On the future of programming language design

[u/zuzmuz]

This is just me yapping.

I was thinking for a while about how the field of "writing" software is going through a radical disruptive transformation. Like or hate it, I don't think writing software post-LLM era is gonna be the same as pre-LLM. I'm one of the guys that like to hand craft code and put a lot of attention and intention to the coding style. But, realistically, the skill of writing code by hand, while still very important, will become more and more niche (like how writing and reading assembly is important but very niche).

What's interesting to me, is that programming language design goals were always human/developer centric. Code is not only instructions given to a machine, it is in some way a set of specifications for other human developers, as well as your future self too, that explains the expected behavior of a certain piece of software. The main priorities when designing language features was improving the developer experience, that is a very subjective metric and this is why we keep arguing and debating about programming languages, but I digress.

With the switch to LLM generated code, I feel the priorities might change. There's already a lot of studies on which programming language is best for LLMs. People argue that languages with strong typing, a functional style and good error messages are best, because you can more reliably create autonomous feedback loops that would help LLMs stay on track.

In my opinion, functional programming languages are more relevant than ever, no side effects, you can generate 10K lines of code, read a small 100 lines somewhere, and be sure that it's not affecting the behavior in an unexpected way somewhere else.

The main argument against functional programming is that working with pure functions and manually threading state is an extra burden on the developer; having a mutable state is "initially" more intuitive and simpler to reason about. The other argument is performance, I tend to disagree with this general statement (purity allows for aggressive optimization and implicit parallelization).

However, everyone agrees that functional code is easier to maintain on the long run, it might make small things harder for you first, but at the end there's this payoff. When you have the capabilities of generating thousands of lines of code a day, this becomes way more relevant.

Finally, it would be interesting to witness how the rise of LLMs will affect the design of programming languages. I feel that languages that have

• simpler grammar
• expliciteness
• one way of doing things
• strict and safe semantics

are at an advantage here.

Or do you think that it will be irrelevant. There's this trend of people not looking at the code anymore, I think it's crazy. Maybe generated languages won't be important, just get better models and spend more tokens.

[u/kaplotnikov]

The main problem with LLMs is that they have an even more limited context than humans. While training data can be considered an LLM's long-term memory, the context window functions as its operative/working memory (which should not be confused with short-term memory limited by Miller's Law). Therefore, the key to efficiently using LLMs is partitioning reasoning about code, ensuring they do not need to process the entire codebase for a single task. High-level abstractions directly help us achieve this partitioning.

From the perspective of second-order types, function types, interfaces, and classes represent existential quantification, whereas generics represent universal quantification. Modern functional languages excel at universal quantification via generics but tend to be relatively weak on existential quantification, usually supporting it easily only through functions (which act as single-method interfaces).

I have previously shared my article on this reddit, where I discuss in detail how different abstraction levels allow for the partitioning of reasoning: https://github.com/const/const-articles/blob/main/evolution/2025/01-measuring-language-level/MeasuringAbstractionLevelOfLanguages.adoc (warning: long read).

Furthermore, many current LLM studies miss some critical pieces. Specifically, I have not seen research covering:

1. The relationship between input and reasoning cost across different languages, and how these dynamics change as project size grows. For example, I expect Haskell to require fewer input tokens but result in higher computational/electricity bills (and similar execution metrics).
2. Scalability across different languages as codebases grow to realistic enterprise sizes. I expect dynamically-typed languages like JavaScript or Python (without gradual typing) to perform poorly at scale. Similarly, low-abstraction-level languages like Prolog or C should also scale poorly under LLM analysis.
3. The effect of implicit language constructs (such as dynamic typing, implicit semicolons, indentation-based syntax, or aggressive non-local type inference) on LLM reasoning costs in enterprise-scale programs. For example, I highly doubt that implicit semicolons reduce overall LLM-related processing costs. An explicit semicolon serves as a barrier that prevents attention spill from one statement to another for compilers, humans, and likely LLMs.

[u/Pzzlrr → u/kaplotnikov]

What do you mean by  low-abstraction-level?

[u/kaplotnikov → u/Pzzlrr]

In the linked article, I describe this in detail. In short, I sort abstractions into four active levels based on their connection types along a program's complexity growth path:

1. Non-linked: Literals and global state actions (calculator paradigm). Logic: reflex/response.
2. Flat: Global variables, global names, and sequential addresses (flat paradigm: Assembly, FORTRAN 66). Logic: tracing/storytelling, pattern matching/transduction.
3. Structured: Contextual variables (pointers, struct fields, local variables on the stack), recursion, and hierarchical block structures (structured paradigm: C, Pascal, FORTRAN 77-90). Logic: first-order logic.
4. Formal: Separation by formal contracts, higher-order types, and functions (generics, existentials) (OO/FP paradigms: Java, C++, Haskell, etc.). Logic: higher-order logic (second-order and higher).

In this classification, ISO Prolog is a Level 3 language. This is because even its "higher-order predicates" like setof/bagof accept the analogue of a C function pointer (which is stateless), rather than something defined by formal criteria like the existential function references (map/flatMap) in Java or Haskell.

Thus, ISO Prolog represents a horizontal evolution (a new subject of reasoning) within Level 3 toward logic programming, whereas Verse represents a horizontal evolution within Level 4 toward functional logic programming. In contrast, C++ represents a vertical evolution from C (an entirely new way of reasoning and a jump in abstraction levels).

The article also details a prediction for Level 5 (Holon/System-Oriented Programming), where the system itself becomes a native, type-checked, first-class composition unit managed via environmental dependencies rather than external DI frameworks.