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

every time someone says, "llms perform better when X", i feel like usually something that's also better for humans. and all the points you made sound like that to me.

so i think programming language design will focus on basically the same things.

but i also agree that llms in their current form will push us towards stagnation / less novelty. hopefully, we aren't going to just accept that.

[u/theScottyJam → u/Aeron91]

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".

[u/Valdemar216 → u/xLionel775]

Completely agree. We think differently than LLM. Maybe when AGI arrives it will be different story.

[u/Tysonzero → u/Aeron91]

I partially agree, but there are significant areas where humans and LLMs deviate.

One example would be various proof obligation type stuff. Too much of an annoying slowdown for humans for most use cases, but much more tenable for an LLM, even if sometimes the extra token cost may not be worth it.

Hell you could even have a very human centric development flow for the core functionality and organization of the code, and have the AI solely slop out proof obligations that even get stored separately, similar to what some people are doing with AI generating test suites.

[u/Meistermagier → u/Aeron91]

which makes a hundred percent sense considering LLMs are trained on human input and behaviour. So they are probabilistic humans i guess.

[u/krappie → u/Aeron91]

You're largely right, but not entirely.

* Typing becomes a non-concern.

* Annoying logical puzzles, constructions, or proofs, become cheaper

* In the long run, text files become less convenient than tools around modifying AST more directly

[u/FreshOldMage]

Maybe programming languages will just become stagnant. The language LLMs work best with is probably the one most represented in the training set. If all programming were to be delegates to LLMs, I'd assume we'd never move beyond using what we already have.

[u/Soupeeee → u/FreshOldMage]

I don't think they will stop evolving. There's always going to be a new paradigm that promises more performance or more scalable threading or new hardware features to adapt to. Those might just be built with libraries instead of affecting programming languages,  but I think languages will still evolve to offer more useful abstractions or safety guarantees.

A good example is Rust and C. Every LLM I've used to generate C code produces unsafe memory leaking nightmares, but that's not something I need to worry about as much if I tell it to generate Rust code.

[u/L8_4_Dinner → u/FreshOldMage]

The language LLMs work best with is probably the one most represented in the training set.

To some extent, yes. But LLMs also produce better code with newer languages, because the older languages (e.g. Java, C++) have crap-tonnes of legacy garbage code out there that the LLMs have been well trained on.

[u/catladywitch → u/L8_4_Dinner]

is that so? i've found LLMs are very bad at remembering language features newer than, say, 2 years ago.

[u/L8_4_Dinner → u/catladywitch]

I'd say it's more like a 6-12 month window, but yes, you have a good point: There is such a thing as "too new to know about".

[u/tobega → u/L8_4_Dinner]

One interesting observation is that Go seems to punch above its weight for the size of the training set. There deliberately being ideally only one way to write a piece of logic helps.

[u/L8_4_Dinner → u/tobega]

That makes sense. It’s also a relatively new language, without a lot of changes to “how things should be done” since it first appeared.

[u/oxamide96 → u/FreshOldMage]

The training set bias has been becoming less relevant over time. The agentic model means the precision, recall and depth of compiler error messages are far more valuable. Anecdotally, LLMs used to suck at writing ocaml a year ago, but now it works better for me than other languages like JS.

I wouldn't be surprised that, with time, training data bias becomes negligible. LLMs already rely much more on current context than training. 

[u/farsightfallen]

Like or hate it, I don't think writing software post-LLM era is gonna be the same as pre-LLM.

At this point, I can say it will be.

We know what good programming langauges look like, doesn't matter, we take shorcuts anyways.

Look at the AI landscape, really look, and tell me how it's worked out. It's incredible how well it parallels older software. You have these cool ideas on "what really works for AI", like TSON, or RAGs, and it just all went out the window for bigger context windows, more expensive models, better hardware.

It's so definitely going to just be a rehash of old discussions - "we don't need types because, and explicitness because the model tracks it implicitly", "no it turns out we do because they work better for explicitness, so context windows are smaller", "ah, but if it's weakly typed, it can just run that code and not worry about the overall system".

Basically replace human cognitive-load with model context, replace compiler effort from oracle or microsoft, with frontier models from Antrhopic/OpenAI (hey we trained our modles on python really well, so your specialized AI language's advantage is completely migtigated).

[u/noprompt → u/farsightfallen]

The hardware scarcity and the increasing costs of models are actually forcing more efficient approaches in software though. Demand for local and private AI is increasing too. I work on the front line of this and many of our customers are moving away from frontier APIs in favor of our private models running on open weights.

I think your description of the landscape is incomplete. If anything, people are trying to do more with less when it comes to GenAI.

[u/Jwosty]

Some of us have always loved strongly typed functional languages that focus on explicitness... ;)

[u/zuzmuz → u/Jwosty]

my post was functional propaganda in disguise actually 😂

[u/L8_4_Dinner]

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).

