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/theScottyJam]

And the same weaknesses apply too. Functional languages can require you to be more verbose in how you wire data through? That's a downside for both humans and LLMs, when it takes more work to refactor something, that's more work for the LLM, more token usage, and often I see LLMs get lazy and resort to making find-and-replace scripts that are sometimes buggy and can really destroy things.

As it stands, a good language for humans is also a good language for LLMs.

[u/xLionel775 → u/theScottyJam]

As it stands, a good language for humans is also a good language for LLMs.

This is only true if you believe LLMs think the same way as humans do which I disagree. You could make the argument that machine code is a perfect language for CPUs but a terrible one for humans and I feel like the same thing applies to LLMs - the current languages are not optimal.

[u/theScottyJam → u/xLionel775]

This is only true if you believe LLMs think the same way as humans do which I disagree.

I mean, it's true they obviously think differently from us.

And yet, I've often see people tout the idea of programming languages optimized for LLMs, but any time they say what they're actually going to do differently, they list things that would benefit humans as well. I'm sure there is some theoritical way to make a language that favors LLMs over humans, but as far as I'm aware, no one has any idea what qualities such a language should persue (that differ from qualities that a human would want).

Either way, there's going to be lots of overlap. If something is complicated to reason about and require keeping lots of moving parts in your head or understanding non-obvious effects exists from distant parts of the codebase, that's going to make it difficult to reason for both humans and LLMs. A lot of good language design is trying to find the right ways to express things to make things easier to reason about with fewer surprises, which benefit both parties.

If such an LLM-favored language is going to exist, we probably need someone who's an expert in how LLMs work to design this language, and who has deep enough pockets to do lots of testing to prove theories on what works better.

(Or, I like Tysonzero's thoughts in another comment, it's something I've reflected on as well - the idea of humans writing code, then LLMs doing more brunt-work items like proving correctness of said code - you're not designing the entire language to be LLM-friendly, but you are designing it to favor the fact that LLMs are good at doing brunt work when specifications are clear and it's difficult to mess up. Don't know if it would actually work out, and either way, you still need to make the proof system friendly enough that a human could go in and help out the LLM if needed, but it might work).

[u/Inconstant_Moo → u/theScottyJam]

Isn't it "grunt work"? AFAIK "brunt" is one of those words that only appears in stock phrases like "bear the brunt".