The disconnect is weird isn't it? The latest coding models can churn out a lot of mediocre code that more or less works if the task is sufficiently well specified, but it's not particularly good code, they have no real taste, no instinct for elegance or simplification, weak high level design. It's useful, but not anywhere near superhuman. It's also my impression that improvements in raw intelligence, far from increasing exponentially, are plateauing. The advances that people are excited about come from agentic patterns and tool use, but it's not much higher levels of intelligence, just slightly better intelligence run in a loop with feedback. Again that's useful but it's nowhere in the realms of "greater than Nobel winning across all domains".

Outside of coding, the top models still fall flat on their face when faced with relatively simple knowledge work. I got completely bogus info on a fairly simple tax question just a few days ago for example, and anyone using AI regularly with any discernment runs into simple failures like this all the time. It's still useful but the idea that we're on some trajectory to exceeding top human performance across all domains seems completely unrealistic when I look at my experience of how things have actually been progressing.

Yeah, you can even use tree-sitter to implement a language server, I've done this for a custom scripting language we use at work.

Good article, thanks!

Minor correction though, I think this is not quite correct:

> The compiler computes the required size at compile time by summing the sizes of all locals (accounting for alignment).

In optimized C++ builds, compilers can reuse stack storage for locals whose live ranges don’t overlap, so the required stack frame size is not necessarily the sum of all locals. Some locals may never have stack storage at all (e.g. living entirely in registers or being optimized away).

For objects with non-trivial destructors, storage reuse is constrained by object lifetime and destruction semantics, but the same stack slot may still be reused after the destructor has run.

That's not really "fooling" the optimizer, that's kind of the point of volatile. The optimizer not making optimizations is the intended behaviour.

This might be true in the abstract but it's not true of actual compilers dealing with real world calling conventions. Absent inlining or whole program optimization, calling conventions across translation units don't leave much room for flexibility.

The semantics of pass by const reference are also not exactly the same as pass by value in C++. The compiler can't in general assume a const reference doesn't alias other arguments or global variables and so has to be more conservative with certain optimizations than with pass by value.