rotifer
Now it just acts as a dumb screen for my Apple TV box.
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.
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>My understanding is that this is how Eclipse's Java compiler works, but I'm not positive.
[1] https://hdombrovskaya.wordpress.com/2024/01/11/the-optimizat...
$ 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.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/...
[1] https://quoteinvestigator.com/2011/08/09/remain-solvent/
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.
[1] https://cacm.acm.org/magazines/2023/6/273222-the-silent-revo...
Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.
[1] https://openjdk.org/jeps/426[1] https://petapixel.com/2023/04/12/pentax-unveils-k-3-iii-mono...
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. 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...
blah | sudo dd of=/some/file
where: blah | sudo cat > /some/file
wouldn't work. head filename | ...
Once its working I find it easy to just type C-aM-dcat (i.e. beginning-of-line kill-word cat).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.)
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... 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.
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...
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...