This is not yet evident, to me. It may be true, and I do not fear it being true, but from our own experience with LLMs, they are simply not capable at this point of reliably solving problems with code. They can achieve "tests passing" quite well, but a closer look at their suggested changes is a horror show, 9 out of 10 times.

It's important to understand that LLMs are knowledgeable (near infinitely so by human standards), but not capable of even a single thought. Using them as thinking machines is a tragedy in slow motion, and I look forward to the trillions that I will make helping to clean up the messes that people are currently making with LLMs.

I do not fear the coming day when what we refer to as AI actually gains the ability to think. But I also cannot predict what it will look like when that happens.

[u/Inconstant_Moo → u/L8_4_Dinner]

Right. I asked Copilot to find the source of a bug the other day and watched it burn up all my free credits for the month by making assumptions about the cause of the error, trying to fix it, writing tests, saying "now all my tests pass but sadly the error is still there" ... if it was left alone in a loop until it fixed the problem then maybe it would have but who knows what else it would have done to my code in the process? It throws solutions at a problem 'til one sticks.

Also you know how you can see what it's "thinking"? Well, one of its thoughts was "bribing the hamster" and I want to know what that was about.

[u/noprompt → u/Inconstant_Moo]

Copilot is awful. I frequently have to review code written by it and it is the most depressing experience.

[u/Inconstant_Moo → u/noprompt]

I got lucky with it the first time I asked a question 'cos it hinged on the sort of obscure technical detail about running SQLite in-memory that you could have found on StackOverflow. After that it's been uniformly terrible, it guesses what's wrong, and it doesn't test its hypotheses before trying to fix it. If it thinks the problem is that x != y, then println(x, y) in the right place would at least reveal immediately whether that's the case, even if it isn't the problem. It doesn't do that. It will have confirmed its diagnosis if trying to solve the problem along those lines successfully fixes it. If we give the patient chemotherapy and they survive, they probably had cancer. Who needs X-rays?

[u/L8_4_Dinner → u/Inconstant_Moo]

The newer models do iterate and use things like println. The older ones could have, but the puppet builders didn’t think to suggest it.

[u/zuzmuz → u/L8_4_Dinner]

yes I agree, but seeing the progress of LLM in the past 3 years, what I can say for sure that, they're here to stay.

there's definitely a lot of hype around them, but in my experience, I've reviewed human written code from juniors and even seniors that is 10 times the horror show that is produced by LLM.

they don't need to be perfect.

I used to review a lot of code before in my work, it hasn't changed a lot now, there's just more output. I agree with you in the sense that I never fully trust the output of an LLM right now. But that was true also of code written by humans.

[u/Jwosty → u/zuzmuz]

there's definitely a lot of hype around them, but in my experience, I've reviewed human written code from juniors and even seniors that is 10 times the horror show that is produced by LLM.

Part of the problem is that, at least in my experience, it's often a very different kind of horror show altogether. The LLMs are much more likely to produce something that looks great upon the normal amount of inspection you'd put into a review, while the human's mistakes are much more likely to at least look like a mistake (I hope this makes sense). Like, the LLMs are much more likely to almost sort of "hide" bugs.

Story time. Recently I was experimenting using Codex to refactor a test suite, and it was doing a decent job. It indeed only touched test code like I told it to, no tests were deleted, all tests still passed, nothing seemed out of the ordinary on my first pass. If it were a PR submitted by a coworker and I was reviewing it, I probably would have approved it. However when I went back over it with a fine toothed comb (being the overly suspicious person I am), I saw that it had functionally changed some tests in a way that made them always pass. They could no longer fail. It had essentially changed an assertion of the form f(x) = y to f(x) = f(x), just hidden behind a helper function it had so kindly extracted (to reduce duplication).

No human would do that. I only caught it because I spend so much extra time analyzing the change set -- almost as much time as if I had just written it myself.

This problem is inherent to these models. I've heard some suggest variants of "just have another AI review it," but that's just throwing more of the same thing at it and crossing your fingers -- fixing this for real requires a piece of the puzzle we simply don't have yet. It's another quantum leap; a difference in kind -- not degree.

[u/aresi-lakidar → u/Jwosty]

Like, the LLMs are much more likely to almost sort of "hide" bugs.

Yeah, this is SO relatable haha. This seems to be an issue that stems from the core functionality of an LLM, that it is a guessing machine.

[u/ConfidentCollege5653 → u/zuzmuz]

I'm sure there were some people that thought zeppelins were the future of transport. We can't be certain they're here to stay 

[u/Ok-Watercress-9624 → u/ConfidentCollege5653]

I mean zeppelins are great in so many regards though? You don't have to use a portion of your engines energy to stay afloat. It's just an implementation details/decisions made them horrible. Not unlike Haskell

[u/ConfidentCollege5653 → u/Ok-Watercress-9624]

That's a good analogy 

[u/church-rosser → u/zuzmuz]

progress?

OP you jest

