I do still wish it had discriminated unions (algebraic data types) and some better error handling ergonomics.

But I might not read it super carefully when recipe planning at the start of the week, which can result in scheduling mistakes.

- Steps that actually include many different steps.

- Steps that don't repeat the quantities, making me scroll back and forth between the step and the quantity list.

The diagrams in this post very cleanly solve both.

To some extent, it feels like the genie is out of the bottle on this. There's so much LLM-generated code out there, and I'm sure plenty of it could be argued to infringe a copyright or license (though I think the legal bar for counting as infringement is set too low), that there's no way to go back and undo it.

That said, OpenJDK might be afraid that someone will decide to make an example of them because they are a high-profile target.

This could be both for small scale things (e.g. which part of this is squeaking?) or large scale (e.g. is that booming noise coming from the construction a few blocks away?)

I also wish there was a book that guided you through the process of implementing a language with accurate garbage collection, similar to how Crafting Interpreters teaches you to implement a language. Perhaps it could start with a shadow stack + simple mark-and-sweep and then move on to stack maps + generational GC.

Speaking of which, what's the timeline of the RAM shortage ending? I have no sense for whether it is going to be (for example) 6 months or 3 years.

> the act of writing out a problem to a model still forces the same sentence-level precision described earlier

(model referring to LLM here)

but not as writing for writing's sake