I'm already upset enough about what the water heater water is doing to my skin and am about to go tankless under my bathroom sink!
That's by far the more practical option anyway if we truly cared about the problem instead of fawning over engineer porn. The problem is solved. This is pointless engagement about temperature preference masquerading as something more interesting.
Anyone who has handwashed many dishes could tell you that cold water will work, but hot water works faster and with less effort. It's no different for your hands. For best results use hot water to wash your hands and cold water to rinse them then put some lotion on them if you worry about them drying out.
My larger issue, any time I have tried to learn statistics, is how fast the notation moves. You end up flipping back pages and pages just to double-check a definition that was given once and is now being extended syntactically. It's infuriating.
Handling errors in compilers has become the most interesting part of my job. If you do the math, most calls to compilers are error-yielding calls. So those calls really need to produce the best errors possible! (Maybe this is less true in LLM land, but certainly it was right before.) Tracking spans, doing extra algorithmic work, and exploring why the expectation failed in order to give a user the most-informative error possible is extra work on the main compute path. But it pays dividends: easily-diagnosable bugs and quick fixes present in the code itself. Tracking spans to point back to origin definitions, etc., always feel like plumbing work until you see the error that explains exactly what went sideways. And once you do, the errors that don't feel like a frustration you are trying to cast your net over.
>Maybe this is less true in LLM land, but certainly it was right before
I disagree:
I was tasked with rewriting a Python application in ucode for use on OpenWRT. It's a low-resource and dynamic language, and sufficiently JavaScript-like that Opus 4.8 couldn't write code without errors that were obvious with my LSP. The interpreter errors were often reported with the the correct line and column numbers, but with the incorrect code and a vague error message. I had to ask it to use my LSP and fix the warnings and errors, which led to it fixing a few dozen bugs.
Just the other day, Fable 5.1 still wrote a lot of code in Rust that had compiler errors. While I'm sure it could have fixed these errors if the Rust compiler also reported incorrect line numbers, columns, code, with a vague error message to boot, I saved a substantial amount of time and tokens because its error reporting is so comprehensive.
Specific and accurate error message reporting will always have the same high value that it does today. Error messages are far cheaper to generate than tokens.
I made a language design some years ago. More recently, I had Claude carry out some of the implementation to see if it would work. It did not. I tried again, hand-tailoring the IRs and many of the main algorithms, and it did better but the self-hosting compiler still violates many of the design principles and even behaviors in the design document. I have spent six months of free time reviewing and fixing it myself, and it's just a small pet project. I would not open-source that code any time soon.
Imagine if artists were embracing AI the same way coders were being forced to. All that would be left there is taste, and your argument applies as readily there as well.
I encourage you to read the whole thing, but the standout quote for me is near the end:
> One thing I learned from discovering The Elm Architecture is that it is really lovely to be able to show up in any codebase and know what is going on. I think custom operators detract from that enough that they are not worth it for the whole ecosystem, even if they are great for specific individuals.
Having talked to people at work who had to remove custom operators when they upgraded from 0.18 to 0.19, they initially didn't love dropping them, but getting rid of the syntax cliff for new hires at the expense of terseness for the old hands was a decent tradeoff. Personally, I find it can be easy in an ML family language to get a bit wrapped around the axle trying to write the most terse, pointfree implementation of something.
I think you are taking the wrong lesson. The lesson is not "things make break." Many languages break things. Haskell has made it a feature, not a bug.
But this change did more than break things. It meant people using Elm in production had to abandon it, nearly immediately, as all future work would first require them to port the whole stack, in one fell swoop, to Elm (and this was before tail recursion modulo cons was implemented, but recursion was forced).
Imagine if, in Rust's infancy, it decided to remove the C FFI with the argument that people should instead, naturally, rewrite that code in Rust. What would have happened? People would have abandoned it in droves, and it would have been essentially relegated to a research language, never again suited for prime time.
You should consider doing the hard work yourself here. I sat down and reasoned through a Perceus-style RC mechanism a few years ago, made difficult by the presence of one-shot delimited continuations, and actually sorting it all out was not hard. Handing the correct semantics to Claude will produce the correct results if you take the time to understand the actual work you are attempting.
reply