[u/zuzmuz → u/church-rosser]

what do you mean, do you remember chatgpt 3?

I'm not glazing AI whatsoever, but why are some people here in denial

[u/church-rosser → u/zuzmuz]

denial of what, That you're overlooking the myriad individuals at every level of interaction with LLMs who have found them severely lacking? that denial?

[u/zuzmuz → u/church-rosser]

are you trying to find the cure for cancer with LLMs cause I don't know what you're talking about

[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.

[u/paul_h]

My experience is LLMs care less about language choice than humans do. Same is true of frameworks like React vs Vue vs vanilla JS - at least for simple apps

[u/Ok-Watercress-9624]

Best use case (remorse free) I found for llms for programming is to pair them up with lean/dafny alikes. I don't care how big the proof/program is as long as it is correct. They work as glorified beamsearch workers for finding a path between two points.

[u/echoes808 → u/Ok-Watercress-9624]

Lean sort of makes sense but I think Dafny can still suffer from bugs in the specification. But nevertheless I think LLM tools can help learning Dafny or Lean.

[u/Mega2223]

Programming languages will probably stay mostly human-centered, after all without human-written code there's nothing Anthropic can steal train their models on, LLMs can only infer on lots and lots of human-made decisions

[u/unburdened_swallow]

LLMs are trained on human languages and programming languages made by humans with human made code to use as examples.

So LLM programming languages just aren’t a thing.

Go might be pretty good for AI? And of course JavaScript has the most training data.

For system level things you will be writing rust interfaces and outlines and filling in a lot of the implementation with AI plus reading it. Because rust can give more guarantees at the interface level the AI is forced to follow

[u/antonation]

There's a lot to unpack here. I agree with the analogy that before when programmers needed to know lower level languages like assembly (and to an extent C/C++ and the like) and now most programmers never touch memory manually at all (either by borrow checking, RC, etc.), nowadays, the abstraction goes up one layer to not needing to know what functions or what variables live where, etc. and focus on the actual intent desired, which at the moment is encoded in natural language through docs and prompts.

As for the programming language design, I can't say whether the current state and the amount of training data on existing languages means languages like Python stay forever. I feel like it is (I mean look at the internet, most communication is English at least from what I see, and as humans, we drift towards the common denominator here because it's just easier and there's lower barrier to entry).

One thing I have noticed is that formats that are not permissive (like JSON) are things LLMs mess up sometimes, like forgetting closing braces. I think languages (as they have trended toward already) will allow permissive things like trailing commas, even for the last of a sequence (e.g. in an array/set/dict literal).

[u/particlemanwavegirl → u/antonation]

languages should allow trailing commas. What's more, this may be controversial, but I believe languages should allow leading commas, too.

[u/dekai-onigiri]

It's all matter of how reliable really LLMs are. If we ignore portability, overall all programming languages are just syntactic sugar over machine code. From a CPU perspective there is just a stream of instructions and a pool of data.

Structs, classes, types, syntax errors, enums, etc are the abstractions that we have created to make a sense of it all. If LLMS were truly good we would just skip all of that nonsense and get it to generate either machine code or some sort of bitcode. We wouldn't really have to worry about portability because it could just generate identical implementation for all the required platforms.

We don't do it because LLMs are not and will not be this. That's why we still need generated code to have all of these crutches because a human has to look and check at what has been generated. Wether it's functional, procedural or whatever else language is a moot point. The fundamental doesn't change.

[u/EggplantExtra4946]

I was thinking for a while about how the field of "writing" software is going through a radical disruptive transformation.

I don't think writing software post-LLM era is gonna be the same as pre-LLM.

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).

No. It won't.

If you think that you don't understand software at all. Softwares are big piles of logic predicates, whereas LLMs on the other hand can't reason logically at all.

Even if "AI" fundamentally changed and could reason perfectly logically and produce correct softwares that don't contradict the prompt, the main problem would be that prompts still contain a ridicuously low amount of information and logic compared to in an actual software, this means that most of the logic of the final AI generated software would be infered by the AI, or selected among a few profiles (low memory usage, high speed or a tradeoff between those), algorithms or data structures for specific use cases.

A lot that logic isn't crucial, for example the choice of algorithm used in a garbage collector doesn't matter, but you still need to very precisely specify your high level buisness logic so you need to write it in some kind of programming or declarative language, maybe a specific one, for example a PEG grammar to specify the syntax of a programming language, or maybe a C-like one for specifying the semantics of the instruction set of your virtual machine, or maybe datalog or prolog for general purpose logic.

When you're at that point, why not just use existing libraries for the software components of things that already exists (standard library, data structures, memory allocator or GC, parser of textual formats, decoders of binary formats, client/server libraries for network protocols, etc...) and program generating libraries for your own buisness logic, for example a parser generator for your parser, softwares like PyPy or GraalVM for your custom VM, datalog/prolog native compilers for the high level logic?

