6 ms·

The thought crosses my mind that Haskell may be uniquely suited for AI coding using a very small context window (cheap). Haskell encourages small functions and

The thought crosses my mind that Haskell may be uniquely suited for AI coding using a very small context window (cheap). Haskell encourages small functions and no global state. So you may be able to capture all the relevant context for editing a Haskell function within a few hundred or few thousand tokens. That would be better than some other languages. Plus the strong typing could help AI agents catch errors. I have not played around with it to see how that plays out with agentic coding. But it does seem like an interesting idea.

idle_zealot 5mo ago
I suspect that the compact nature of the syntax would require more tokens spent "thinking" to get decent results. It might be more efficient for simple code though. Either way worth testing. Surely someone must've set up a "how well LLMs handle Xlang" benchmark suite.
- ShinTakuya 5mo ago
  I think the main reason more time might be spent thinking is because there's relatively less training data on Haskell out in the wild, meaning an agent may have to check back and forth with static analysis to figure out what's valid. Compact syntax is generally only a good thing for LLMs because it saves context windows and tokens.
- pianopatrick 5mo ago
  I haven't seen such a benchmark although maybe it exists. As far as benchmarks go, I'd also like to see benchmarks that try to find what LLMs are good at. Most of the benchmarks seem designed to give LLMs hard problems and see if they can succeed. In that sense a "good" benchmark is one with a low pass rate. But if we're going to do agentic coding we also need to know the opposite. We need to know which types of tasks given in which format LLMs will succeed at with like 95%+ accuracy. Then we can more easily build multi prompt pipelines with high confidence in each step.
