Naive question: why do we care about programming languages when we no longer read programming languages directly? Shouldn't we either design languages optimized for LLMs? (needs fewer tokens, easier for bots to process, easier to machine verify, not sure what else)
We do still read code. Most people are not doing a fully unseen development strategy because we have needs around efficiency, security, compliance etc and we can’t simply blame it on our agents like we don’t control them like OpenAI do
Who's this "we" you speak about. There is a small subset of programmers who have become effectively become managers and ask their AI employees to do things. The rest of us still regularly read and write code.
I’d love to see some numbers on this, but this is not my impression from the communities I participate in (such as the Elixir forum.). Amongst programmers who are employed, I suspect it is a majority at this point who use agents to write code. It is hopefully a small minority who never read code, but it’s certainly growing.
I mean, even if you've stopped even reading code (good luck with that), the right abstraction should make things things easier for the LLM. A good rich type system to stop incorrect code, linters to catch common errors. A good set of battery-included system libraries. BEAM should provide a good abstraction for highly parallel and distributed systems, which means the LLM doesn't need to build all those abstractions itself. If you're building a distributed system, it should be like providing a set of good guardrails, guiding the LLM in building a correct system.
I've seen even the best models try to build & debug parallel and distributed systems. The results are always a bit uneven at best, even with a good harness and a lot of guidance.
The disadvantage of niche languages is that the LLM won't quite know the language as well due to less training data being available. But if you actually need to build something distributed, then this might be a good trade-off.
We might still read them, but let’s set that aside. Some languages may offer ways to eliminate entire classes of bugs. Gleam and Haskell-ish languages do that through very strong type systems and expressive high-level functional constructs. Rust similarly eliminates a ton of memory errors through its borrow checker. LLMs aren’t infallible, so this can result in better quality code (or if you believe every bug will still be caught…less code to do it).
Gleam also runs on BEAM, which has important runtime characteristics vs other languages. That will impact your system and how it scales even if you never look at the code.
For what it's worth, I still parse code changes and feel uncomfortable if I struggle to understand code output without assistance.
On the "languages for LLMs front", isn't that a bit "cart-before-horse"? Doubt we are anywhere near the limit of what a model could do with a static verifiable language, even more so since stuff like TS has massive training data, any new language wouldn't benefit in such a way.
Add to that, I'd rather be able to understand the output, partly for aforementioned reasons, partly because we have seen with post Spud GPT reasoning traces what happens when being able to read model output becomes even slightly harder. Having model-focused languages would only exacerbate such issues.
Even in an AI intensive workflow, reading code remains a huge quality gate and I'd be wary of any software which hasn't been reviewed by humans.
Moreover, to me coding carefully is still a hobby, a pleasure, a craft. Gleam is exactly the kind of language that makes this such a pleasant activity.
> why do we care about programming languages when we no longer read programming languages directly?
Because, we do?
You may not, which is fine. A lot of developers may not... that's fine. I guess you're all employed and don't risk your livelihood when things go wrong.
I do though. I take responsibility.
And just like with any junior developer I guide AI and I do review what it creates in the project that matter. (Personal tools I've entirely vibe-coded, never any client projects though)
I never liked currying. It feels more theoretically elegant than practically useful.
IMO it is hard to read (unless you're very familiar with the functions at hand), produces type errors that are not easy to follow (oops, I forgot the last arg), and is often too rigid (I keep needing to partially apply arguments in non left-to-right order).
I never understood why partial application via "slots" isn't more common though (I just made up the term, not sure if this has a name). Like Clojure's #(f % 1). Does Gleam have something like that?
I think the single hole version is a good compromise compared to actual currying or multiple holes, since it's strictly better than something like first or last argument threading (e.g. ->, ->> in Clojure), easier to reason about than currying, and in my experience most of the time you'll only be dealing with one argument to pass piping anyway. Anonymous functions are fine for the cases you need more flexibility.
As I mentioned in my other comment, they do have partial application with _, and it works like a charm for piping!
It's automatic currying which is absent.
To your point on "Gleam: the bad" and the ecosystem being small, I would add that this community has a history of activism behaviour. Some like that, I'm out.
I don’t have a problem with activism per se, but it does put me off how the official website tries to make the language and community look extremely friendly and cutesy, only to immediately break that facade. If that’s the look you’ve decided to go for, at least try and commit to it!
> "Contribute to their codebase" includes bug reports and seeking help with errata and other issues.
That is exceedingly rare. The vast majority of times you will either find your answer online to work your way around issues.
> It might be problematic to use a language where needed help could be preceded by Twitter or HN background and allegiance check.
I would remind you that we have LLMs now. One of the greatest gifts of LLMs is not having to rely on talking to people online to figure out issues when using a language/framework/library.
Both searching for answers online and consulting LLM’s depends on prior human works or interactions, and (from what I know) their feasibility scales with the language’s popularity. I should expect both approaches to work much more reliably for Perl or Python than they would for Gleam or Newlisp.
I have a web app i've been using regularly and develop regularly with gleam on the frontend and backend. I have written very little of the code by hand and use claude to implement everything, open PRs and stuff and it works well. I like that it's typesafe and you can share code between the frontend and backend so easily, and you don't have to get a bunch of config right like you do if you want an all-typescript application. If I was writing it by hand I think I would find there's an annoying amount of boilerplate, but since ai is writing the code for me it's not a big deal.
Programming models have been sophisticated enough for some time to not be restricted to specific languages. It's rather like the difference between a junior developer (who knows how to use a specific language) and a mid developer (who knows who to program generally).
Is there any research that supports what you are saying here? I agree it mostly works, but I’d expect more API hallucinations and test cycles at a minimum.
That mindset is a bit dated when models can pull up docs for a few years now. You can even have it write itself a little guide for lesser known languages within its own agents file.
In that Tencent study less common languages got easier problems. Which explains why racket also performed suspiciously well in it. The authors recognize the problem themselves. I like elixir, but it's imo embarrassing how often elixir people cite that study despite it not actually supporting what they claim.
That showed about what we expect, that popular languages like python, javascript, java, C#, etc do best, while less popular languages like Common Lisp, Ocaml, Zig, etc do slightly worse. But the difference is small enough I'd still just choose whatever language and ecosystem I know best that is appropriate for a project.
I would definitely be skeptical of a study that finds using an LLM/agent to write sqlite in JS being better than writing in Zig, but it strongly depends on what “better” or “worse” mean.
It means how much of the sqlite test suite it passed. They were just measuring correctness, not performance or memory consumption, where of course Zig should win.
But the aim of that experiment was measuring correctness of llm written code in different languages, so used sqlite as a benchmark considering it's fairly complex software with a comprehensive test suite. It is not suggesting that because a language scores better on that benchmark it'd be better suited to writing the next sqlite, due to obvious other factors like performance...
Exactly the opposite -- in a lot of ways, mainstream languages represent a compromise that gives the worst of all worlds for the benefit of popularity. With AI, you can take advantage of unpopular esoteric languages that have measurable advantages over mainstream languages. Before, the choice for a mainstream language was too strong because of network effects. Now with AI those effects don't matter as much, so being mainstream isn't as much of an advantage.
The copious training data on mainstream languages doesn't really translate as a network effect, and therefore is kind of a red herring because the AI can use all that training on new languages as well. e.g. if you use a esoteric language that is vaguely object oriented, the AI will use its vast training on object oriented programs and apply it to your language instead of falling over because your language isn't Python and it doesn't have training data on it.
Moreover, the AI is trained on copious amounts of PL research, so it's not like the ideas in a new language are completely new to it.
this is what grinds my gears with gleam. afaik its not really possible to interact with elixir libraries? A project exists to try to make this 'easier' but the fact that it was not baked-in as first class is a huge smell to me https://github.com/gleam-lang/mix_gleam/
Perfect example: Clojure. Clojure is the textbook esoteric programmers dream... but it's SUPER easy to sell and integrate in a typical Java shop. Why? Clojure is Java. You can use everything on Maven. You can interop with any Java tooling. No hacks or BS required... it's a native compatibility. The fact that the Gleam did not opt for this level of congruence is mind boggling to me.
I could be wrong btw so please correct me if I am. I am genuinely interested in using Gleam in place of Elixir (I think they nailed syntax and got rid of a lot of bullshit) but it is unfortunately not a drop-in replacement. It should be.
Only if they gain that ergonomic advantage without complicating flow of control. Metaprogramming is costly for example, in the past so have been operator overloading and lazy evaluation.
61 comments
[ 0.32 ms ] story [ 76.5 ms ] threadI've seen even the best models try to build & debug parallel and distributed systems. The results are always a bit uneven at best, even with a good harness and a lot of guidance.
The disadvantage of niche languages is that the LLM won't quite know the language as well due to less training data being available. But if you actually need to build something distributed, then this might be a good trade-off.
https://static0.cbrimages.com/wordpress/wp-content/uploads/2...
Gleam also runs on BEAM, which has important runtime characteristics vs other languages. That will impact your system and how it scales even if you never look at the code.
On the "languages for LLMs front", isn't that a bit "cart-before-horse"? Doubt we are anywhere near the limit of what a model could do with a static verifiable language, even more so since stuff like TS has massive training data, any new language wouldn't benefit in such a way.
Add to that, I'd rather be able to understand the output, partly for aforementioned reasons, partly because we have seen with post Spud GPT reasoning traces what happens when being able to read model output becomes even slightly harder. Having model-focused languages would only exacerbate such issues.
Moreover, to me coding carefully is still a hobby, a pleasure, a craft. Gleam is exactly the kind of language that makes this such a pleasant activity.
Because, we do?
You may not, which is fine. A lot of developers may not... that's fine. I guess you're all employed and don't risk your livelihood when things go wrong.
I do though. I take responsibility.
And just like with any junior developer I guide AI and I do review what it creates in the project that matter. (Personal tools I've entirely vibe-coded, never any client projects though)
Missing currying feels a little to me like walking in FP land with one leg cut off.
IMO it is hard to read (unless you're very familiar with the functions at hand), produces type errors that are not easy to follow (oops, I forgot the last arg), and is often too rigid (I keep needing to partially apply arguments in non left-to-right order).
I never understood why partial application via "slots" isn't more common though (I just made up the term, not sure if this has a name). Like Clojure's #(f % 1). Does Gleam have something like that?
See the relevant docs: https://tour.gleam.run/everything/#functions-function-captur...
Seems more limiting than the closure way. Scala allows multiple _ but in turn that doesn't allow changing ordering.
TBH, I feel this stuff is not really worth it,
Plenty of practical reasons for currying, but the biggest (imo) is for use with the pipe operator.
If they don't have partial application now, what are the odds they'll have it in the future?
Do you only use languages that you can contribute to their codebase?
It might be problematic to use a language where needed help could be preceded by Twitter or HN background and allegiance check.
That is exceedingly rare. The vast majority of times you will either find your answer online to work your way around issues.
> It might be problematic to use a language where needed help could be preceded by Twitter or HN background and allegiance check.
I would remind you that we have LLMs now. One of the greatest gifts of LLMs is not having to rely on talking to people online to figure out issues when using a language/framework/library.
Overall, I recommend it.
Is there any research that supports what you are saying here? I agree it mostly works, but I’d expect more API hallucinations and test cycles at a minimum.
A much more recent and imo more realistic comparison of different languages with ai, is openai's study reimplementing sqlite in different languages: https://openai.com/index/low-resource-programming-languages/
That showed about what we expect, that popular languages like python, javascript, java, C#, etc do best, while less popular languages like Common Lisp, Ocaml, Zig, etc do slightly worse. But the difference is small enough I'd still just choose whatever language and ecosystem I know best that is appropriate for a project.
But the aim of that experiment was measuring correctness of llm written code in different languages, so used sqlite as a benchmark considering it's fairly complex software with a comprehensive test suite. It is not suggesting that because a language scores better on that benchmark it'd be better suited to writing the next sqlite, due to obvious other factors like performance...
The copious training data on mainstream languages doesn't really translate as a network effect, and therefore is kind of a red herring because the AI can use all that training on new languages as well. e.g. if you use a esoteric language that is vaguely object oriented, the AI will use its vast training on object oriented programs and apply it to your language instead of falling over because your language isn't Python and it doesn't have training data on it.
Moreover, the AI is trained on copious amounts of PL research, so it's not like the ideas in a new language are completely new to it.
Perfect example: Clojure. Clojure is the textbook esoteric programmers dream... but it's SUPER easy to sell and integrate in a typical Java shop. Why? Clojure is Java. You can use everything on Maven. You can interop with any Java tooling. No hacks or BS required... it's a native compatibility. The fact that the Gleam did not opt for this level of congruence is mind boggling to me.
I could be wrong btw so please correct me if I am. I am genuinely interested in using Gleam in place of Elixir (I think they nailed syntax and got rid of a lot of bullshit) but it is unfortunately not a drop-in replacement. It should be.
https://gleam.run/frequently-asked-questions/#Can-I-use-Elix...
F# showed a lot of promise with Fable, but the community never quite got the tooling right, I think for a lack of energy/funding.
There are a few rough patches too. For example, I have yet to find out how to run a single test and not the whole suite.
https://carolina.codes/speakers/2024/dillon-mulroy
That site is also partially powered by Gleam on the backend.