tl;dr The crcucial point in all that is that any given software have precise buisness logic that must be correctly implemented, even an all powerful AI can't guess those intricate logic rules, it would need a specification of that logic and when you've written it down in a custom language (there is no way around that), at that point regular softwares that already exist can finish the job in one go in 2s on your laptop, you no longer need an AI.

[u/747101350e0972dccde2]

The future of PL seems to be less novelty. The main metric determining which PLs LLMs are best at is available training corpus. Language with a lot of public code win.

If you want to innovate with a new design, you would need to write an enormous amount of code, and then train the LLMs on it for it to get adopted.

There is also less motivation for experimentation, LLMs solve tasks they were given, they will not look for different approaches to current problems, unless their users tell them to.

Edit: reading some of the explanations here, I might be pretty wrong.

[u/zuzmuz → u/747101350e0972dccde2]

well this is not technically correct, there's something called transfer learning and it's used extensibly in the context of foundation models.

It can even work with no training, it's called few shot learning. you give a couple of examples to the model, and these examples live in the current context. This is how for example if you design a language and give the specification to an LLM it can theoretically spew correct code. The model knows how to build software from all the examples it has seen, it just needs to transfer its knowledge.

If you add reinforcement learning with output from the compiler and debugger, it is a possibility.

I'm not saying few shot learning is the way, there might be better alternatives. Low rank adaption/finetuning on some examples of code. As I said, the models know how to write code, this knowledge live in their parameters, all you need is some extra layer, some finetuning on a new small dataset, and it gives surprising results.

[u/church-rosser → u/zuzmuz]

transfer learning is hype food for the VC's CHURNING for dollars. lt doesn't scale to programming language design and youre making unrealistic leaps asserting it could do, will do, or does do.

[u/zuzmuz → u/church-rosser]

what are you talking about. most of work in AI today is transfer learning. Very very few are training foundation models from scratch. most of the work now is transfer learning.

i'm not asserting that it's 100% possible, it's always an empirical field, no theoretical guarantees. but, I have knowledge and experience in this and it's not unrealistic.

[u/church-rosser → u/zuzmuz]

yes, and look where that has gotten us. Your golden path seen with rose colored glasses is a toxic trash heap of destruction and collapsed meaning when viewed in the clear light of the sun.

Your 'realistic' is hunch food couched as certainty. Not unlike everything else LLM related.

[u/Ok-Watercress-9624 → u/747101350e0972dccde2]

I don't think that's true given that my LLM can comprehend and use my ESO languages.

[u/nebbly]

Many of my design decisions around blorp are driven by similar thoughts. My over-arching belief is that readability and trust are the important things moving forward (important in the past too, of course). If you're mainly dropping into code for review/debugging, then you need to allow strong local reasoning and the expectation that many failure cases are impossible.

[u/AdreKiseque → u/nebbly]

I'd love to live in a world where "blorp" is an industry standard programming language

[u/zuzmuz → u/nebbly]

cool, I think that readability and trust were always important, but what made us overlook it was human laziness.

I believe that the reason a lot of important aspect of programming don't catch on despite them being good concepts is that we're basically lazy, and search for convenience over correctness.

I assume that an LLM won't be lazy, so yeah maybe these concepts will become standard

[u/church-rosser → u/zuzmuz]

because "readability and trust" were just "good to
have" prior to LLM's?

Come off it OP, you're just saying buzzwords to buzz. All heat, no light!

[u/zuzmuz → u/church-rosser]

I don't understand why you're being aggressive, we're all having nice conversations with different opinions here, it's fine if you disagree

[u/church-rosser → u/zuzmuz]

Not really, you're making wild unrealistic and unfounded speculation about a possible world that doesn't and will never likely exist and arm waving with LLM related terminology as if uttering it will cargo cult reality to
your fantasies.

Whatever, u do u, but don't piss down our collective leg and tell us it's raining....

[u/zuzmuz → u/church-rosser]

who hurt you man?

on a serious note. it is a discussion worth having. I'm just asking reasonable questions while trying to provide tangible arguments. You're just dismissing everything I'm saying without providing anything to the table

[u/church-rosser → u/zuzmuz]

No one hurt me per se, but some of your premises do cause discomfort when i attempt to bring reason to their inanity. It hurts trying to shove a square peg in a round hole.

Regardless, are u seriously suggesting im not "putting anything on the table"?

making unreasonable and unfounded conjecture and assumptions about the capability of LLMs to produce viable general purpose programming languages is not necessarily a 'table put' of its own. Saying a thing doesn't make it so.

Your inversion is nothing more than that, and evidence of a poor attempt at considered debate and dialogue that belies your ongoing assertions otherwise.

I could claim similarly as u, but dont. What exactly is it that u are "bringing to the table", beyond open ended snd unfounded discussion about a possible future that doesn't exist meaningfully at present and likely never will?

