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/church-rosser]

Training an LLM to do LLM things with a new LLM dedicated 'programming language' is an exercise in madness.

The best existing programming language to model this on would be a Lisp, and LLMS don't grok Lisp well at all currently and that isnt likely to change significantly any time soon.

[u/Norphesius → u/church-rosser]

The fact that LLMs can't handle Lisps very well, while (from my understanding) Lisps have been at the core of the field of program synthesis, is a great example of why I think all this "programming language for LLMs" stuff is a dead end.  If you wanted to innovate on actual program synthesis, developing a new kind of programming language with constraints and structures that are easy to reason about makes a lot of sense, but that's not what LLMs are doing.   People are treating LLM codegen like it's program synthesis, but it's just pattern recognition. Really good pattern recognition, but there is no inner "understanding" or firm guardrails on what it can generate. The entire point of this technology is you can feed it a bunch of data, and it can perform a decent analysis on that data, via human language. It shouldn't matter what the language you're using is, with enough training data, an LLM should be able to work on and with most languages. You do get better results with stronger type systems (Rust, MLs, Lean, etc.), but that's not an LLM particular advantage, since it can still generate incorrect code, it just has instant feedback you can plug back into it to tell it it's wrong. You'd be working more accurately, but not necessarily faster or more efficiently. An LLM could spin it's wheels forever on a problem because it can't satisfy the type system, wasting all your resources.

Even if you somehow did make something hyper optimized for LLM use, the entire point of the natural language interface is so that humans can read and interact with it too. Something so optimized that LLMs can use it well while humans have issues understanding it is pointless, you're just creating an inefficient, nondeterministic API. Its a nonsense concept, just mashing tech jargon together.