the-grump 5mo ago
As someone who loves Haskell more than any other language, some challenges are - the tooling is decades behind, say, Rust or Go - finding the right library in looks very different in Haskell--you frequently start with the signature on Hoogle. Agents can learn this but it's not the same as "web search" - creating the right solution also looks different. It's usually borne out of thinking about the types and coming up with the correct algebra. Again models can probably learn to create the right types and orient the solution around that, but it's not automatic - same today as yesterday, laziness is a blessing and a curse. The runtime can do unpredictable things when you suddenly evaluate a deep thunk - GHC directives effectively mean there are multiple "Haskells" Some of those are a result of the "avoid success at all costs" mantra. You can't shake that off in a day. It will take a concerted effort to make it more amenable for seamless adoption. Haskell continues to be my favorite language to write and read, but Rust is the more practical language with a rich type system. If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript.
- mhitza 5mo ago
  No way tooling is decades behind. You have a decent LSP, debugger, package manager and REPL. Laziness is hard to observe, maybe Strict and StrictData would become more popular in use within this context. I haven't checked in a while now if effects have become the norm in the ecosystem, or if some solution exists for "string" types, but for me all of Haskell's expressivity is lost in the noise of endless conversion function, wrapper types when stacking monads, and import fiddling.
  - Pay08 5mo ago
    The package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.
    - nh2 5mo ago
      No, this is not the reality of using Haskell packages. The problem you describe was solved more than a decade ago. You use a Stackage snapshot (https://www.stackage.org/lts https://www.stackage.org/lts) which is a curation of packages that work together, similar to a Linux distribution like Debian, carrying one version per package. Our company using Haskell has not spent 1 minute doing "dependency resolution" in the last 10 years, not has anybody we know.
uHuge 5mo ago
Yup, it was mostly pleasure AI coding a company codebase in Scala. I'm considering it for next projects for this reason although my understanding and intuition for Scala code is much weaker than for Python.
isatty 5mo ago
As an intermediate Haskell programmer, I’ve found that using AI to debug or learn Haskell is a better use of time than generating a lot of code with it. Even without AI most of my Haskell time is spent thinking. Also, I hand writing Haskell is one of my small after work pleasures.
- shideneyu 5mo ago
  Much agreed
internet_points 5mo ago
There are lots of people successfully using agents with Haskell, for example * https://github.com/digitallyinduced/ihp/ https://github.com/digitallyinduced/ihp/ is mainly written with Claude now * https://jappie.me/haskell-vibes.html https://jappie.me/haskell-vibes.html is gushing over agent-written Haskell * https://discourse.haskell.org/t/anti-llm-sentiment-considered-harmful/14008 https://discourse.haskell.org/t/anti-llm-sentiment-considere... huge thread about the divisiveness of LLM's from some person who loves using them with Haskell I can see how agent coding is a nice fit for Haskell, since LLM's tend to be best at tasks where you can easily verify the output – and GHC lets you easily verify much more of your domain than say Python (sure you can test some of what dynamic typing doesn't catch, but LLM-written tests do not always do what you think they should[0]). At the same time, the LLMs tend to not code golf unless asked to, and they don't care if they have to wait for dependencies to compile, so that takes away the two major Haskell time sinks. [0] https://haskellforall.com/2026/05/type-out-the-code#:~:text=scrutinize%20those%20tests https://haskellforall.com/2026/05/type-out-the-code#:~:text=...
angled 5mo ago
I was a little disappointed with the results I was seeing in F#. I thought the .NET + GPT-5.* pull through would be sufficient but it never seemed to work out. Maybe I just wasn’t approaching it correctly.
- Paradigma11 5mo ago
  I am using https://github.com/github/spec-kit https://github.com/github/spec-kit and am pretty content. I also tell it in the constitution.md to generate the .fsi files first, then write tests for it before implementation. That might very well be useless superstition since it is soo easy to fool yourself.
  - Paradigma11 5mo ago
    Also tell it to prefer easy language constructs with a need to justify anything more complex. I am currently trying to add elmish since its mind numbingly boring explicit plumbing is something I no longer have to do.
    - angled 5mo ago
      Thanks, I will try that!
jappgar 5mo ago
"no global state" sure but sprawling monad constraints mean you're jumping around more than other languages. The terseness of Haskell just hides the inherent complexity of the problem. The AI (or human) still needs to uncover that complexity in order to do non-trivial things.
thesz 5mo ago
I think you may find helpful this [1] almost 20 years old [2] agent. [1] https://github.com/augustss/djinn [2] http://lambda-the-ultimate.org/node/1178 The context window it requires for AI coding can be as short as half a dozen of tokens.
iLemming 5mo ago
[dead]
epolanski 5mo ago
I had a good experience extending the Elm compiler, written in Haskell. AI did very good with it (both Opus 4.5 and GPT 5.4). It has a good time reasoning on compiler feedback and iterating for the reasons you mention. But I still don't like Haskell and lisps for the very same reason: they don't scale. Every single project out there needs to reinvent the wheel at language level (in form of compiler extensions or DSLs). Makes the whole ecosystem hard to contribute and leverage. People can keep saying how great lisps or Haskell are all they want, but the fact remains that very ugly languages everybody hates somehow can produce software so good that makes you adopting the language bearable. There isn't a single software that makes me (personally) go "yeah, I want to learn Clojure/Racket/Haskell so I can use X". Whereas stuff like Laravel or Rails or Redis or Unreal Engine can sell me on PHP, Ruby, C/Lua, C++ even though I'm not particularly fond of any of those languages.
- simonmic 5mo ago
  I didn't understand what you meant by "haskell and lisp don't scale". Are you saying their library ecosystems are weak ?

idle_zealot 5mo ago

I suspect that the compact nature of the syntax would require more tokens spent "thinking" to get decent results. It might be more efficient for simple code though. Either way worth testing. Surely someone must've set up a "how well LLMs handle Xlang" benchmark suite.

ShinTakuya 5mo ago
I think the main reason more time might be spent thinking is because there's relatively less training data on Haskell out in the wild, meaning an agent may have to check back and forth with static analysis to figure out what's valid. Compact syntax is generally only a good thing for LLMs because it saves context windows and tokens.
pianopatrick 5mo ago
I haven't seen such a benchmark although maybe it exists. As far as benchmarks go, I'd also like to see benchmarks that try to find what LLMs are good at. Most of the benchmarks seem designed to give LLMs hard problems and see if they can succeed. In that sense a "good" benchmark is one with a low pass rate. But if we're going to do agentic coding we also need to know the opposite. We need to know which types of tasks given in which format LLMs will succeed at with like 95%+ accuracy. Then we can more easily build multi prompt pipelines with high confidence in each step.

the-grump 5mo ago

As someone who loves Haskell more than any other language, some challenges are - the tooling is decades behind, say, Rust or Go - finding the right library in looks very different in Haskell--you frequently start with the signature on Hoogle. Agents can learn this but it's not the same as "web search" - creating the right solution also looks different. It's usually borne out of thinking about the types and coming up with the correct algebra. Again models can probably learn to create the right types and orient the solution around that, but it's not automatic - same today as yesterday, laziness is a blessing and a curse. The runtime can do unpredictable things when you suddenly evaluate a deep thunk - GHC directives effectively mean there are multiple "Haskells" Some of those are a result of the "avoid success at all costs" mantra. You can't shake that off in a day. It will take a concerted effort to make it more amenable for seamless adoption. Haskell continues to be my favorite language to write and read, but Rust is the more practical language with a rich type system. If you're looking for something approaching Haskell's expressiveness but with fewer of these issues, check out PureScript.

mhitza 5mo ago
No way tooling is decades behind. You have a decent LSP, debugger, package manager and REPL. Laziness is hard to observe, maybe Strict and StrictData would become more popular in use within this context. I haven't checked in a while now if effects have become the norm in the ecosystem, or if some solution exists for "string" types, but for me all of Haskell's expressivity is lost in the noise of endless conversion function, wrapper types when stacking monads, and import fiddling.
- Pay08 5mo ago
  The package manager/build system is anything but decent. Any Haskell project will involve at least 24 hours worth of manual dependency conflict resolution.
  - nh2 5mo ago
    No, this is not the reality of using Haskell packages. The problem you describe was solved more than a decade ago. You use a Stackage snapshot (https://www.stackage.org/lts https://www.stackage.org/lts) which is a curation of packages that work together, similar to a Linux distribution like Debian, carrying one version per package. Our company using Haskell has not spent 1 minute doing "dependency resolution" in the last 10 years, not has anybody we know.

uHuge 5mo ago

Yup, it was mostly pleasure AI coding a company codebase in Scala. I'm considering it for next projects for this reason although my understanding and intuition for Scala code is much weaker than for Python.

isatty 5mo ago

As an intermediate Haskell programmer, I’ve found that using AI to debug or learn Haskell is a better use of time than generating a lot of code with it. Even without AI most of my Haskell time is spent thinking. Also, I hand writing Haskell is one of my small after work pleasures.

shideneyu 5mo ago
Much agreed

internet_points 5mo ago

There are lots of people successfully using agents with Haskell, for example * https://github.com/digitallyinduced/ihp/ https://github.com/digitallyinduced/ihp/ is mainly written with Claude now * https://jappie.me/haskell-vibes.html https://jappie.me/haskell-vibes.html is gushing over agent-written Haskell * https://discourse.haskell.org/t/anti-llm-sentiment-considered-harmful/14008 https://discourse.haskell.org/t/anti-llm-sentiment-considere... huge thread about the divisiveness of LLM's from some person who loves using them with Haskell I can see how agent coding is a nice fit for Haskell, since LLM's tend to be best at tasks where you can easily verify the output – and GHC lets you easily verify much more of your domain than say Python (sure you can test some of what dynamic typing doesn't catch, but LLM-written tests do not always do what you think they should[0]). At the same time, the LLMs tend to not code golf unless asked to, and they don't care if they have to wait for dependencies to compile, so that takes away the two major Haskell time sinks. [0] https://haskellforall.com/2026/05/type-out-the-code#:~:text=scrutinize%20those%20tests https://haskellforall.com/2026/05/type-out-the-code#:~:text=...

angled 5mo ago

I was a little disappointed with the results I was seeing in F#. I thought the .NET + GPT-5.* pull through would be sufficient but it never seemed to work out. Maybe I just wasn’t approaching it correctly.

Paradigma11 5mo ago
I am using https://github.com/github/spec-kit https://github.com/github/spec-kit and am pretty content. I also tell it in the constitution.md to generate the .fsi files first, then write tests for it before implementation. That might very well be useless superstition since it is soo easy to fool yourself.
- Paradigma11 5mo ago
  Also tell it to prefer easy language constructs with a need to justify anything more complex. I am currently trying to add elmish since its mind numbingly boring explicit plumbing is something I no longer have to do.
  - angled 5mo ago
    Thanks, I will try that!

jappgar 5mo ago

"no global state" sure but sprawling monad constraints mean you're jumping around more than other languages. The terseness of Haskell just hides the inherent complexity of the problem. The AI (or human) still needs to uncover that complexity in order to do non-trivial things.

thesz 5mo ago

I think you may find helpful this [1] almost 20 years old [2] agent. [1] https://github.com/augustss/djinn [2] http://lambda-the-ultimate.org/node/1178 The context window it requires for AI coding can be as short as half a dozen of tokens.

iLemming 5mo ago

[dead]

epolanski 5mo ago

I had a good experience extending the Elm compiler, written in Haskell. AI did very good with it (both Opus 4.5 and GPT 5.4). It has a good time reasoning on compiler feedback and iterating for the reasons you mention. But I still don't like Haskell and lisps for the very same reason: they don't scale. Every single project out there needs to reinvent the wheel at language level (in form of compiler extensions or DSLs). Makes the whole ecosystem hard to contribute and leverage. People can keep saying how great lisps or Haskell are all they want, but the fact remains that very ugly languages everybody hates somehow can produce software so good that makes you adopting the language bearable. There isn't a single software that makes me (personally) go "yeah, I want to learn Clojure/Racket/Haskell so I can use X". Whereas stuff like Laravel or Rails or Redis or Unreal Engine can sell me on PHP, Ruby, C/Lua, C++ even though I'm not particularly fond of any of those languages.

simonmic 5mo ago
I didn't understand what you meant by "haskell and lisp don't scale". Are you saying their library ecosystems are weak ?