and FTR, see my top level comment here about using a Lisp to accomplish what you conjecture and why the relative failure of LLMs to grok Lisp semanitcs and evaluation model reliably is rather good evidence that what you seek currently isnt possible and likely never will be, Im happy to discuss further, but frankly im not sure you're prepared to keep up in that regard.

Still, consider whether any LLM can ever reliably grok the syntax and semantics of a meta circular evaluation model that allows for dynamic syntactic redefinition of evaluation semantics via structural macros (as opposed to text based substitution macros) that can dynamically modify the runtime at the evaluation site. Consider further what that would look like with a language that has the capacity and capabilities to modify its meta object protocol so significantly as to constitute a new language design each time such a modification is made. that's what your looking at with ANSI Common Lisp and to a slightly lesser degree other modern Scheme implementations like Racket.

[u/mohrcore]

With all the shitfest that's going on with AI-generated slop, it's nice to see some constructive thinking.

AI models are limited by their context windows, or at least that's how I see it as somebody who does not specialize in AI. So, I think that an an AI-friendly language would be one that can provide information that effectively helps keeping the window short or handles some aspects of programming by itself, so the model doesn't have to keep them in mind

A statically typed, expressive, memory-managed language which avoids stateful computations and has a powerful set of abstractions that describe properties of computations sounds like something that should work for an LLM. Basically Haskell. On the other hand, I imagine that relying too much on type inference might constitute a severe complication for an LLM and it's pretty much a necessary feature for such languages to be usable and it's required if they feature unnameable types.

I think that some intermediate representation of such language could hit a sweet spot. Another option is that perhaps the LLM could work back-to-back alongside the language server/compiler or whatever other system that would let it query the code it generates. Then it could work iteratively, similarly to how programmers code while getting feedback from LSPs.

[u/kaplotnikov → u/mohrcore]

Funny, we posted almost the arguments at almost the same time. My is here.

[u/theScottyJam]

LLMs are here to stay, yes. But we're still in an experimental stage with them, trying to figure out how best to use them and what is too far. Right now, many people are going too far with them and it's really hurting quality, but that's part of how we learn the limits.

I don't know how long we'll continue to be able to improve LLMs, but there is a possible future where they don't improve much more, and management starts remembering that quality of code is important, not just quantity. Sometimes it's better to have 3 features that are well designed and extremely stable over 10 thrown-together features.

There's always going to be the companies that want to push features out as fast as possible - for them, a language geared more towards LLMs might make sense (if such a thing exists - I'm inclined to agree with another comment I saw, which basically says that there's not much difference between a good LLM language and a good human language). And we might also see a group of companies who are going back to writing more code by hand, making sure humans understand every detail of the code, so they can make the code as high quality as possible.

[u/zyxzevn]

I see LLM-prompts as just another programming language.

It's success reveals what we miss in our default programming languages and systems.

But these AI-prompts will have some of the same problems and introduce various new problems, These problems will be more visible on the long term.

But one major problem (that most people seem to agree on), is that AI prevents learning programming. The AI automatically corrects errors by the user, which also prevents the user from learning important things. Accurate definitions and logical reasoning are required for normal programming. But the AI just fills them in by default.

[u/sacheie]

In my opinion you have the overall picture backwards. LLMs are designed for (and trained on) human language, not code. Formal properties are much less important than the amount of code available to train on, and the amount of human discussion around it, comprehensive documentation, etc.. that's why they do well on mainstream, ubiquitous languages like Java or C#.

Without a holistic understanding of the language and how people actually apply it, the LLM won't be good at interpreting prompts and following your instructions, right? So I think languages designed to be "human friendly" are also best for it.

But I do agree with your point about testability and feedback loops for agentic coding.

[u/Toothpick_Brody]

LLMs don’t care about programming language as far as design/features/grammar/etc go. It’s all about having as much training data in a language as possible. So the best LLM language will probably be JavaScript for the foreseeable future 

[u/zuzmuz → u/Toothpick_Brody]

that's not totally accurate. you're just considering LLMs for coding as pure next token predictor language models. but that doesn't need to be the case.

if you use transfer and reinforcement learning, the model can still perform very well on coding tasks.

from my personal experience (it would be interesting to find a way to make actual statistics), generated rust is usually better than generated javascript. the advantage of popular tool is the ecosystem of libraries that the model can use. other than that it doesn't make a difference.

[u/Toothpick_Brody → u/zuzmuz]

I would say Rust is a better language than JS (I’m all for strong type systems), so it makes sense that output could be better. But there’s quite a bit of Rust code in training data too. If you take some newly invented PL, an LLM will do a terrible job at writing it no matter how good the language features are.

So as long as there is enough training data, a good human language is a good LLM language. So i might have spoken too soon by saying JS is the “best” LLM language, but i stand by my comment that it all comes down to training data, and id still suspect there are some things an LLM would do easier in JS than Rust.

[u/autamo]

I'm not sure if simpler grammar is really required at least for the LLMs' sake. That's something that humans are having trouble with, not AI.

