It's been one of the plays that the F# community has also been trying to make (somewhat with a modicum of help from Microsoft's marketing arm, but not enough help from what I've seen) pitching F# as a language close enough to Python to feel familiar and useful to data science but with the performance help of rich ML types and the modern .NET performance ecosystem.
(To my experience: getting "fast" compared to Python seems easy for most functional languages. Getting data science out of Python seems hard for a lot of sociology reasons more than technical ones.)
Unoptimised/naive Haskell might be that slow. But that's true of a lot of languages and isn't particularly interesting to me. Java is slow if you do everything the naive way, too.
[0] https://entropicthoughts.com/on-competing-with-c-using-haske...
Java's most badly optimised type, is the String.
Both of them need a string-builder pattern, the default operators don't work around things to do the right thing for you. They expect you to understand how data works.
In this new AI-driven world, is there still place for such a luxury as functional programming?
I mean few people still code by hand, few read the generated code, models aren’t trained on functional languages, it’s inefficient token wise to use functional languages - while a lot become self-proclaimed software engineers overnight by just prompting LLMs.
Cannot confirm functional programming being inefficient token-wise, or worse at being generated than other paradigms. Claude is great at Haskell.
The difficult parts about Haskell, such as understanding type checker error messages, are gone thanks to LLMs.
Type-safe, side-effect free code degrades correctness a lot less under heavy LLM action in my experience.
As for token-wise inefficiency, this is based on my sporadic observations and discussions with friends and colleagues from the past three years. I can’t give you a fresh benchmark with latest models in a reproducible way. But I’m happily willing to accept your assertion at face value. This makes me curious to see for myself how the latest models perform, will perhaps set up a quick evals just out of curiosity.
From my past experience, the latest I’ve seen were Opus-4.6 and GPT-5.5 struggle a lot with standard GHC Haskell, no extensions, nothing fancy. Not that they produced impeccable Python or Rust. But it appeared to take several turns for obvious expressions, while at Java and TypeScript they were much better - fewer turns, time, and cost for the same verified results. I had assumed that the training set wasn’t large and diverse enough for Haskell and Scala, and this was the go-to explanation with everyone I talked about it. Generated F# code was good enough but not OCaml. With C++ there’s still quite some struggle, expectedly.
To me it resorted to the question, if we’re mostly generating code through LLMs now, which ones and what will it cost in total terms per task/capability completed. I’m wondering now if DeepSeek/MiMo or GPT-6 Luna can benefit from the terser, more (forgive the pun) load-bearing expressions.
> from the past three years [..] the latest I’ve seen were Opus-4.6 and GPT-5.5 struggle a lot with standard GHC Haskell
If your experience is from years ago, I totally get that. For my standards, LLMs were pretty bad before 2026.
I haven't tried any serious LLM Haskell before 2026-02, because it was just not a timesaver.
I had good experiences with Opus-4.6 already on Haskell, such as it having detail knowledge on async exceptions, allowing it to immediately pinpoint difficult bugs that me and other experts missed, e.g. https://github.com/snoyberg/conduit/pull/530
But most of my experience is from Opus >= 4.8. I found it excellent at writing difficult TemplateHaskell and Generics implementations, such as oneshotting Postgres JsonPath queries derived from lens-like field accessors on Haskell types.
Note it's still not great at writing general high-quality "engineering" stuff, e.g. Opus 5.0 writes functions that refer to things out of their scope, such as:
requireFooOr400 :: MyMonad m => Maybe Foo -> m Foo
requireFooOr400 x = case x of
Nothing -> throwHttp400 "Cannot perform [very specific action from the caller]: the inputs have no foo"
Just foo -> return foo
Same, and now seven months later a GBP 20 per month Plus subscription gets me basically all the GPT-6-Luna-xhigh I can eat, which does a tremendous job of Haskell. It's even helped me with some really gnarly things like this, which require deep knowledge of the GHC RTS: https://github.com/tomjaguarpaw/bluefin/commit/c298733bdd67d...
It's possible it's much slower when working on Haskell than it is on other languages. I wouldn't know because I've only tried it on Haskell. But I'm very happy (and extremely impressed) by it.
Fable has made an excellent tutor. Maybe it’s just because the exercises I have it generating for me are relatively simple, but I have yet to catch it suggesting non functional or non compiling Haskell code.
> inefficient token wise to use functional languages
where does that idea come from?
Surely there's way more content related to programming in Python, JavaScript, Go, etc. than in Haskell.
So you'd expect some things like: an LLM is likely able to come up with an approach that's suited to Python/etc., and an LLM is likely able to work its way through Python/etc.
My experience has been: when using an LLM with a nice language (Nickel-lang, a modular configuration language with types and contracts) that it frequently guesses slightly wrong as to what works (e.g. guessing wrong about how stuff like { x = x + 1 } would work) that it spends more tokens than it otherwise might.
But yes, terser source documents and low raw token counts could mean lower prediction rates and more prediction attempts needed to get intended results (again, especially if the model was undertrained in that particular language).
What I meant was really about the output tokens, on the API pricing level of interaction with an LLM.
Should be mandatory
However they claim using Haskell for data science is "fast", which doesn't really mean anything until you have numbers to show. A little benchmark with pandas and polars wouldn't hurt I guess.