[TeMPOraL]

On the one hand, this sucks. On the other hand, we're already vacillating along the Pareto frontier of how much we can stuff into code; in fact, most of the criticisms of DSLs are indirectly stating just that.

So with LLMs making it easier to project back and forth between how programmer sees the task at hand, and the underlying dumb/straightforward code they ain't gonna read anyway, maybe we'll finally get to the point of addressing the actual problem of programming language design, which is that you cannot optimize for every task and cross-cutting concern at the same time and expect improvement across the board - we're already at the limit, we're just changing which time of day/part of the project will be more frustrating.

[guelo]

This sounds insightful but I can't make heads or tails of "you cannot optimize for every task and cross-cutting concern at the same time and expect improvement across the board".

Can someone help me out?

[le_marton]

I understand it that way:

The general programming languages we have now are about as good as they are ever going to get. Balance-wise. One can solve problems across a broad range of topics equally well.

Tailoring a language to make some tasks especially easy / straightforward will likely make some other problems a lot harder / more cumbersome to express.

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

[TeMPOraL]

> I understand it that way: (...)

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.

[guelo]

That does sound useful but it seems like it should be fancy features in the IDE, not the language.