You understood and explained what I meant well.

> So further improvements in abstraction and expressiveness have to come from elsewhere. Not better programming languages but partnering up with an LLM?

In practice, probably yes; but the point I've been making here and in bringing this up over the years is, further improvements can come if we stop insisting on directly editing "single source of truth" code representation. Then, you no longer need to make trade-offs up front - for task A, you may view code through lens (or "in language") that makes tasks like A especially easy, then for task B you switch to a view that makes tasks like B especially easy.

Examples:

- Switching between "point free style" and explicit temporary variables;

- For a given function, inlining its entire call subtree, turning a tiny function calling tiny functions into a single block you can read top to bottom; super useful for debugging;

- Switching between "exceptions" and "sum types" styles of error handling (they're pretty much equivalent), or more generally, switching between showing all vs. hiding error handling code vs. handling everything except error handling/propagating code;

- A view of code that shows only types, or one showing async, or one entirely hiding it;

- A database-style view for code, that lets you query it and edit in bulk;

- An editable state machine diagram that corresponds to code (maybe needs a little help by manually identifying which set of classes is conceptually a state machine, which methods are transitions, etc.);

- Hide/show logging, telemetry, or any other cross-cutting concern that you don't strictly care about at the moment (superset of earlier hiding of error handling code);

And so on, and so on.

Point being, all those views/perspectives operate on the same underlying artifact - the codebase. It can be plaintext, but because no one is actually reading it directly, it doesn't have to be optimized for anything in particular (or it could just be simple and straightforward, at a price of being verbose; say Python). Meanwhile, the views/perspectives could each use syntax or format best suited for the specific task it helps with. All the trade-offs would be made at the point of use, instead of baked in up front when the project starts.