I was thinking of Haskell recently, why isn't it more popular with AI? Haskell is very terse and token efficient, it has many expressive safety features. Rust is getting additional adoption because of its strictness, so hey why not have this in Rust over Javascript if it takes the same time to write?
An ideal language for agentic AI I would think is extremely strict, where the AI can iterate over the tooling for correctness. It would probably be less verbose and more terse to allow the AI to be more efficient with tokens.
drewr 1 days ago [-]
It's my default for all the reasons you mention.
In fact if I have to ship in a different language, I'll often do a Haskell version first to steer towards isolating IO, enforcing referential transparency, and generally picking up other functional patterns that are a good idea no matter what. Then I'll port the Haskell version to whatever the solution demands.
mncharity 1 days ago [-]
> do a Haskell version first [...] port
As lower-hanging fruit, to get some style steering, but not the strictness/correctness assist in implementation, there's also doing code sketches in hs - writing without testing - and then asking for whatever code as inspired by / in the spirit of / based on the reference sketch.
jimbokun 1 days ago [-]
With LLMs that’s not a terrible approach. They are generally very good at translating between programming languages.
amelius 11 hours ago [-]
Yes, this is why I believe LLMs will (finally) allow us all to make the move to purely functional languages.
calebkaiser 1 days ago [-]
I do AI research and mostly work with Lean these days. I love Haskell, though I wouldn't consider myself a particularly strong Haskell programmer (just never spent a ton of time working in it). I think you're spiritually correct that there are lots of reasons to use extremely strict languages with AI, but the reality is a little messier than you'd expect.
Token efficiency is specifically the place where strict languages get a little trickier. With dynamic languages where the model has a ton of training data, like Python, the agents are really good at writing code that just works. You still have challenges there, but they're just different than the challenges you hit with a language like Haskell/Lean/Agda etc. With Lean, for example, the amount of things the agent decides it needs to prove for a relatively trivial operation can lead to an absurd amount of code. And the way it decides to prove them can be borderline labyrinthian. It sort of plays perfectly towards current agent weaknesses, where agents can run off and reinvent a lot of machinery and build unnecessarily complex abstractions.
And those iterations have a cost. Even if the final artifact is more terse, the path to getting there can involve a huge amount of backtracking and rewriting and off-by-one syntactic corrections.
Ultimately, a lot of this comes down to developer experience. Getting useful error messages for the agent, having fast compile times so that the agent can iterate quickly, providing useful utilities for debugging, etc. There was a popular blog post specifically about Haskell that generally makes this point--the Haskell language is, in a vacuum, ideal in a lot of ways for AI, but the Haskell developer experience and ecosystem made it hard for this team to build with it via agents: https://avi.press/posts/2026-07-10-after-7-years-in-producti...
Note: I am not advocating against using these kinds of language. Obviously, I still work in Lean and a little in Agda and some related languages/projects, so I think this direction is right. Probably biased in that I love them with or without LLMs, but I do think they're also more ideal for AI development. There are still just challenges in getting agents productive in them, and most of the challenges are not about the type systems but the actual ergonomics and dev experience.
lallysingh 1 days ago [-]
I'm wondering the inverse, actually. That LLMs can make regular haskell programming (e.g. typing in code, not english that LLMs convert to code) powerful enough to prefer. Can we have LLMs do enough of the grunt work on building type machinery, dealing with compiler errors, looking up exact types and conversion systems, to make the APIs presented to us preferable?
So, I could write what I want in haskell, and it's faster for me than to have an LLM do it. The haskell would be high-level enough and precise enough to describe what I want the program to do with less iterations than I'd have with an LLM writing code, finding its own bugs, fixing them, then having me ask it what it did, tell it what to do differently, etc.
Direct control is very powerful. LLMs take that away from us, in exchange for a great speedup. But perhaps we can use LLMs to give it back to us by making our actual programming languages more powerful.
calebkaiser 1 days ago [-]
Yeah, I think this is roughly where things are headed. Or at least, it's part of what I'm working on these days, though I'd characterize myself as "generally kind of bad at things," so maybe that's anti-signal.
But I think this is actually in the design of many languages already, especially in languages like Lean, where you can prove that the presentable API is correct.
Here's one rough example that is related to this direction:
A common convention in Lean is to write essentially two versions of a function, with a theorem proving their equality or correspondence.
So you can write a more demonstrative version that is more easily understood, which you can treat sort of as a spec that all other implementations must satisfy. And then you can set the agent loose to do whatever nastiness it wants to do to improve performance.
> I think you're spiritually correct that there are lots of reasons to use extremely strict languages with AI
> With dynamic languages where the model has a ton of training data, like Python, the agents are really good at writing code that just works.
I'm confused how the former supports the latter here.
Surely, you mean that LLMs are not the right kind of "AI". Languages like Haskell expose how fundamentally porous LLMs are with information.
I wouldn't even say it's the dynamic nature of Python that leads to good results, but the consistency. Javascript is the obvious counterexample. There's far more javascript out there to train on than any other programming language, yet LLMs are terrible at writing it too.
3836293648 1 days ago [-]
Just reading chain of thought traces for Agda (I'm using Qwen 3.8-Flash-Next) and it's struggling so hard with just the syntax, long before it can struggle with semantics or type errors.
Admittedly I'm not much better, Agda has some crazy scoping rules at times and its operators are a mess, so much worse than Haskell, but at least I don't have to re-learn from scratch after every compaction.
icrbow 14 hours ago [-]
Opus 5.5 has no problem with Haskell in any domain whatsoever, including mixing it up with FFI and eDSLs. You call it, it does it.
mietek 16 hours ago [-]
No, Agda's mixfix operators and general syntactic malleability is state-of-the-art in programming language design. Try learning how to write it yourself, before relying on LLM to write it for you.
3836293648 15 hours ago [-]
It's a cool hack. It's also a catastrophe for actual usage. State-of-the-art doesn't mean good, it just means new, shiny and complex. Not being able to do syntax highlighting without a full typechecking pass is a usability nightmare.
Anyway, that's not the part I the human struggle with, it's remembering what level of infix each new custom operator has. Why λ() isn't equivalent with λ{}, if `a b , c` is `(a b) , c` or `a (b , c)` with this version of comma (Though now I've given up on the others and just use Σ a (λ _ -> b) for all kinds of tuples just to make it consistent). Why implicits won't unify as I expect them to. Why with just doesn't work in a reasonable fashion at all ever beyond the most basic two cases (no nesting and only nest in the final case). Literally copy pasting from the docs doesn't parse.
Cool trick, but in practice it was a mistake and Haskell's take on custom operators was far enough.
Operator fixity is a non-issue; if you don't like how the fixities have been set up, you can change them at will, even in the middle of an `import` statement. Nobody is making you use custom infix operators, either; you can write Agda that looks mostly like a Lisp if you wish.
Improving `with` is ongoing work; there was a presentation on it at the recent Agda implementors' meeting.
There's real people with real feelings building Agda, and not very many of them either. Consider that before publicly denigrating their work, with such shallow criticism to boot.
3836293648 6 hours ago [-]
Yes, and I know some of them and have critiqued it in person.
calebkaiser 1 days ago [-]
Yeah I know this pain. I actually have had some success by giving the agent a style guide for Lean that is strictly not conventional. The nice syntactic shortcuts and different modes that make Lean more ergonomic for humans, in my experience, actually make it easier for an agent to trip itself up.
solomonb 1 days ago [-]
I write Haskell every day, both for work and in my free time. Without commenting on the general quality of LLM generated code, my experience is that Haskell is at least as good as any other language for LLM code gen.
kodoman 21 hours ago [-]
I have not generated haskell code yet and did some haskell a while ago (before LLMs) and liked it a lot but I would imagine you are prompting the LLM like an engineer so to say and making sure you know the data types and everything before hand and probably tending to write type signatures and asking the LLM to complete it. I would imagine if you vibe code and ask it to write things without thinking that sort of thing though it might produce very bad code, but not sure, would like to know you experience on that matter.
solomonb 16 hours ago [-]
I don't know how to answer this. I find that the quality of claude's output in any language is highly dependent on your skill at prompting it and what context you can provide. Sometimes I might give it type signatures and heavily micromanage it but other times not. I almost always ask claude to develop a plan and architecture which I review before having it produce code.
Here is an example where I literally just told claude I wanted generic instances for these type classes and we had a brief back and forth about the approach then it one shotted this entire module:
https://github.com/solomon-b/monoidal-functors/blob/main/src...
I would say this code is indistinguishable from generics code written by a human. However, this type of code has a tendency to only be writable one way.
kodoman 12 hours ago [-]
> Here is an example where I literally just told claude I wanted generic instances for these type classes and we had a brief back and forth about the approach then it one shotted this entire module
Yes this is basically what I thought you where doing (what seems to me the correct thing). I have found it's very good at implementing interfaces or in your case type classes and completing generic functions. Though I am not sure if you wrote the type class definitions in this file or not, but sounds like either way you explained what you wanted. Also this sort of Haskell code is well above what I did in Haskell so I can only take your word for it that this is good code and I am sure it is.
Though I always use plans like you, and found them to always be good. I have experimented with just asking it to implement features with minimal direct and it does end up being very bad. Particularly in creating data structures/ data types or interfaces and classes.
My guess was only that when you try and get the agent to decide stuff like data types and type classes and how to structure the program it does a poor job and worse then if you did it in other languages.
solomonb 6 hours ago [-]
I did not write the type class declarations in this file but they are generic representation for type classes I did write.
I picked an extreme example. Sadly I don't have a great example of more "business" style code in a public repo to show you right now, but I have had a lot of success using LLMs to write CRUDy haskell APIs and such as well.
I think LLM output quality is wildly dependent on how we prompt them. And I don't just mean giving a really specific design for it to implement or whatever. I have no real proof but suspect that every little thing about how we communicate to an LLM will impact the quality of the output. Like even just our choice of language in how we describe a problem.
I have a friend who is not remotely a programmer who tried to vibe code a big python project with Claude. He came up with really detailed designs and worked through them over and over with Claude. He hit some major roadblocks and asked me to look over the code. I was really shocked at the quality of the code out.
There was tons and tons of dead code, unnecessary repeated expensive computations, no real sense of an architecture, etc. I didn't even re-write it by hand, I just asked claude things like "decompose all the functions to a reasonable size", "use modules to organize the code", "remove dead code", "write pure functions", "parse dont validate", etc. It eliminated thousands of lines of crap, became way easier to read, and improved the speed of the program by orders of magnitude.
nyssos 11 hours ago [-]
> My guess was only that when you try and get the agent to decide stuff like data types and type classes and how to structure the program it does a poor job and worse then if you did it in other languages.
It's about the same as for other languages, in my experience. LLMs are terrible at Haskell type design, but they're terrible at Rust type design too, terrible at deciding when and how to use Python classes, terrible at deciding when metaprogramming is appropriate, terrible at deciding what is well factored and what is not - great scripters, terrible lead engineers. The root causes seem to be things like bad domain modeling, judgement about which things matter and which things don't, prioritization, and so on, all of which produce bad designs in any language that will let you. The only really Haskell-specific defect I've noticed is an aversion to polymorphism and especially to HKTs.
kodoman 10 hours ago [-]
Yes agree it's not a good architect (and thankful as it puts a ceiling of crappy vibe coded apps and what vibe coders can do). But in languages like go-lang and python it's easier for you to just hand off something you want made to an llm and come back and possibly maintain and fix it in the future or modify it.
I have found go-lang fantastic for this, and although I would not do this for an important thing, for writing little tools that are a little beyond what would usually be a script and you want to maintain, it's great. I did this for a tool to insert data from stripe into a db for my service and it was a one shot thing.
solomonb 6 hours ago [-]
> LLMs are terrible at Haskell type design, but they're terrible at Rust type design too, terrible at deciding when and how to use Python classes, terrible at deciding when metaprogramming is appropriate, terrible at deciding what is well factored and what is not - great scripters, terrible lead engineers.
I find there are shibboleths you can say which get the LLM into a space where it can do better but generally I agree with you.
I also find that if the LLM is working in an existing code base with a really opinionated and consistently applied design that it will largely stay consistent with the codebase. Quality will drift as the ratio of human to LLM code changes so you periodically have to do a big cleanup to keep it from going too far.
lcprk 1 days ago [-]
It's not more popular because Dan Luu actually measured this [1] and those languages aren't better in practice.
A priori, it does seem strange. But the relative Haskell vs Python tokens in the internet go a long way to explaining it, as another commenter has said.
My main takeaway from that post was that, apart from "don't use assembly", none of the experiments showed strong evidence either way, and the things that took time were when the agent got stuck doing silly things like invoking cargo with the wrong arguments. Ie. there's a lot of measurement noise, and not any strong signal, and "LLMs are good at generating $PL" isn't well-founded as an argument for picking $PL. So we're back to the old arguments for picking a language, like "I find it readable/enjoyable"
kccqzy 1 days ago [-]
The popularity or the lack thereof has nothing to do with AI. AI writes good Haskell code, certainly not worse than much more popular languages like Python.
But I just don’t think terseness matters much; most of the cost is spent on reasoning tokens, not the sheer volume of code output.
flossly 1 days ago [-]
One "did not compile, fix error, try again" loop takes so many tokens, that a well-trained-on lang like JS/Py/Bash/C easily outperforms a strict one.
The benefits of strict are still the same: once the code grows bigger you have alll kinds of guarantees built into the software, that JS/Py/Bash/C needs lots of test achieve the same.
Since writing code is cheap, it like to go more on the tests and the strong typing, simply because it is so cheap. Why write Ruby/Py/JS when you can write Haskell/Kotlin/Rust? There's simply no reason not to be doing TDD these days.
cowlevel 18 hours ago [-]
LLMs predict next tokens following their training data. Following "so i wrote this little program in", "Haskell" is not a likely prediction.
N_Lens 11 hours ago [-]
At this stage, people who parrot “next token prediction” appear the most predictable of all!
klntsky 1 days ago [-]
Haskell does not have a good low level library wrappers story, unlike Rust.
Nobody prepared it for adoption nearly as much as Rust evangelists did for their language. Years of hard work they invested into maintaining bindings as hobby projects paid off.
internet_points 16 hours ago [-]
Hm, I found writing FFI code from Haskell quite easy.
People care a lot more about Rust-C++ interop because people expect to replace C++ with Rust. People don’t care as much about Haskell-C++ interop, so in the end people just rely on C ABI because it’s the lowest common denominator. If your low level library has a C interface, Haskell works very fine. Some people even prefer the OpenSSL C library over Haskell-native TLS.
klntsky 1 days ago [-]
Businesses care. I worked with Haskell in production (a fairly normal B2B SaaS). Some things you would expect to have in the ecosystem had to be maintained domestically.
My former company was generous enough to publish most of these[0] as open source projects. But what's really telling is that oftentimes vendoring a commonly used OSS library was unavoidable.
It totally can wrap c and c++ and whatnot. The hard part is done only once, then it is incremental maintenance that's mechanical. Some are even scripted. Huge API surfaces like Vulkan and AWS were bound and used that way.
Hendrikto 12 hours ago [-]
Haskell just feels too much like the academic experiment it is. And you really get the feeling that this is what most of the community and leadership want it to be.
danpalmer 24 hours ago [-]
> Haskell is very terse and token efficient
I'm not certain this is the case. I find AI better at producing code in languages where there are fewer abstractions. It's great at writing Go, because everything is there on the page in text/tokens, and I find it less good at writing (good) Swift, because there are lots more abstractions for it to reason about, which are not written in text/tokens on the page.
This is part of why I think LLMs producing dense and unpleasant to read text is linked to their ability, it's no coincidence that people have this criticism of all of the independently developed frontier models.
We can train around this, the frontier models are getting better at it, but it's a good reminder that LLMs are just text calculators at some level, and do much better when the concepts are in text rather than abstractions in our minds.
GZGavinZhao 1 days ago [-]
Is it really better than Lean though? I started learning programming in Haskell but gradually transitioned into Lean, both because it has almost everything Haskell has (minus laziness), great meta-programming support, and most importantly allows me to drop down into proofs / formal verification if needed.
cosmic_quanta 15 hours ago [-]
What's the runtime performance of a lean program? I've ever used it.
Haskell has had 36 years to get a really good runtime system (including software transactional memory, pure concurrency bliss) and an amazing optimizing compiler
nyssos 11 hours ago [-]
Good enough to be usable, still several times slower than Haskell.
icrbow 14 hours ago [-]
Better than Lean for what? It certainly has more ready to use packages in a bunch of domains.
guyastorey 1 hours ago [-]
im writing llambda, a compiler assistant.
i need contributors!
guyastorey 1 hours ago [-]
its more about cabal imo. the agents love cabal test.
llambda uses a 'go-is' formalism that allows properties to be proven about the presence of unit tests.
alethic 15 hours ago [-]
Because Lean 4 exists, which is a strictly (heh) better Haskell.
In seriousness, Lean is indeed a better Haskell (strict-by-default, performant data structures, BEAUTIFUL do-notation, full dependent types, etc), and you indeed do see a lot of slopped-out projects in it. However, certainly fewer than Rust, to be sure. I think the bitter truth of the matter is that additional static guarantees beyond what specifically Rust gives you -- type safety, interfaces, and linearity -- are simply not worth all that much in practical software applications.
segmondy 1 days ago [-]
It's as popular as you make it. Nothing is stopping you from using it. People generate code for what they are familiar with or have desire for. There are people who have wanted to give rust a try and AI opens that possibility up. There are certainly less people that want to try Haskell. Furthermore, Rust has more training data so LLMs generally will provide better Rust code than Haskell code. Because of LLM, I'm back into obscure languages that I didn't have the mental capacity to carry day by day. Prolog, Lisp and Forth, and like you said, they are very terse and token efficient. However, I must point out that terse was only relevant prior to the entire thinking era, a model could use 100k tokens to think only to give you 100 tokens of final output.
pimeys 1 days ago [-]
I've been generating probably 500k lines of Rust with all the SOTA models (and now DeepSeek). Every model does an absolutely horrible job generating good Rust code. You have to babysit it and you need to question everything the model spat out.
I mean, free functions and no general nice trait/struct/enum based architecture, random `Mutex`/`RwLock` everywhere, all your big futures inside a `tokio::select!` etc.
Yes it's great when you do your first Rust project. After a year it's a nightmare if you don't keep a clear control how the code is generated and organized.
srcreigh 1 days ago [-]
The ideal language is the one the agent knows how to use.
I used prolog for a project and GPT 6.1 Sol repeatedly made dumb mistakes as if it doesn’t understand the symbolic resolution capabilities.
For vibe coded Haskell id not be surprised to see it just not use strict types, hucking strings around
seizethecheese 1 days ago [-]
We happen to have data on GPT 6.1 Sol and programming languages used, so I looked into this.
Pretty much like with Rust it passes Value or String more often than using a struct for JSON data...
icrbow 14 hours ago [-]
You can totally demand doing most of the domain modelling in types before messing around with implementation details.
Plan.hs > plan.md
faangguyindia 24 hours ago [-]
If you are developing on mac and deploying to linux, Haskell is pain.
I had to switch to Rust for this reason otherwise Haskell was decent for my project
simonmic 3 hours ago [-]
> If you are developing on mac and deploying to linux, Haskell is pain.
Why is that ?
cosmic_quanta 15 hours ago [-]
We do this at work and it seems no more painful to deploy from Mac than deploying from Linux
dcss_gardener 1 days ago [-]
The ideal language for the AI has very short feedback loops with highly localized errors and minimal up front reasoning about types that itself provides a surface for flailing and errors. I'm not familiar enough with haskell to say for sure but I don't think this describes the language very well.
The ideal language for the engineer driving the agent has maximum comprehensibility, since review and understanding are the real bottlenecks now. I'm also pretty sure this doesn't describe haskell. It incompletely describes rust I think.
It does describe ocaml. And also gleam and maybe scala. And moonbit, developed by someone who is a proven expert in exactly this domain and explicitly targeting this problem space.
jose_zap 1 days ago [-]
Yet, "short feedback loops with highly localized errors" is exactly what Haskell is. You can start Haskell in interpreter mode (ghci) and you get instant feedback. Errors are always localized. Although my experience with claude in the last few months shows that it rarely hits a compilation error at all.
neutronicus 10 hours ago [-]
There was one post about a startup moving from Haskell to a Python because compile times had become a bottleneck for their Agents.
thatsabadlook 13 hours ago [-]
That's when you know a company wants to irreversibly go full vibe code. Turn their entire stack into LLM generated haskell. No one will ever read it again the end.
win311fwg 1 days ago [-]
> Rust is getting additional adoption because of its strictness
That's doubtful. It's not strict in any way that matters, especially when LLMs are writing it. You still have to rely on tests for everything. The languages that are strict are still largely ignored.
It is seeing adoption because of a well executed advertising campaign combined with "C++ without the dependency hell" being a real value proposition.
_doctor_love 1 days ago [-]
The most interesting idea in this space I have heard is to have LLMs generate formally verified assembly. And then from that assembly generate higher levels projections in languages like Haskell to help the human understanding.
klntsky 1 days ago [-]
It's not going to work. Formally verified assembly needs a low level spec which is comparable in length to the assembly code, so not really comprehensible.
"higher level projections" - wtf is this even about?
redeeming 1 days ago [-]
[dead]
pmkary 1 days ago [-]
There is this memo video of S. P. Jones that famously says "Haskell is Useless". I love Haskell, but I wished it was universal like C, C++, JavaScript, Rust, and C#. By that I mean: It could be used to create apps for desktop, mobile, and web. JavaScript can be used to do so many things like power the entire web, be on node and let anyone create cli and share the code with web, and mobile through React Native, on desktop with Electron and its alike things, it lets you do plugins for god knows how many things, it lets you write things for the GNOME Shell... C and C++ are perhaps behind everything in the world and string theory finally gets seen will see they are written in C. And they can be compiled to Web and almost everything in the world. Rust is a placeholder for the two, and C# reinvented itself when it saw Mono and now works even in the browser. Each time I see Haskell I wonder what else can I do rather than creating CLI apps, and it makes me choose something else that grants me more code reuse and interesting applications.
If I could have a vision for Haskell, it was for it to be useful. Academic research and making compilers is cool, a few cli things here and there are cool too, but why can't we build music players and game engines and flutters and web pages with it? The language is way more elegant and beautiful than all the JS/C like languages out there and I really wished I could use it for the things I did. I'm aware of Servant/Yesod/IHP/Miso/Reflex for web, GTK/Monomer for desktop, TidalCycles for music, SDL/gloss for games, and various FFI/plugin, but none of them feel as coherent and worked on as the others, none of them are polished. Haskell surely needs good DX, but it also needs really better reasons for existing.
pbrowne011 1 days ago [-]
> There is this memo video of S. P. Jones that famously says "Haskell is Useless".
I think that is an unfair characterization of the video and the intent of Haskell's co-creator, based on the rest of your comment. Simon Peyton Jones makes a graph with two dimensions, useful/useless and safe/unsafe. The question he gets at is: how can one distinguish between effectful and effect-free computations in a programming language? He proceeds to characterize most useful languages as unsafe, and Haskell as useless but safe. He then spends the majority of the video talking about how useful languages are becoming safer, and at the same time how Haskell must become useful.
I've loved this video for years, primarily because of SPJ's willingness (and excitement, even) to talk about Haskell's shortcomings. I think SPJ and other important people in the Haskell community are keenly aware that Haskell appeals to a specific demographic and that, to survive as more than just a research plaything, that they need to broaden participation.
The famously friendly "Learn You a Haskell" book features its first "helloworld" program deep into the middle of the book, _after_ functors and (if I recall correctly) monads. It takes a very special beginner programmer to push that far through, working in the REPL, before they can write programs that do basic I/O.
I teach functional programming to college sophomores and juniors, and I would love to teach them Haskell. But I have to meet them where they are, and it would be difficult to do in Haskell. This is why we have taught either F#, Scala, or LISP over the years. F# in particular has a lot of the aesthetic qualities of Haskell while allowing impurity or mutability escape hatches without too much trouble. If somebody has truly beginner-friendly Haskell resources, I would love to hear about it-- I'm apparently not smart enough to chart that path myself.
axman6 22 hours ago [-]
I used to tutor at the Australian National University, where the first semester CS course is 100% Haskell, it it was absolutely the right choice. People who’ve programmed before are at very little advantage over students who’ve never written a line of code, and often it’s the ones who did well in maths in high school that do best with it. It teaches many important ideas in a way that doesn’t give you an escape hatch to do bad things. I think for a CS degree, the primary goal is not to teach students how to program in the languages they’ll use in industry, but to teach them the ideas they’ll be able to apply to _any_ language they use in the future. I’ve also spent most of the 15 years since I took that course working professionally in Haskell, so it’s not like it’s “useless” for everyone.
raddan 5 hours ago [-]
I have colleagues at institutions who teach LISP-like languages (Scheme, Racket) to incoming first-year students. They name the same benefits you do, and trust me, I am onboard for functional programming as a first PL generally. But I am curious whether you know how successful your program was in "outreach". Our CS1 course uses Python, and students implement a game (inspired by Pokemon). They find it very exciting, and for a lot of them, the "computer very literally does what you say" is a revelation to them. I would worry about losing some of that switching to Haskell. I'm not saying that it's an impossibility. The main obstacle in my department would be that only a handful of the faculty even know more than a few languages.
rramadass 1 days ago [-]
Great video! Thanks for the link.
It is important to clearly understand that Simon uses the word "useless" in the sense of having no side-effects on the external world i.e. if state changes are not reflected in the external world at some point then there is no practical purpose to it and hence "useless".
Functional languages solved this by using the type system at different levels to combine both effectful and effect-free computations cleanly.
petra 1 days ago [-]
It's really hard to be the best at every platform, and at every problem area. Especially at the start. But once you have dominance in some niche, that may give you the power/possibility to dominate other niches.
I think this article tries to figure out where can Haskell be the best.
As for a platform? If Haskell can offer the most secure, correct, and trusted web apps(the biggest platform), created with the help of LLM's, and they can use LLM's to make reading Haskell intuitive, that's a good place.
epgui 1 days ago [-]
> It could be used to create apps for desktop, mobile, and web
Haskell can 100% be used to create all of these kinds of apps.
flossly 1 days ago [-]
But expect to be in pain when not web.
epgui 23 hours ago [-]
It’s unclear to me why that would particularly be the case with Haskell.
the__alchemist 1 days ago [-]
It sounds like it needs foundational libraries? Or is it something else. For example, almost everything I write requires one or more of:
- Embedded toolchain and/or HAL/register map for my MCU family or CPU arhitecture
- A GUI library and/or basic I/O interaction library (keyboard/mouse to start)
- A GPU interaction library
- A web framework (Not going to roll my own DB interface, auth, user system, router, template system etc)
(Etc). I.e., some core library which handles the drudgery I can build my application on. If this is what you're getting at, this suggests a plan of attack!
chriswarbo 1 days ago [-]
Pretty sure those all exist; e.g. at work we use Yesod and Servant, which are a couple of Haskell web frameworks.
jose_zap 1 days ago [-]
Embedded toolchain and/or HAL/register map:
- Copilot (by NASA)
- MicroHs — for running Haskell on an MCU
GUI library and/or basic keyboard/mouse I/O:
- Monomer
- sdl2
- gi-gtk4
GPU interaction library
- OpenGL bindings
- vulkan bindnigs
- Accelerate — numerical GPU computation with an NVIDIA backend.
Web framework with database access, auth, users, routing, and templates:
- IHP
- Yesod
txdv 1 days ago [-]
whats holding you back? buy claude pro and make it reality, hell im gonna give it try because your comment offends me
Y_Y 1 days ago [-]
> Functional programming should not be viewed as a tuxedo that we dust off and use when we want to be "fancy programmers." It's simply a tool in the toolbox.
Nothing is really missing, Haskell can do all of that.
gavmor 1 days ago [-]
I thought so. What's the reason for the PR problem, then?
raddan 1 days ago [-]
I can only speak from my own experience, but expressing a program as a composition of pure functions, where effects are carefully managed, is a challenging way of thinking at first. The imperative approach really is simpler to wrap one's head around _until you start worrying about correctness_. I think many developers never really care that deeply, so Haskell never appeals to them. You really do have to take a mathematical approach to program construction. I personally think that the mathematical perspective is liberating, but it's not an easy one to cultivate.
tome 10 hours ago [-]
> The imperative approach really is simpler to wrap one's head around
I've devised a way of programming imperatively in Haskell but in a way that maintains all the benefits of the type system ("make invalid behaviours unrepresentable") but I don't think that moved the needle on Haskell's popularity...
epgui 23 hours ago [-]
I wouldn’t call imperative programming simpler. I’d say it’s more familiar to most people, because it’s the first thing they learn, and it’s hard to unlearn things.
1 days ago [-]
epgui 23 hours ago [-]
I mean, everyone who learns programming learns a fortran/C family language.
So Haskell is asking of them that they unlearn most of the things they’ve learned. It’s unfamiliar, and people react in a hostile way.
In reality, objectively speaking, it’s a very fine language to work with.
1 days ago [-]
whateveracct 21 hours ago [-]
dumb people are loud
1 days ago [-]
carterschonwald 1 days ago [-]
hasufell has been a wonderful person in haskell land. hes got very clear headed ideas about stuff and so forth.
also the stuff i can now build in haskell with computer aid is epic. earlier this week i stood up what i believe is one of the/ if not the: best step file format reader writer on like every axis. some c ones are 20-30 percent faster on the largest possible cad assemblies i could try out.
an important axis that folks neglect to consider: the main way llms are getting scaled up for better coding is metric megatons of reinforcement learning traces, and type checking thats fancy gives a cheaper and faster training feedback loop.
with an llm as a sortah insane manic intern im looking over the shoulder, so to speak, im able to build the apis and designs i can see but cant type anywhere near the same scale. but i can specify the keystones for the exact designs quite compactly and then the agent kinda acts as a compiler inhave to correct and iterate running
georgewsinger 1 days ago [-]
RE the debugging experience in Haskell: we recently wrote a post about bringing live run-time debugging to our Haskell VR compositor: https://simulavr.com/blog/debug-hud/
Live step-through debugging and interactivity we think is pretty underrated in the Haskell ecosystem.
axman6 22 hours ago [-]
Yeah the availability of Haskell tooling has improved so much in the past five or so years.
KolmogorovComp 1 days ago [-]
While I agree compile time is a big issue, I think the focus should really be on incremental build, because considering how much work the Haskell compiler has to do, it is expected to be quite slow on full build.
But incremental build has no reason to be slow, if the scope is as fine-grained as the function and type level.
axman6 22 hours ago [-]
It’s one of the reasons Tweag built rules_haskell for building Haskell with Bazel (and IIRC Buck2 too). Simon Marlow has also been talking recently about his work to build Haskell with Buck2, which he has on a fork of cabal-install.
(Disclaimer, I work at Tweag and recently did some work on the project)
internet_points 16 hours ago [-]
I find initial build to be the most annoying, since it stops me from starting new projects in Haskell. It's also very annoying when setting up CI or switching machines or introducing new team members.
1 days ago [-]
time4tea 1 days ago [-]
Ok, so shoot me down...
The jvm world has achieved a few of these goals, and is in some ways an exemplar for these lofty goals.
Long term api stability, innovation, mapping hardware to software etc etc .
ourcat 1 days ago [-]
I remember when Charles Hoskinson announced that smart contracts on his crypto platform Cardano / Plutus would use Haskell.
It just didn't get anything like the adoption that Solidity had at the time.
treyd 1 days ago [-]
That's not the reason Cardano failed though. All the capital had already established itself on other platforms and "it uses a better language" wasn't enough of an incentive to switch. It's an overwhelmingly common story in that ecosystem, even with other networks that Solidity can target.
mhitza 1 days ago [-]
I don't know what it takes to write (or wire up) a smart contracts language, but when I, as someone past beginner level, looked up the Cardano docs on how to build contracts I was mega confused and had no clear way how to get started.
axman6 22 hours ago [-]
Cardano contracts are _strange_, because they don’t describe what you want to happen, they check if what’s happening in a transaction is allowed — all contracts are a function `Transaction -> Bool` — and most people want to describe the actions. There are plenty of ways to write Cardano contracts in several languages, but I do agree it’s not clear how you go from idea to on chain.
nilkn 1 days ago [-]
It doesn't have enough marginal value add on top of competitors like Rust. There are other more significant synergies with coding agents that are getting attention instead, like autonomous formal verification. Languages like Lean enable an entirely new category of engineering, and Haskell just doesn't. So it's stuck in a difficult middle where it's too different to justify relative to its gains, but not different enough to capture the new opportunities emerging.
axman6 22 hours ago [-]
As a Haskell developer who wants to like Rust, I just find it to incredibly verbose and noisy. It’s really hard to see the program through the code, all the types are messy, there’s so many things that feel like they should be abstracted so you can see the business logic, but there’s all these `if … .unwrap()`, and other guff I can’t remember that makes it really unpalatable to me.
flossly 1 days ago [-]
Just like Ruby was IMHO a "simple" lang carved out of Perl;
Elm is a "simple" lang carved out of Haskell.
Some languages are here merely to inspire others.
Not that Elm is such a success... But it is "simple" (Haskell and Perl are not; they big).
snordgren 15 hours ago [-]
Elm was on a strong upward trajectory, getting more and more attention and usage, when the fateful change that killed it was introduced. Who knows what it could have become if things were different?
Haskell also heavily inspired Rust, not in terms of syntax, but Rust traits and enums are very similar to Haskell type classes and ADTs.
As a vehicle for PL research, Haskell has been very successful. Practically every language introduced after ~2015 includes some variant of ADTs, option types, and result types. Many include type class analogues, too.
icrbow 14 hours ago [-]
And this in turn invalidates some of the "but certainly Rust has more code in the corpus than Haskell" claims. Sure, by the cloc, perhaps. But when agents dive into Haskell they feel right at home conceptually, because the concepts reverberated throughout CS domain.
jimbokun 1 days ago [-]
Is it even possible for Haskell to have compilation times similar to Go, given the language semantics?
jose_zap 1 days ago [-]
It is definitely possible for incremental compilation, but requires more work in that area. It is possible today in interpreter mode.
whateveracct 21 hours ago [-]
the interpreter is faster than Go when reloading comparable stuff
_bent 1 days ago [-]
> the onboarding experience of rust
> we are going to build the best onboarding experience in the programming language ecosystem
> This can only be done if we commit to unix principles
> write programs that do one thing and do it well
Rust is so approachable because Cargo does not subscribe to "do one thing".
In fact Cargo does a bunch of things. Which is very convenient for newcomers, because they only need to learn one thing instead of a bunch (and how they interact).
The same holds for a GUI like a file explorer with buttons and interactions like drag / drop or marquee select, which is a bunch simpler than chaining 3 programs together to delete 30 old files and move some folder into a subdirectory.
It also explains why the most successful tools within the land of Unix philosophy are stuff like AWK, which really don't just do one thing. Or why PowerShell is less usable than GNU. Or why Emacs is an 'operating system'.
It's also a reason why the installation experience for Haskell is so bad: there are a bunch of programs and users don't know where to start and what they need.
> Cabal and Stack: which one should I install?
> We recommend installing both.
One thing and one thing well.
Atleast it seems they've added a combined installer for these tools since the last time I've checked.
chriswarbo 1 days ago [-]
I disagree. About a decade ago I made some tooling to extract and analyse code from Haskell packages. That's easier said than done, given the use of pre-processors, TemplateHaskell, language extensions affecting the syntax/grammar, using external files like `.cabal` to specify such pre-processors/extensions, etc.
I went through several iterations, to get something that I could throw arbitrary packages at from Hackage, GitHub, etc. The result was a hacky mess containing a GHC plugin to dump Core code, a library to dynamically generate and evaluate strings of Nix to handle dependencies, shell scripts that piped `:t` commands through GHCi, and so on.
It was annoying, not because of the effort involved (I was doing weird, bespoke things; so it's no surprise it needed weird, bespoke code to be written); but because all of the functionality I needed already existed, just buried deep inside GHC/Cabal/etc.
Admittedly the GHC API has gotten much better in recent years; but there's no way the developers of "one tool to rule them all" can predict all of the different things that users will want it to do. Indeed, it's probably wise for such tools to avoid supporting/maintaining particularly weird/niche uses!
Having a collection of tools instead, which "do one thing and do it well", side-steps that problem entirely: users with weird use-cases are empowered to plug things together in a way that suits their needs, without needing the devs to add special features/flags just for them (or maintain their own forks with such flags, etc.)
kodoman 20 hours ago [-]
Size of programs binary, memory usage, heavy runtime and the size of the compiler can be very painful and possibly non-starts for some things as well. I do like Haskell but a lot of things I could never use it for because of those issues.
> It also explains why the most successful tools within the land of Unix philosophy are stuff like AWK, which really don't just do one thing. Or why PowerShell is less usable than GNU. Or why Emacs is an 'operating system'.
I am not really sure this is true. I find my self composing Unix tools (partly because I don't know AWK that well lol) and I think 'do one thing well' when can mean easier time thinking how things interact and from primitives rather then one big opaque program. I agree for this to work things have to sit well together and adherence philosophies and respecting the boundaries of the other programs is an important thing to do.
Cabal and Stack step on each others toes constantly and it does seem confusing. I am a masochist so use nix on top of this and there a a very many ways to go when you do that for Haskell projects.
odyssey7 1 days ago [-]
They’re pitching a tall order. First they will need to convince the masses that code should be understood.
classified 1 days ago [-]
That seems like a losing proposition in these times.
whateveracct 21 hours ago [-]
haskell is a bastion for the actually intelligent
origini 1 days ago [-]
Sooo they are fixing how you install Haskell? :D
rafaelRiv 1 days ago [-]
How this was ever a problem ? and today we have ghcup, stack and nix
itishappy 1 days ago [-]
That's the problem!
If I'm on NixOS, should I be installing via ghcup, stack, or nix?
Buttons840 1 days ago [-]
The Haskell ecosystem seems obsessed with NixOS in a way I haven't seen anywhere else.
I recall wanting to use Haskell packages that were only available in Nix, but nobody had bothered to make just a normal package.
axman6 22 hours ago [-]
I’ve been using Haskell for about eighteen years and can’t think of a single example of anything that was only available via nix, other than Obsidian System’s stuff that used WASM back when building for that as a target was _complicated_ and having a reproducible environment was kind of a necessity.
Buttons840 8 hours ago [-]
Yeah. That tickles my memory, so that's probably what I'm talking about.
itishappy 11 hours ago [-]
NixOS is subtly marketed to Haskell folks.
I got into Haskell because I wanted to learn ADTs, and quickly found I really appreciate the ways that purely functional programming tickles my brain!
NixOS has been described as a "purely functional Linux distribution" and I liked the sound of that at first. I haven't figured out what this means, lol, but I tried it anyway and quickly found I really appreciate it's declarative configuration.
If you want to create an ecosystem optimized towards correctness, you'll have to curate what you let inside, and drop many things. And Nix is probably the best package manager for correctness.
That of course hurts market share.
Buttons840 1 days ago [-]
There is no correct, only pros and cons. How you weight the pros and cons will not be the same as everyone else.
petra 21 hours ago [-]
in correct i meant "minimizes the amount of bugs".
wasted_intel 1 days ago [-]
To be fair, that’s a general problem on NixOS (and other OSes), and one that tools like devenv have tried to solve. You can take what’s included with OS packages, but then you’re stuck with whatever version that is.
chriswarbo 1 days ago [-]
> You can take what’s included with OS packages, but then you’re stuck with whatever version that is.
It's pretty easy to override things in Nixpkgs though, whether at the system level, or for one application, or just a particular dependency deep in the tree of one script.
Nixpkgs has a bunch of powerful functions to make this easier, e.g. callCabal2nix, makePackageSet, etc.
There is no such problem with Haskell! You either use your distro version of GHC or you use ghcup for the latest GHC.
Every other language does/must do the same since Ubuntu/Debian have 2+ years old packages.
itishappy 11 hours ago [-]
This wasn't a hypothetical. I'm still not sure I made the right choice.
I decided to go with GHC via nix-shell, which worked fine, but it's a different path than I went with installing Rust (global rustup), and I'm not sure how to evaluate the pros/cons of each. I miss having ghci invocable anywhere, but doubt that's a good reason to change.
Also, ghcup failing on my Rasberry Pi was a fun troubleshooting experience! I don't remember how I got around that one either, but they eventually fixed the issue.
whateveracct 21 hours ago [-]
if you're on NixOS, why don't you know how to install stuff? seems like you somehow don't know Nix??
hexasquid 22 hours ago [-]
Haskell community "we're going to be more beginner friendly than ever"
Beginners "I'm confused"
Haskell community "well that's certainly your fault, this isn't hard"
20 hours ago [-]
guyastorey 1 hours ago [-]
[flagged]
smitty1e 1 days ago [-]
> Beginners: the onboarding experience must be our benchmark for usability
OK, so I put this into Gemini:
"show me a non-trivial haskell function and type signature with at least five distinct arguments"
And I get:
---
processRecord :: (a -> b) -> Maybe c -> [d] -> (e -> Bool) -> (b, c, [d], e) -> Either String (b, c, [d], e)
processRecord transform mVal items pred (bVal, cVal, dList, eVal)
| pred eVal = Right (transform (const bVal undefined) mVal, cVal, dList, eVal) -- simplified example logic
| otherwise = Left "Predicate failed on the fifth argument"
---
My brain just crashes after the "::".
For the beginner, there isn't enough syntax on offer to discern who's doing what to whom here.
Is there a "function signatures for dummys" somewhere?
kccqzy 1 days ago [-]
Your brain crashes just because of unfamiliarity with the syntax. Just mentally translate it into C++ or Rust syntax.
This familiarity can be gained in frankly a day or two of trying, and afterwards you’ll find it to be clear and information dense. The example doesn’t even involve anything truly mind blowing for a beginner yet, like the Traversable class, the lens/traversal/prism signatures, or polymorphic recursion.
axman6 22 hours ago [-]
See how much more readable that is? /s
smitty1e 11 hours ago [-]
You can typedef your way to readability in C++.
WorldMaker 10 hours ago [-]
Similarly you can type definition (`data` keyword) your way to additional readability in Haskell. There's always a push/pull between using a generic type like `(b, c, [d], e)` and using a named type like `Record` in the above example, for instance.
polarsanel 17 hours ago [-]
You don't need to make everything anonymous. Types can be given names. This would be similarly definable and confusing in C#
lambdas 1 days ago [-]
Huh? How would that be a good criteria - how many languages exist where a non-user can easily grok non trivial functions with at least five distinct arguments?
If someone told me German was easy to learn, I wouldn’t get an LLM to generate me a complex sentence with two clauses and three adjectives and then be like “sure about that?”
`processRecord :: (a -> b) -> Maybe c -> [d] -> (e -> Bool) -> (b, c, [d], e) -> Either String (b, c, [d], e)`
Says:
“
give me:
1) a function of a to b,
2) a ‘c’ wrapped in a Maybe,
3) a list of d’s,
4) a function of e to a Bool,
5) a 4 tuple of a, b, list of d’s, and an e
And I will give you either a String or your original tuple back”
It doesn’t really do anything so there’s not much more to explain
the_af 1 days ago [-]
If you read the most introductory guide of Haskell, or ask your LLM to explain, you'll find there's nothing mystifying about the syntax you quoted. You're just unfamiliar with it because you didn't do the bare minimum effort.
If I ask my grandma what she thinks of the supposedly easy Python syntax, or C-style curly braces, her brain would similarly crash. Unless she read an intro to Python or C first.
In other words, do not confuse "I'm unfamiliar with this because it doesn't resemble what I know" with "hard to understand".
hexasquid 22 hours ago [-]
This is a great example of how the haskell community takes feedback.
Perhaps I'll get a response to this like "well actually you're wrong"
the_af 22 hours ago [-]
I'm not part of the Haskell community. I dabbled for a while, years ago. I would have given the same answer for, say, someone complaining they cannot understand lisp syntax without first trying reading an intro article about it. "All those parentheses, what do they even mean?".
There's valid feedback in the form "after reading the free Learn You A Haskell or some chapters from Real World Haskell, I cannot figure out how to write a useful program", and then there's "I asked ChatGPT to write some code and I cannot figure out the basic syntax elements because I couldn't be bothered to read anything about the programming language first".
smitty1e 21 hours ago [-]
I actually own Paul Hudak's Haskell School of Expression and a couple other dead tree books.
The means of getting over the hump with this syntax just has not been found.
the_af 21 hours ago [-]
So were you just faking that you didn't understand Haskell syntax or that you didn't know there are gentle introductions to it?
Seems dishonest.
smitty1e 11 hours ago [-]
No, I'm actually communicating that this syntax, for whatever reason, is not yielding itself to understanding for my brain cells.
This in response to a quoted statement from TFA about beginners.
The moderation and feedback here strangely congruent with the syntax.
the_af 10 hours ago [-]
So you didn't read your School of Expression and "the couple other" books in your shelves, huh?
Surely you understand "the moderation" here on HN and "the Haskell community" are not the same? Over here, people are reacting to the tired old trope of "I don't understand this unfamiliar syntax that I didn't bother to learn first!".
7 hours ago [-]
smitty1e 21 hours ago [-]
I quoted TFA with specific feedback and get modded to -2.
I'm not bitter.
3 hours ago [-]
21 hours ago [-]
mrkeen 10 hours ago [-]
And you're getting specific feedback to your specific feedback.
Just post the language that makes your example code look acceptable.
Jtsummers 1 days ago [-]
> For the beginner, there isn't enough syntax on offer to discern who's doing what to whom here.
If you throw a beginner at any non-trivial code in any language without teaching them anything about the language, then, yeah, it'll be hard for them to figure it out. That says nothing about the language itself, though. That's pretty obvious to everybody.
> Is there a "function signatures for dummys" somewhere?
Yeah, of course. There's actual beginner material, here's one example:
Not hard to find, and not the only introduction to the language that covers this material. I guess you never bothered to look, or even to ask Gemini.
smitty1e 11 hours ago [-]
Thank you. A welcome respite from the "tough love" elsewhere in the thread.
the_af 10 hours ago [-]
It's the same answer I gave you, that you arbitrarily didn't like.
In this day and age, where you used an LLM to give you a random Haskell example, you cannot ask "is there an introduction...?". That's lazy and dishonest. Google it (Learn You A Haskell would have been one of the first results) or ask the same LLM you used for your contrived example:
https://chatgpt.com/share/6af86ef7-fa4c-83e9-b32f-7daeb7753d...
It's not tough love, it's that you're being dishonest.
nurumaik 1 days ago [-]
-- Show me a non-trivial function
-- Here you go
-- Oh my god, it's non-trivial
galacticaactual 1 days ago [-]
In before a certain defense tech engineer in 3...2...1
yeah ive never heard anyone say they like doing productive coinduction in lean. agda almost has a story, but the ergonomics and semantics arent trivial.
though i have thought about it.
Rendered at 00:24:49 GMT+0000 (Coordinated Universal Time) with Vercel.
An ideal language for agentic AI I would think is extremely strict, where the AI can iterate over the tooling for correctness. It would probably be less verbose and more terse to allow the AI to be more efficient with tokens.
In fact if I have to ship in a different language, I'll often do a Haskell version first to steer towards isolating IO, enforcing referential transparency, and generally picking up other functional patterns that are a good idea no matter what. Then I'll port the Haskell version to whatever the solution demands.
As lower-hanging fruit, to get some style steering, but not the strictness/correctness assist in implementation, there's also doing code sketches in hs - writing without testing - and then asking for whatever code as inspired by / in the spirit of / based on the reference sketch.
Token efficiency is specifically the place where strict languages get a little trickier. With dynamic languages where the model has a ton of training data, like Python, the agents are really good at writing code that just works. You still have challenges there, but they're just different than the challenges you hit with a language like Haskell/Lean/Agda etc. With Lean, for example, the amount of things the agent decides it needs to prove for a relatively trivial operation can lead to an absurd amount of code. And the way it decides to prove them can be borderline labyrinthian. It sort of plays perfectly towards current agent weaknesses, where agents can run off and reinvent a lot of machinery and build unnecessarily complex abstractions.
And those iterations have a cost. Even if the final artifact is more terse, the path to getting there can involve a huge amount of backtracking and rewriting and off-by-one syntactic corrections.
Ultimately, a lot of this comes down to developer experience. Getting useful error messages for the agent, having fast compile times so that the agent can iterate quickly, providing useful utilities for debugging, etc. There was a popular blog post specifically about Haskell that generally makes this point--the Haskell language is, in a vacuum, ideal in a lot of ways for AI, but the Haskell developer experience and ecosystem made it hard for this team to build with it via agents: https://avi.press/posts/2026-07-10-after-7-years-in-producti...
Note: I am not advocating against using these kinds of language. Obviously, I still work in Lean and a little in Agda and some related languages/projects, so I think this direction is right. Probably biased in that I love them with or without LLMs, but I do think they're also more ideal for AI development. There are still just challenges in getting agents productive in them, and most of the challenges are not about the type systems but the actual ergonomics and dev experience.
So, I could write what I want in haskell, and it's faster for me than to have an LLM do it. The haskell would be high-level enough and precise enough to describe what I want the program to do with less iterations than I'd have with an LLM writing code, finding its own bugs, fixing them, then having me ask it what it did, tell it what to do differently, etc.
Direct control is very powerful. LLMs take that away from us, in exchange for a great speedup. But perhaps we can use LLMs to give it back to us by making our actual programming languages more powerful.
But I think this is actually in the design of many languages already, especially in languages like Lean, where you can prove that the presentable API is correct.
Here's one rough example that is related to this direction:
A common convention in Lean is to write essentially two versions of a function, with a theorem proving their equality or correspondence.
So you can write a more demonstrative version that is more easily understood, which you can treat sort of as a spec that all other implementations must satisfy. And then you can set the agent loose to do whatever nastiness it wants to do to improve performance.
Here's a fun write up from someone doing just this with zip file compression: https://kim-em.github.io/blog/2026-7-24-why-lean-is-faster-t...
> With dynamic languages where the model has a ton of training data, like Python, the agents are really good at writing code that just works.
I'm confused how the former supports the latter here.
Surely, you mean that LLMs are not the right kind of "AI". Languages like Haskell expose how fundamentally porous LLMs are with information.
I wouldn't even say it's the dynamic nature of Python that leads to good results, but the consistency. Javascript is the obvious counterexample. There's far more javascript out there to train on than any other programming language, yet LLMs are terrible at writing it too.
Admittedly I'm not much better, Agda has some crazy scoping rules at times and its operators are a mess, so much worse than Haskell, but at least I don't have to re-learn from scratch after every compaction.
Anyway, that's not the part I the human struggle with, it's remembering what level of infix each new custom operator has. Why λ() isn't equivalent with λ{}, if `a b , c` is `(a b) , c` or `a (b , c)` with this version of comma (Though now I've given up on the others and just use Σ a (λ _ -> b) for all kinds of tuples just to make it consistent). Why implicits won't unify as I expect them to. Why with just doesn't work in a reasonable fashion at all ever beyond the most basic two cases (no nesting and only nest in the final case). Literally copy pasting from the docs doesn't parse.
Cool trick, but in practice it was a mistake and Haskell's take on custom operators was far enough.
An Agda course taught in Padova since 2024: https://agdapad.quasicoherent.io/~Padova2026/
"Programming Language Foundations in Agda", a course taught at multiple universities since 2018: https://plfa.github.io
Conor Titania McBride's lectures on Agda, including videos: https://github.com/pigworker/CS410-18
Thorsten Altenkirch's lectures on computer-aided formal reasoning using Agda: https://www.cs.nott.ac.uk/~psztxa/g53cfr
I am returning to the language, not new.
Operator fixity is a non-issue; if you don't like how the fixities have been set up, you can change them at will, even in the middle of an `import` statement. Nobody is making you use custom infix operators, either; you can write Agda that looks mostly like a Lisp if you wish.
Improving `with` is ongoing work; there was a presentation on it at the recent Agda implementors' meeting.
There's real people with real feelings building Agda, and not very many of them either. Consider that before publicly denigrating their work, with such shallow criticism to boot.
Here is an example where I literally just told claude I wanted generic instances for these type classes and we had a brief back and forth about the approach then it one shotted this entire module: https://github.com/solomon-b/monoidal-functors/blob/main/src...
I would say this code is indistinguishable from generics code written by a human. However, this type of code has a tendency to only be writable one way.
Yes this is basically what I thought you where doing (what seems to me the correct thing). I have found it's very good at implementing interfaces or in your case type classes and completing generic functions. Though I am not sure if you wrote the type class definitions in this file or not, but sounds like either way you explained what you wanted. Also this sort of Haskell code is well above what I did in Haskell so I can only take your word for it that this is good code and I am sure it is.
Though I always use plans like you, and found them to always be good. I have experimented with just asking it to implement features with minimal direct and it does end up being very bad. Particularly in creating data structures/ data types or interfaces and classes.
My guess was only that when you try and get the agent to decide stuff like data types and type classes and how to structure the program it does a poor job and worse then if you did it in other languages.
I picked an extreme example. Sadly I don't have a great example of more "business" style code in a public repo to show you right now, but I have had a lot of success using LLMs to write CRUDy haskell APIs and such as well.
I think LLM output quality is wildly dependent on how we prompt them. And I don't just mean giving a really specific design for it to implement or whatever. I have no real proof but suspect that every little thing about how we communicate to an LLM will impact the quality of the output. Like even just our choice of language in how we describe a problem.
I have a friend who is not remotely a programmer who tried to vibe code a big python project with Claude. He came up with really detailed designs and worked through them over and over with Claude. He hit some major roadblocks and asked me to look over the code. I was really shocked at the quality of the code out.
There was tons and tons of dead code, unnecessary repeated expensive computations, no real sense of an architecture, etc. I didn't even re-write it by hand, I just asked claude things like "decompose all the functions to a reasonable size", "use modules to organize the code", "remove dead code", "write pure functions", "parse dont validate", etc. It eliminated thousands of lines of crap, became way easier to read, and improved the speed of the program by orders of magnitude.
It's about the same as for other languages, in my experience. LLMs are terrible at Haskell type design, but they're terrible at Rust type design too, terrible at deciding when and how to use Python classes, terrible at deciding when metaprogramming is appropriate, terrible at deciding what is well factored and what is not - great scripters, terrible lead engineers. The root causes seem to be things like bad domain modeling, judgement about which things matter and which things don't, prioritization, and so on, all of which produce bad designs in any language that will let you. The only really Haskell-specific defect I've noticed is an aversion to polymorphism and especially to HKTs.
I have found go-lang fantastic for this, and although I would not do this for an important thing, for writing little tools that are a little beyond what would usually be a script and you want to maintain, it's great. I did this for a tool to insert data from stripe into a db for my service and it was a one shot thing.
I find there are shibboleths you can say which get the LLM into a space where it can do better but generally I agree with you.
I also find that if the LLM is working in an existing code base with a really opinionated and consistently applied design that it will largely stay consistent with the codebase. Quality will drift as the ratio of human to LLM code changes so you periodically have to do a big cleanup to keep it from going too far.
A priori, it does seem strange. But the relative Haskell vs Python tokens in the internet go a long way to explaining it, as another commenter has said.
[1] https://danluu.com/pl-tokens/
But I just don’t think terseness matters much; most of the cost is spent on reasoning tokens, not the sheer volume of code output.
The benefits of strict are still the same: once the code grows bigger you have alll kinds of guarantees built into the software, that JS/Py/Bash/C needs lots of test achieve the same.
Since writing code is cheap, it like to go more on the tests and the strong typing, simply because it is so cheap. Why write Ruby/Py/JS when you can write Haskell/Kotlin/Rust? There's simply no reason not to be doing TDD these days.
Nobody prepared it for adoption nearly as much as Rust evangelists did for their language. Years of hard work they invested into maintaining bindings as hobby projects paid off.
I've been meaning to try the new https://well-typed.com/blog/2026/10/hs-bindgen-official-rele... which looks even nicer, but haven't found a missing library yet to try it on :)
My former company was generous enough to publish most of these[0] as open source projects. But what's really telling is that oftentimes vendoring a commonly used OSS library was unavoidable.
[0] Here's a potentially incomplete list: https://chatgpt.com/s/t_6af76fd8f2a081918fa37f8c30bdb3ba
I'm not certain this is the case. I find AI better at producing code in languages where there are fewer abstractions. It's great at writing Go, because everything is there on the page in text/tokens, and I find it less good at writing (good) Swift, because there are lots more abstractions for it to reason about, which are not written in text/tokens on the page.
This is part of why I think LLMs producing dense and unpleasant to read text is linked to their ability, it's no coincidence that people have this criticism of all of the independently developed frontier models.
We can train around this, the frontier models are getting better at it, but it's a good reminder that LLMs are just text calculators at some level, and do much better when the concepts are in text rather than abstractions in our minds.
Haskell has had 36 years to get a really good runtime system (including software transactional memory, pure concurrency bliss) and an amazing optimizing compiler
In seriousness, Lean is indeed a better Haskell (strict-by-default, performant data structures, BEAUTIFUL do-notation, full dependent types, etc), and you indeed do see a lot of slopped-out projects in it. However, certainly fewer than Rust, to be sure. I think the bitter truth of the matter is that additional static guarantees beyond what specifically Rust gives you -- type safety, interfaces, and linearity -- are simply not worth all that much in practical software applications.
I mean, free functions and no general nice trait/struct/enum based architecture, random `Mutex`/`RwLock` everywhere, all your big futures inside a `tokio::select!` etc.
Yes it's great when you do your first Rust project. After a year it's a nightmare if you don't keep a clear control how the code is generated and organized.
I used prolog for a project and GPT 6.1 Sol repeatedly made dumb mistakes as if it doesn’t understand the symbolic resolution capabilities.
For vibe coded Haskell id not be surprised to see it just not use strict types, hucking strings around
Looks like the claim is true that Sol sucks at the long tail of languages (vs. battle opponents). https://micjm.com/blog/gpt-6.1-sol-long-tail-languages/
Plan.hs > plan.md
I had to switch to Rust for this reason otherwise Haskell was decent for my project
Why is that ?
The ideal language for the engineer driving the agent has maximum comprehensibility, since review and understanding are the real bottlenecks now. I'm also pretty sure this doesn't describe haskell. It incompletely describes rust I think.
It does describe ocaml. And also gleam and maybe scala. And moonbit, developed by someone who is a proven expert in exactly this domain and explicitly targeting this problem space.
That's doubtful. It's not strict in any way that matters, especially when LLMs are writing it. You still have to rely on tests for everything. The languages that are strict are still largely ignored.
It is seeing adoption because of a well executed advertising campaign combined with "C++ without the dependency hell" being a real value proposition.
"higher level projections" - wtf is this even about?
If I could have a vision for Haskell, it was for it to be useful. Academic research and making compilers is cool, a few cli things here and there are cool too, but why can't we build music players and game engines and flutters and web pages with it? The language is way more elegant and beautiful than all the JS/C like languages out there and I really wished I could use it for the things I did. I'm aware of Servant/Yesod/IHP/Miso/Reflex for web, GTK/Monomer for desktop, TidalCycles for music, SDL/gloss for games, and various FFI/plugin, but none of them feel as coherent and worked on as the others, none of them are polished. Haskell surely needs good DX, but it also needs really better reasons for existing.
I think that is an unfair characterization of the video and the intent of Haskell's co-creator, based on the rest of your comment. Simon Peyton Jones makes a graph with two dimensions, useful/useless and safe/unsafe. The question he gets at is: how can one distinguish between effectful and effect-free computations in a programming language? He proceeds to characterize most useful languages as unsafe, and Haskell as useless but safe. He then spends the majority of the video talking about how useful languages are becoming safer, and at the same time how Haskell must become useful.
https://youtu.be/iSmkqocn0oQ
The famously friendly "Learn You a Haskell" book features its first "helloworld" program deep into the middle of the book, _after_ functors and (if I recall correctly) monads. It takes a very special beginner programmer to push that far through, working in the REPL, before they can write programs that do basic I/O.
I teach functional programming to college sophomores and juniors, and I would love to teach them Haskell. But I have to meet them where they are, and it would be difficult to do in Haskell. This is why we have taught either F#, Scala, or LISP over the years. F# in particular has a lot of the aesthetic qualities of Haskell while allowing impurity or mutability escape hatches without too much trouble. If somebody has truly beginner-friendly Haskell resources, I would love to hear about it-- I'm apparently not smart enough to chart that path myself.
It is important to clearly understand that Simon uses the word "useless" in the sense of having no side-effects on the external world i.e. if state changes are not reflected in the external world at some point then there is no practical purpose to it and hence "useless".
Functional languages solved this by using the type system at different levels to combine both effectful and effect-free computations cleanly.
I think this article tries to figure out where can Haskell be the best.
As for a platform? If Haskell can offer the most secure, correct, and trusted web apps(the biggest platform), created with the help of LLM's, and they can use LLM's to make reading Haskell intuitive, that's a good place.
Haskell can 100% be used to create all of these kinds of apps.
- Copilot (by NASA)
- MicroHs — for running Haskell on an MCU
GUI library and/or basic keyboard/mouse I/O:
- Monomer
- sdl2
- gi-gtk4
GPU interaction library
- OpenGL bindings
- vulkan bindnigs
- Accelerate — numerical GPU computation with an NVIDIA backend.
Web framework with database access, auth, users, routing, and templates:
- IHP
- Yesod
https://news.ycombinator.com/item?id=15486063
I've devised a way of programming imperatively in Haskell but in a way that maintains all the benefits of the type system ("make invalid behaviours unrepresentable") but I don't think that moved the needle on Haskell's popularity...
So Haskell is asking of them that they unlearn most of the things they’ve learned. It’s unfamiliar, and people react in a hostile way.
In reality, objectively speaking, it’s a very fine language to work with.
also the stuff i can now build in haskell with computer aid is epic. earlier this week i stood up what i believe is one of the/ if not the: best step file format reader writer on like every axis. some c ones are 20-30 percent faster on the largest possible cad assemblies i could try out.
an important axis that folks neglect to consider: the main way llms are getting scaled up for better coding is metric megatons of reinforcement learning traces, and type checking thats fancy gives a cheaper and faster training feedback loop.
with an llm as a sortah insane manic intern im looking over the shoulder, so to speak, im able to build the apis and designs i can see but cant type anywhere near the same scale. but i can specify the keystones for the exact designs quite compactly and then the agent kinda acts as a compiler inhave to correct and iterate running
Live step-through debugging and interactivity we think is pretty underrated in the Haskell ecosystem.
But incremental build has no reason to be slow, if the scope is as fine-grained as the function and type level.
(Disclaimer, I work at Tweag and recently did some work on the project)
The jvm world has achieved a few of these goals, and is in some ways an exemplar for these lofty goals.
Long term api stability, innovation, mapping hardware to software etc etc .
It just didn't get anything like the adoption that Solidity had at the time.
Some languages are here merely to inspire others.
Not that Elm is such a success... But it is "simple" (Haskell and Perl are not; they big).
Haskell also heavily inspired Rust, not in terms of syntax, but Rust traits and enums are very similar to Haskell type classes and ADTs.
As a vehicle for PL research, Haskell has been very successful. Practically every language introduced after ~2015 includes some variant of ADTs, option types, and result types. Many include type class analogues, too.
> we are going to build the best onboarding experience in the programming language ecosystem
> This can only be done if we commit to unix principles > write programs that do one thing and do it well
Rust is so approachable because Cargo does not subscribe to "do one thing". In fact Cargo does a bunch of things. Which is very convenient for newcomers, because they only need to learn one thing instead of a bunch (and how they interact).
The same holds for a GUI like a file explorer with buttons and interactions like drag / drop or marquee select, which is a bunch simpler than chaining 3 programs together to delete 30 old files and move some folder into a subdirectory.
It also explains why the most successful tools within the land of Unix philosophy are stuff like AWK, which really don't just do one thing. Or why PowerShell is less usable than GNU. Or why Emacs is an 'operating system'.
It's also a reason why the installation experience for Haskell is so bad: there are a bunch of programs and users don't know where to start and what they need.
> Cabal and Stack: which one should I install? > We recommend installing both.
One thing and one thing well.
Atleast it seems they've added a combined installer for these tools since the last time I've checked.
I went through several iterations, to get something that I could throw arbitrary packages at from Hackage, GitHub, etc. The result was a hacky mess containing a GHC plugin to dump Core code, a library to dynamically generate and evaluate strings of Nix to handle dependencies, shell scripts that piped `:t` commands through GHCi, and so on.
It was annoying, not because of the effort involved (I was doing weird, bespoke things; so it's no surprise it needed weird, bespoke code to be written); but because all of the functionality I needed already existed, just buried deep inside GHC/Cabal/etc.
Admittedly the GHC API has gotten much better in recent years; but there's no way the developers of "one tool to rule them all" can predict all of the different things that users will want it to do. Indeed, it's probably wise for such tools to avoid supporting/maintaining particularly weird/niche uses!
Having a collection of tools instead, which "do one thing and do it well", side-steps that problem entirely: users with weird use-cases are empowered to plug things together in a way that suits their needs, without needing the devs to add special features/flags just for them (or maintain their own forks with such flags, etc.)
> It also explains why the most successful tools within the land of Unix philosophy are stuff like AWK, which really don't just do one thing. Or why PowerShell is less usable than GNU. Or why Emacs is an 'operating system'.
I am not really sure this is true. I find my self composing Unix tools (partly because I don't know AWK that well lol) and I think 'do one thing well' when can mean easier time thinking how things interact and from primitives rather then one big opaque program. I agree for this to work things have to sit well together and adherence philosophies and respecting the boundaries of the other programs is an important thing to do.
Cabal and Stack step on each others toes constantly and it does seem confusing. I am a masochist so use nix on top of this and there a a very many ways to go when you do that for Haskell projects.
If I'm on NixOS, should I be installing via ghcup, stack, or nix?
I recall wanting to use Haskell packages that were only available in Nix, but nobody had bothered to make just a normal package.
I got into Haskell because I wanted to learn ADTs, and quickly found I really appreciate the ways that purely functional programming tickles my brain!
NixOS has been described as a "purely functional Linux distribution" and I liked the sound of that at first. I haven't figured out what this means, lol, but I tried it anyway and quickly found I really appreciate it's declarative configuration.
https://edolstra.github.io/pubs/nixos-jfp-final.pdf
That of course hurts market share.
It's pretty easy to override things in Nixpkgs though, whether at the system level, or for one application, or just a particular dependency deep in the tree of one script.
Nixpkgs has a bunch of powerful functions to make this easier, e.g. callCabal2nix, makePackageSet, etc.
https://nixos.org/manual/nixpkgs/stable/#haskell-overriding-...
https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
Every other language does/must do the same since Ubuntu/Debian have 2+ years old packages.
I decided to go with GHC via nix-shell, which worked fine, but it's a different path than I went with installing Rust (global rustup), and I'm not sure how to evaluate the pros/cons of each. I miss having ghci invocable anywhere, but doubt that's a good reason to change.
Also, ghcup failing on my Rasberry Pi was a fun troubleshooting experience! I don't remember how I got around that one either, but they eventually fixed the issue.
Beginners "I'm confused"
Haskell community "well that's certainly your fault, this isn't hard"
OK, so I put this into Gemini: "show me a non-trivial haskell function and type signature with at least five distinct arguments"
And I get:
---
processRecord :: (a -> b) -> Maybe c -> [d] -> (e -> Bool) -> (b, c, [d], e) -> Either String (b, c, [d], e)
processRecord transform mVal items pred (bVal, cVal, dList, eVal)
---My brain just crashes after the "::".
For the beginner, there isn't enough syntax on offer to discern who's doing what to whom here.
Is there a "function signatures for dummys" somewhere?
If someone told me German was easy to learn, I wouldn’t get an LLM to generate me a complex sentence with two clauses and three adjectives and then be like “sure about that?”
`processRecord :: (a -> b) -> Maybe c -> [d] -> (e -> Bool) -> (b, c, [d], e) -> Either String (b, c, [d], e)`
Says: “ give me: 1) a function of a to b, 2) a ‘c’ wrapped in a Maybe, 3) a list of d’s, 4) a function of e to a Bool, 5) a 4 tuple of a, b, list of d’s, and an e
And I will give you either a String or your original tuple back”
It doesn’t really do anything so there’s not much more to explain
If I ask my grandma what she thinks of the supposedly easy Python syntax, or C-style curly braces, her brain would similarly crash. Unless she read an intro to Python or C first.
In other words, do not confuse "I'm unfamiliar with this because it doesn't resemble what I know" with "hard to understand".
There's valid feedback in the form "after reading the free Learn You A Haskell or some chapters from Real World Haskell, I cannot figure out how to write a useful program", and then there's "I asked ChatGPT to write some code and I cannot figure out the basic syntax elements because I couldn't be bothered to read anything about the programming language first".
The means of getting over the hump with this syntax just has not been found.
Seems dishonest.
This in response to a quoted statement from TFA about beginners.
The moderation and feedback here strangely congruent with the syntax.
Surely you understand "the moderation" here on HN and "the Haskell community" are not the same? Over here, people are reacting to the tired old trope of "I don't understand this unfamiliar syntax that I didn't bother to learn first!".
I'm not bitter.
Just post the language that makes your example code look acceptable.
If you throw a beginner at any non-trivial code in any language without teaching them anything about the language, then, yeah, it'll be hard for them to figure it out. That says nothing about the language itself, though. That's pretty obvious to everybody.
> Is there a "function signatures for dummys" somewhere?
Yeah, of course. There's actual beginner material, here's one example:
https://learnyouahaskell.github.io/types-and-typeclasses.htm...
Not hard to find, and not the only introduction to the language that covers this material. I guess you never bothered to look, or even to ask Gemini.
In this day and age, where you used an LLM to give you a random Haskell example, you cannot ask "is there an introduction...?". That's lazy and dishonest. Google it (Learn You A Haskell would have been one of the first results) or ask the same LLM you used for your contrived example: https://chatgpt.com/share/6af86ef7-fa4c-83e9-b32f-7daeb7753d...
It's not tough love, it's that you're being dishonest.
-- Here you go
-- Oh my god, it's non-trivial
>Languages
>Haskell 81.9%
https://leangineer.com/blog/realworld-in-lean/
https://news.ycombinator.com/item?id=50088748
though i have thought about it.