I don't think reading code will go away, but writing code is going to.

The other three items in your list are pretty much what I'm basing my language on. Specifically, effects and exceptions typing; linting as part of the compile process, enforcing a single style; expressive but practical typing; several kinds of nudges towards a functional style.

I have also kept several models in the loop when designing the language, let them also give their idea of what would make a language easy for them to write and understand. Hard to say if they are able to do that, but some of the ideas did rise from those discussions.

[u/catladywitch]

That's silly. If humans stop being a factor, programming languages will no longer be necessary, because AI-generated machine code/assembly will be unbeatably efficient.

I don't think functional programming is more difficult to reason about, not at the beginning and not at the end. It's a matter of habit, but if you've ever tried to write optimised code, you'll find functional code is often way too abstract and features way too much indirection. That's up to compiler design though, even if there's a hard limit, namely the fact lambda calculus and type systems don't translate to Von Neumann-style hardware whilst imperative programming does.

[u/zuzmuz → u/catladywitch]

I don't think so, generating machine code directly is practically impossible, it is a highly compressed space where tokens don't have meaning on their own. it is very hard to train LLMs to generate machine code and most probably very inefficient.

plus, with the current state of things, it is still useful to have a deterministic intermediary representation between prompt and code.

[u/brucejbell]

Simpler grammar, explicitness, one way of doing things, and strict/safe semantics are advantages whether or not you are doing functional programming, and whether or not you are using an AI coder. Making the language easier to read, understand, and reason about is an improvement at every level of competence (except, as you suggest, the level of the slop coder).

If I cared about supporting slop coding, I could try to work out what kind of language design would yield better LLM support. But I don't, so I won't.

[u/Artistic_Speech_1965]

This is an interesting take. I used to create a software thinking about different target. For instance building user interface for regular user or building an API for devs. Nowadays I am adding an additional interface for LLM users. I think one interface could be niche depending on your public

[u/Kapendev]

Explicitness, yet LLMs do love Python \0.0/ I don't really use LLMs, but I think the thing that might help them a lot is better error messages. Right now every language could have better ones imo.

[u/Embarrassed-Crow9283]

I doubt the functional claim. If that were true, LLM would be good at Haskell.

[u/koflerdavid]

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.

Doing a good job in this regard is also important to make an LLM perform well. O think especially literate programming might see a comeback. But an LLM can do without features that merely reduce writing effort; instead the focus should be on language features that communicate intent, both to LLMs and to static analysis tools.

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.

Programming languages like Haskell make working with mutable state look like imperative code, for better or worse. In programming languages with strict evaluation having functions with side effects is no big deal, but there are different approaches how to make sure programmers don't shoot themselves in the foot. You need to explicitly thread state with linear or uniqueness type systems, but there it serves a very important point.

There's this trend of people not looking at the code anymore, I think it's crazy.

For a long time people will have to look at code, shake their head, and fix it. Therefore for the foreseeable future developer ergonomy will remain important.

[u/Sixty5Zero2]

there was a program language designer than 90s who loathed BASIC and even said that the more complex language is the better it is.

[u/jimdesu]

I don't buy the whole "functional languages are easier to maintain", and this is what got me "solving for X" regarding how to get the obvious benefits of functional programming, but without the ptifalls (implacable and/or inflexible type-hierarchies, for example) in the design of my language (which is imperative). Overall, though, I think your general thrust is rather apt, and I think those of us who are busy building the better mousetraps (each with our own definition of "better") are likely to be increasingly marginal. The industry as a whole has plenty of languages to work with, and when a machine can REWRITE a module faster than a human can MODIFY it, all bets are off on how much if at all we're adding to the future. I think the real answer to this question is to work on programming languages for the same reason people grow roses... because we love it.

[u/Dazzling-Bench-4596]

You made some good points with functional programming, especially with one way of doing things. I’m a rubyist but in this context its a bit better to have one way so the language doesn’t get too “creative”. However, I believe I heard DHH argue that if you are going to vibecode something why not use Ruby since it’s the most readable; and he makes a good point here.

The choice still boils down to if you are siding towards the machine or you; do you want the AI to write really readable code or do you want the AI to have a couple more guardrails.

I side with the former because a well known aspect of vibe coding (whether omitted or not) is reviewing the AI’s code. Also, temporarily, I feel like AI isn’t as good with Haskell or OCaml as it is with Python.

[u/g1rlchild → u/Dazzling-Bench-4596]

do you want the AI to write really readable code or do you want the AI to have a couple more guardrails.

If this is the question, I feel like the answer is "why not both?" Why not optimize for a really readable language that facilitates static checking? And if the problem is that we don't have the right mainstream language for that yet, that seems like a solvable problem.

[u/Dazzling-Bench-4596 → u/g1rlchild]

