HN user

rotifer

150 karma
Posts1
Comments50
View on HN

A year or so ago I bought a Hisense 65U88KM, which comes with Google TV. During the setup procedure it asked me if I wanted to enable the "smart" features, such as Google TV, the camera and microphone, or connect it to a network. I said no to all of them, and that was that.

Now it just acts as a dumb screen for my Apple TV box.

Brian Haidet (Alpha Phoenix) shows how he made a video of a laser beam travelling across his garage. From his description:

I'm using the technique from the electricity waves video where I used repeated oscilloscope measurements synced after the fact to produce "videos" of electricity moving down a wire. The only difference is that instead of measuring electricity waves, I'm measuring light emitted by a laser, bouncing off the wall, traveling to my camera, and landing in the window of a photomultiplier tube.

In Haskell the numerator and denominator of the Rational type are unbounded integers, so one of the (many equivalent) ways of writing it is:

    ghci> sum [i % (i+1) | i <- [0..9]]
    17819 % 2520
    ghci> 
% is the constructor for Rational numbers. I.e. one half is written (and shown as) 1 % 2.

I'll spare people the full result, but:

    ghci> sum [i % (i+1) | i <- [0..999]]
    70755...77483 % 71288...20000
    ghci>

FWIW, in an upcoming version of Java you'll likely be able to do this:

    $ cat Hello.java
    void main() { System.out.println("Hello, world!"); }
    $ java --enable-preview --source 21 Hello.java 2>/dev/null
    Hello, world!
    $
This is currently a preview feature in Java 21 and 22.

The January 16, 2024 edition of the CBC radio show "As It Happens" has an interview with Gerry Vogrincic, the doctor who bought the book in 2007 and just sold it.

There's a transcript of the interview here [1]. Search for "Old Anatomy Book".

The audio for the entire episode is here [2]. I don't recall how far into it this interview occurs. (I've sometimes found their interviews split into separate clips, but if that's the case here I don't know where to find it.)

[1] https://www.cbc.ca/radio/asithappens/the-aih-transcript-for-...

[2] https://www.cbc.ca/listen/live-radio/1-2-as-it-happens/clip/...

I write and review medical software. When I'm reviewing code the most important question is, "Is it correct?" If it's not, then the review simply isn't approved (obviously).

Anything that makes it harder to determine correctness is a strike against the code. This can include anything from high level organization, to comments, to the naming of variables, to the use of whitespace. For example, with respect to variable names, if you're implementing something that has to conform to the DICOM standard, then you should consider following their nomenclature, even if it may not be what you'd normally use in other contexts.

Aside from correctness issues, I'll make anything from "strong recommendations" to "mild suggestions". (In theory, any of these could cause me not to approve a change, but the closer we get to "mild suggestion" the less likely that is.) Examples might include:

- You're trying to do something with X. I'm a domain expert in X and while your code is technically correct it's not idiomatic. I suggest doing it this other way instead.

- You added a public function to a library, but it will fail if the String argument isn't a valid Photometric Interpretation. Yes, I see that you only call it with valid values, but since it's public anybody can now call it, and they may not be so diligent. How about making it an Enum?

- You have a loop that, superficially, looks like it's calculating Bar, but upon closer examination it's (correctly) calculating Bar'. How about adding a comment stating this, so that no one is tempted to (incorrectly) "fix" it?

- You've implemented a function that does Y. All our code links with the Foo library, which happens to have a function that does Y. How about using that instead?

- Your log message makes sense if you're reading the surrounding code, but someone from support seeing it in the log file won't know what to make of it. How about including this contextual information in it?

- In the loop that you added, your indentation is inconsistent with the rest of the function. How about making it the same?

- Why do you have four blanks lines in the middle of your function?

In my own code I'm pretty anal about formatting, comments, log messages, use of whitespace, etc. I'm definitely less harsh when reviewing other people's code, but I have to admit that when I see sloppy formatting, grammatical errors or gratuitous use of whitespace, I'm on the alert for sloppiness in other areas, such as design and implementation.

I don't believe that Java currently uses it by default, although I've seen discussion about possibly using it in the future.

However, you might find these links useful:

    - I built an ultra high performance HTTP server in Java, powered by io_uring - https://old.reddit.com/r/java/comments/12f2h79/i_built_an_ultra_high_performance_http_server_in/
    - server is here - https://github.com/bbeaupain/hella-http
    - based on these bindings - https://github.com/bbeaupain/nio_uring
I wouldn't be surprised if there are others.

