We’ve repeatedly moved to higher levels of abstraction: from assembly to C and C++, then to languages and managed environments such as Java and C#. The lower layers didn’t become useless, but fewer developers needed to work with them directly. Could AI represent another such shift not just abstracting away the machine, but abstracting away much of the act of writing code itself?
If agents eventually write and maintain most of our software, perhaps the important question will no longer be “Which language do humans enjoy working in?” but “Which language allows agents to produce reliable software most effectively?” Those might not have the same answer. I can imagine future languages being designed primarily around agents’ ability to generate, verify, and modify programs, rather than around human preferences.
From that perspective, I sometimes see Haskell and other languages celebrated for their elegance as something that could gradually become a form of traditional craftsmanship: valued for their beauty, intellectual depth, and the skill involved, but with a diminishing role in everyday software production. Not because the craft has lost its value, but because the way we produce software has changed.
This has already been discussed to death, but briefly:
Haskell has a pretty strong type system, and is mainstream enough to have decent libraries and tooling. This balance makes it arguably the best target language for LLM codegen right now.
Plenty of people here are highly sceptical of a lot of the claims flying around about LLM capabilities in the first place, particularly for producing quality software that’s maintainable in the long term. So the way we produce software hasn’t necessarily changed all that much.
Haskell isn’t just beautiful aesthetically. It compiles rigorously to System F. It is statically typed with potential for dependent types and effects (among other things). It is highly composable with a unique composition language (typeclassopedia). It is highly symbolic and a lot more information dense than English.
That last point is especially relevant in the age of AI. There are plenty of times where writing Haskell is more efficient than a prompt and waiting on a model. Strictly more efficient. There’s no trade-off in these cases. You can get faster and better output.
From direct experience at work: yes. Agents often have to be given a lot of guidance to correctly follow idioms and architecture vs. just spamming whatever will fulfil the immediate request. A concise language gives you a better shot of understanding what’s been generated if it’s got away from you and spammed pages of code everywhere, and a language with strong types makes it harder for them to punch through your careful architecture to get the job done. Justin Le’s recent post on constraint-evading behaviour discusses this.
If insufficiently careful use of agents makes your codebase 1% worse on each change, say, then it’s not that many rounds before the whole thing is hanging together with duct tape and String.
100% it still matters. Scam artists and forgers have existed for millennia, and the Thief Machine will always need someone to steal from.
My work is sufficiently niche such that AI regularly cites my own material at me without knowing I am the author, so the better work I produce, the easier time I have of it. However, such blatantly obvious theft means I am also taking steps to limit my current work’s exposure to AI because such theft has left me without permanent employment, and nobody wants to pay for my work if they can just scan my repos and ask the Thief Machine to do it for them.
The beauty of deeply effective programming is something AI will have immense difficulty replicating without either having a good data set or actually being AGI. Programming is how I order my thoughts, and modern AI do not have “thoughts”.
I’m actually not quite sure. Ignoring the broader LLM discussion, my feeling is that it’s either something stronger than Haskell (Lean), because it allows greater constraints, or something weaker (Python), because it’s better to train on.
So to me Haskell sits in a niche that caters more towards human written software.
Writing code is only one part of the story. Reading code is another part. Sometimes reading / debugging code takes longer than writing it.
C made it easier for humans to also read C code, compared to reading ASM.
I am not sure how humans using AI to produce code, are supposed to collaborate on a project. Their interaction is likely to be shallow because of participants’ limited understanding of the result. Participants’ impact on the result is likely to be minimal, too.
The family dinner scene from “Back to The Future” springs to mind :
The inverse also happens from what i’ve seen. If AI is used at scale on a codebase, that codebase quickly becomes more and more hostile to human contribution. LLMisms are everywhere. Little things that don’t make sense that didn’t get caught are littered about the codebase misleading and distracting you. People now don’t care about readability or even understanding of certain things became they assume LLMs will be the only authors of those files
Ensloppification is real! The cost in tokens alone is pretty staggering, but the real cost (a bad codebase) isn’t even felt yet. That happens slowly over years.
Trivial apps have been increasingly easier to develop over time. Releasing a static website 30 years ago required a large investment upfront, but now you can deploy a vastly superior experience for free.
Complex systems, on the other hand, have been getting more complex, and thus more difficult to maintain. You cannot remove complexity, just move it around with abstractions.
Designing complex systems still requires deep understanding of the problem and the abstractions used to encapsulate complexity. Haskell is an amazing tool when it comes to represent abstractions, so it keeps being a great tool to rely on when tackling hard engineering problems.
Beauty is something an artificial agent can not experience, but you can. If beauty matters to you, then even a diminishing role in “everyday software production” does not matter. (It may matter to our community as a whole, because we must worry about resources being diverted.)
They will certainly not be writing any of the programs I code for the sheer beauty of casting mathematics into a rigorous form.
If I had let an AI agent write my assembler / printer code for me, I would never have the satisfaction of answering the question myself (eg of ()-nil vs []-nil and does the zero-tuple exist) - I would not even have been present to ask such a question in the first place!
AI certainly helps with code volume, but we don’t determine the best art and artist by who can chuck buckets of paint the fastest. Programming is an art, it is no different.
It’s not just about the language but also the language tooling. If you want to iterate quickly with LLMs, you need fast build times. If you want to do development with local models, you need tooling that uses as little memory as possible (to leave as much as possible for your local model)
I think we can have our cake and eat it too. These agents are good at generating hundreds of thousands of LOC to make a single application. The problem is this makes the codebase so large that one almost is forced to use LLMs for all subsequent edits and updates of the application, ensuring LLM vendor lock-in.
I think a sweet spot is to make a DSL (or layers of DSLs) in Haskell and have the LLM generate various applications using the DSL terms. This tends to result in much less LOC and allows human intervention where need be. This can also be very efficient if you newtype FFI types for example (in your DSL). The LLM can also find odd edge cases in your DSL that would otherwise go unchecked.
This allows one to “scratch the programmer itch” but also to take advantage of all the benefits of an LLM in your respective domain.
This is essentially what was done with miso, and it can make sophisticated apps in 1-2k LOC using an LLM whereas in raw JS or TypeScript it would be much more code and more difficult to maintain.