rotifer

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>

Probably NumbeR.

> Surely it’s possible to make a compiler that takes time proportional to how much of my code has changed [...]

My understanding is that this is how Eclipse's Java compiler works, but I'm not positive.

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.

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.