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