That quote comes from here [1]. A few lines later, writing about a talk he had given at a software company, he says:

    I gave a beautiful lecture, which fell flat on its face. The
    managers were horrified at the suggestion that flawless software
    should be delivered since company derived its stability from the
    subsequent maintenance contracts. The programmers were horrified
    too: they derived their intellectual excitement from not quite
    understanding what they were doing and their professional
    satisfaction from finding weird bugs they had first introduced in
    their daring irresponsibility. Teaching the competence to program
    boils down to the training of misfits.
Ouch.

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...

The city recently added sidewalks to my (low traffic) street after doing some sewer upgrades. Lots of people continue to walk on the street because it's consistently flat, as opposed to the dip and slope you encounter on the sidewalk at each driveway entrance. These can be more treacherous in the winter because you now have ice on a slope. People with (even mild) mobility issues seem to be disproportionately affected.

I rarely use dd, but my most common use might be:

    blah | sudo dd of=/some/file
where:
    blah | sudo cat > /some/file
wouldn't work.

I often use cat because when constructing a pipeline I'll do multiple rounds of:

    head filename | ...
Once its working I find it easy to just type C-aM-dcat (i.e. beginning-of-line kill-word cat).
Learn TLA+ 4 years ago

I just started reading the book a couple of days ago. Sigh... :-)

One thing that I wish websites did is to make it easy to report simple typos and grammatical errors without having to go through GitHub. For example, on https://www.learntla.com/intro/faq.html "losting" should be "losing". It would be great to simply and quickly report them without having to context switch and go through the overhead of opening an issue or creating a PR. (In any case, I don't even have a GitHub account.)

This reminds me of the following quote from the Preface to "Structure And Interpretation Of Classical Mechanics" by Sussman and Wisdom [1]:

    When we started we expected that using this approach to
    formulate mechanics would be easy. We quickly learned though that
    there were many things we thought we understood that we did not in
    fact understand. Our requirement that our mathematical notations be
    explicit and precise enough so that they can be interpreted
    automatically, as by a computer, is very effective in uncovering puns
    and flaws in reasoning. The resulting struggle to make the mathematics
    precise, yet clear and computationally effective, lasted far longer
    than we anticipated. We learned a great deal about both mechanics and
    computation by this process.
[1] https://archive.org/details/StructureAndInterpretationOfClas...

I'll second Michael Kerrisk. Here's what I had to say about "The Linux Programming Interface" in an earlier post [1]:

    Covers some of the history of the Linux/Unix API, describes it in detail, has plenty of examples, compares different APIs that do similar things so you can make an informed choice (e.g. System V vs. POSIX message queues).

    If any book in this list stands out for me, it's probably this one. It might be partly due to the surprise factor of how enjoyable and well-written a 1000+ page, near-reference book is.
From that same list [1] I'll also highlight Graham Hutton, whose writing I find particularly good and clear. He also has a number of YouTube videos on functional programming and Haskell.

Someone also mentioned Julia Evans [2]. She makes complex topics more approachable.

[1] https://news.ycombinator.com/item?id=23453286

[2] https://www.jvns.ca/

I expect we mostly agree, but I disagree with your use of "ever". :-)

From the "January 1998 North American ice storm" Wikipedia article [1]:

    The area south of Montreal [...] was nicknamed the triangle noir ("dark or black triangle") [...] for the total lack of electricity for weeks.
    
    [...]
    
    In Quebec alone, 150,000 people were without electricity as of January 28.
(The storm started about Jan. 4.) The Montreal area is not prone to common natural disasters.

[1] https://en.wikipedia.org/wiki/January_1998_North_American_ic...

ISO 8601 specifies durations [1]. For example, Java's Duration type [2] is based upon it.

Depending on your language, and how much type safety you want, you could use something Haskell's units library [3].

I believe F# also has units [4], possibly built in to the language? (I've never used F#.)

[1] https://en.wikipedia.org/wiki/ISO_8601#Durations

[2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

[3] https://hackage.haskell.org/package/units

[4] https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

To the section "Popular Math Books" I would add almost anything by Julian Havil. John D. Cook referred to him as a writer of "serious recreational mathematics" [1]. I would probably put his "Nonplussed!" and "Impossible?" books in the "Level: Easy" group, with the others at least in "Level: Medium". "Gamma" is one of my favorite serious recreational math books.

If you like getting into the nitty-gritty of problem solving then check out the books of Paul Nahin. They vary between "Level: Medium" and "Level: Difficult", with many of them reveling in the solution of equations, and integrals in particular. Although he recognizes the need for proofs, he makes a point of avoiding them in his books.

[1] https://www.johndcook.com/blog/2019/09/29/a-sort-of-mathemat...