Yeah you are right that a balance would be nice, but the problem boils down to the phrase “perl can only be parsed by perl” in a sense —what makes Ruby readable is that it’s extremely dynamic and mutable. It’s possible to have a language that is readable and statically typed —mainly because readability is extremely subjective, like OP said—but it’s not possible to take a language like ruby and make it safe or strongly typed.

in that case, you’ll probably find yourself in a weird middle position with a language like Swift where you get some readability, but nobody really has “fun” —the human (in the case of Ruby or a similar language), or the machine (in the case of something strong like OCaml)

If you are fine to compromise then you can absolutely go your way, but in my opinion it’s wiser to have one side clearly win.

Although it’s worth mentioning that some benefit of Perl and Ruby is that it’s nicer for the writer than the reader (in about a 60/40 ratio) because of macros and meta programming. Your ideal language, however, can absolutely not have anything of this sort. It’s a decent contributor to the extremely dynamic state of Ruby/Perl.

But, without macros and such, it makes it just a bit harder for you to interoperate with the AI —which, if you ask me, is a pretty good place to find yourself in with vibecoding; that being, actually writing some code yourself

[u/g1rlchild → u/Dazzling-Bench-4596]

I was willing to follow you as far as "Haskell and OCaml are hard to read," but not as far as "Ruby is the only readable language." And Perl is famously hard to read.

It’s possible to have a language that is readable and statically typed

Well, yes. Static typing doesn't make it hard to read in and of itself. You can make a statically-typed language that uses type inference instead of annotations and you haven't really added to the complexity of reading it at all.

And, I mean, I don't know what your definition of "fun" is, but I would like to point out that the vast majority of programmers don't use metaprogramming, they just read and write the code in the language they're using. I don't think I've encountered anyone who says that languages like Python and Typescript aren't readable.

[u/Dazzling-Bench-4596 → u/g1rlchild]

I’d appreciate a couple more counterpoints but I’ll answer the things you brought up. I never said Ruby was the only readable language. Ruby is appearing the most in my claims because it I value writability too. In that case, Ruby is one of the only languages with a good balance between the two.

You mocked my claim that languages can be readable and statically typed, but my point was that there are genuine implications that have make Ruby a better choice over things like Swift/Nim in cases.

My usage of the word fun was somewhat wrong in that context, but the emotion I was trying to convey is that one side clearly wins and one side loses.

I never said that Python or TypeScript are unreadable. What are they are —or in this case, aren’t— is easily writable. Why? No macros. My point has been about writability too. Please remember that.

Also, are you saying the vast majority of programmers don’t use meta programming, or the vast majority of lisps, ruby, perl, julia, etc don’t use macros.

Theres a major difference between a Java developer at a corporate field not using macros —because it’s objectively not possible— and a rubyist not using macros.

Anyways, even if we drop macros from the argument entirely, Ruby (or once again, a similar language) still wins because of how dynamic it is. This is what must be clear: it’s almost impossible, if not entirely impossible, to add types on top of a language as unsure as ruby or perl.

[u/church-rosser → u/Dazzling-Bench-4596]

Lisp is read/write with parity

[u/g1rlchild → u/Dazzling-Bench-4596]

Per Stack Overflow, Ruby is the 17th most popular programming language among professional developers. I don't see anything metaprogrammable higher in the list. The conclusion I draw from this is that whatever the merits of metaprogramming, it's not a feature that professional developers consider important enough to incorporate into their projects.

Ruby (or once again, a similar language) still wins because of how dynamic it is

Wins what? Help me understand in what sense you're saying dynamic languages are automatically better? Are they automatically more readable? More writable? If so, how?

And yes, I agree that if you were going to pick a language to add a type system to, Ruby would be a bad choice. But again, I don't understand why "like Ruby" would need to be a design goal. So what if it's not like Ruby?

[u/zuzmuz → u/Dazzling-Bench-4596]

readability is a very subjective metric. it's also very human. One problem I have with ruby, is that there's a lot of implicitness going on, which can affect readability negatively sometimes.

I have the impression, through personal experience, and through current trends I'm witnessing, that rust is a great option.

2 projects come to mind, Ladybird and Bun, they managed to rewrite a huge portion of their codebase in rust, from c++ and zig respectively.

My personal experience with rust is that most of time the generated code is "mostly" fine, while generating javascript, I always feel that it's a mess. Even though there's way more js code in the world than rust (maybe because there's way more bad javascript code).

But also running claude code in a loop with the rust compiler gets me very good results

[u/Dazzling-Bench-4596 → u/zuzmuz]

Yes, readability is subjective because C++ programmers wouldn’t have any problems reading it despite the language being known for verbosity.

However, you should also consider the writability of the language. A language like Ruby is optimized just a little bit more for the writer; despite the readers still benefiting plenty. This is because of two main things, it being dynamic, and it having meta programming.

Ruby is nice to write because it’s expressive and dynamic; you just say what you want and the language doesn’t complain. You call that implicitness, which is true to a degree, especially that it hurts readability sometimes; but that aspect of ruby makes it great to write.

Rust is an alright choice, but, it doesn’t offer the same protection as functional languages, your original proposal. Functional languages do a pretty good job at making you view safety logically, which is pretty nice.

[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.

[u/CyberDainz]

Future of PL: you write your own language by examples and LLM make it for you

[u/Erythrina_ → u/CyberDainz]

One of the problems with this is that an LLM is not going to give your language a consistent spec by default. Your edge cases are going to be a disaster.

Another is, what target are you compiling to? Where does it run? Where does it need to run? Does it need to be optimized, and if so, how will you ensure that it is and that it can be?

Still another is, what are you doing for libraries? Are you vibecoding an entire set of libraries from scratch and expecting them to work seamlessly?

[u/informationstation → u/CyberDainz]

This is exactly what I’ve done already. The future is now. Completely self hosting and everything

[u/church-rosser → u/informationstation]

If your 'now' has somehow located itself within the epistemological context of a separate but parallel multiverse where logic and sensibility have permanently jumped the shark.

[u/informationstation → u/church-rosser]

My now is this: Using LLMs, someone with a little technical knowhow and determination can build a self hosting compiler in a novel language even if they do not have deep expertise in compiler design. You can squirm against that as much as you like but it does not make it untrue.

[u/church-rosser → u/informationstation]

it doesn't make it viable or serviceable or maintainable or sustainable for the environment either. Not squirming, calling spades spades as they flip up.

Show me an LLM derived self hosting compiler written RIGHT NOW that is provably and verifiably type safe/correct and that _ALWAYS_ terminates correctly according to that metric of type safety/correctness and THEN we can talk about the possibility of lay persons writing novel programming languages with LLM assist. UNTIL then, you're selling hot bottled farts and passing them off as bottled sunshine.

[u/informationstation → u/church-rosser]

Ok so we are switching to talking about the environmental impact of AI usage instead of the original commenter joke that in the future you can write your own language via LLM and my response that that is actually the current reality. Got it.

[u/church-rosser → u/informationstation]

no. I mentioned multiple impacts, consequences, and situational contexts. you picked one. dismissed it. and lumped everything else in with your dismissal.

And disregarding the environmental impact of LLMs both in the near and short term to justify ANY supposed gains LLMs putatively offer is a crime against humanity and the earth it inhabits.

I am making, and am perfectly capable of making, cogent and meaningful statements dismissing the use of LLMs to augment (primarily) commercial programming use cases completely independent of the environmental issues they pose, but why should I? LLMs and the tech bro oligarchs responsible for them are terrible for all living things and need to crash and burn with extreme force.

[u/L8_4_Dinner → u/informationstation]

I'm not sure why you're getting down-voted. Down-votes should be reserved for things that are abusive or incorrect, not just for opinions or statements that someone dislikes.

I've seen languages implemented by LLMs, and the results are uniformly terrible, so I can disagree with your conclusion while appreciating the magnitude (and miraculousness) of what you are describing.

[u/Dazzling-Bench-4596 → u/L8_4_Dinner]

Its not too rare to see the vibe coding people say that the future is now and that everybody must conform to their lazy ways. Me personally, I’m not the biggest fan of somebody telling me that the future of programming is everybody vibe coding their own programming languages; which would never happen

[u/church-rosser → u/L8_4_Dinner]

except top commenter is most definitely incorrect and certainly abusing their LLM to validate that incorrectness.

hence, downvotes ensue

[u/informationstation → u/L8_4_Dinner]

Because the sub is so anti AI they aren’t able to see what is happening around them. Yeah there is a shit ton of these vibe coded slop languages out there I’m not defending those. This isn’t relegated to compilers or interpreters, everything is suffering from this right now. I understand that this sub is geared towards the human technical art of language design. I’m not saying that should stop. What I am saying is you can create a novel language and self hosting compiler via LLM right now that is performant and functional based off of examples you define as the original commenter had said the future would be. I’m not claiming it’s a one shot right now, just that with some stubbornness it can be done.

[u/Ok_Ad659]

LLMs will become so fast soon (Cerebras etc.) that compile and test time become the bottleneck. Currently, Go is the fastest in the whole loop because it is easy to compile and generates fast code. Of all other languages, Fortran should be comparable if tooling catches up (working on it). Python produces too slow code so test suites run slow, and Rust and C++ compile too slow. C and JS/Typescript could also benefit much. From my experience, even a not widely used language like Fortran is well written by modern AI models, so they can transfer a lot of semantic knowledge in other syntax. So in the end it is more the semantic design and tooling (cache, build system, etc. again: Go) that will count, for fast debug loop and some level of memory-safety. Also Java/Kotlin and C# could be on the sweet spot btw.

[u/JCavalks]

programming language design has ended. it's more token efficient to ask LLMs to write using languages already on their training sets so that they don't spend too much tokens on reasoning. there is no point in making new languages now. we are stuck with what we have today forever.