Prominent Haskell defector pilloried by anti-AI purists Another day, another programming language feels the heat from AI. A prominent Haskell-based software platform is shifting new development to Python, with its founder arguing that Haskell's tooling and ecosystem have been slow to adapt to AI-assisted development. “Haskell is in real danger,” warned Scarf founder Avi Press, in a …
Okay ... what is your error rate per function point using different language X, compared to using your previous language, language W?
... and ...
What are other peoples' error rates when modifying your code in different language X, compared to their error rate when using your previous language, language W?
Quality matters.
> what is your error rate per function point using different language X, compared to using your previous language, language W?
Funnily enough W is an actual language and I think there was also an Algol W.
X would be a proprietary SpaceXAI language that can only express what passes for thoughts from Musk's ketamine addled brain.
One of the benefits of Haskell is that if you can get the damned thing to compile in the first place, it almost certainly works correctly. I would have thought that was perfect for AI use: AI writes something, gets an error from the compiler, fixes it or tries a different approach, repeat until it works.
Getting an AI to write Python is like creating a ticking time bomb. Errors lurking in a line of code generally aren't detecting until that code is actually run - and some of that code may only run in rare circumstances, giving you latent bugs which are also hard to reproduce.
Yes, there are optional type annotations in Python, but even if you use them it's still not as robust as Haskell.
If the AI is so good, why not ask it to work on speeding up the Haskell compiler?
Hmmmm ... I wonder if this could be the AI psychosis RotM at play here, where a perfectly well-adjusted individual in love with Haskell, starts to dip his toes in AI (so-called), and in a relatively short time becomes an evangelist convert to the cult of YOLO?
I mean, Avi "gave OpenClaw its own" "email address", "personal gmail", "phone number", "GitHub account", and "service account in Scarf's Google Workspace" [ https://avi.press/posts/2026-02-17-how-were-using-ai-feb-2026.html ]. His autonomous clavi-bot agent then went on to thank him for that by putting together its very own OpenClaw "tamagotchi-style companion" Pet to replace him with it, iiuc [ https://github.com/clavi-bot/openclaw-pet ].
I'm not qualified to determine whether this is normal or not (that I'm aware of), but something does seem to be slightly amiss here ... imho!
The inevitable defense of vibecoding is that it lets people do things faster and create more code/features in the same time. The way that people talk about speed/quantity is as though it is itself the goal. Rather like the metric becomes a goal thing.
I don’t understand the obsession with speed/quantity. Not everything needs more and more features (for example). In many cases, quality (eg optimization/performance) is much more valuable to the customer. I just don’t get it.
Leaving AI aside for the moment, in the practical world, time is money. If you're doing something for a client or customer, then the number of man hours to get the job done is going to have a direct effect on the cost to the customer, and customers have finite budgets.
The big advantage to humans when developing something in Python is that you can write incrementally, testing as you go. If you are dealing with a problem that is a bit tricky, or something that you are unfamiliar with, you can very easily work on that one little bit separately, including typing (or copy-pasting) directly into the interpreter window, test it thoroughly, and then copy it into the part of the application you are working on, then then so on for the next bit.
This is a much faster way of working than typing a mass of code into an editor for a few hours, hitting compile, and then wading your way through masses of compiler errors, followed by wading your way through masses of seg faults and the like. It's faster that is if you measure things in terms of time to getting a final working product as opposed to just counting number of lines of code written (and re-written, and re-written) per day.
That doesn't mean that Python is suited to every problem. It does mean though that it is particularly suited to problem domains where a key criteria is developing working code and delivering it to a client on a tight schedule.
If you read the summary of the talk which Scarf gave about why they originally adopted Haskell, even then he stated that Haskell's build times were a major problem for humans to deal with. He also mentioned very limited library support, painful dependency upgrades, and "type safety" not actually working as well in practical terms as it does in theory (same type does not necessarily mean compatible meaning).
This doesn't mean that Haskell is bad, but it does imply that it was a poor choice for what they were doing.
A lot of the benefits that he now thinks he is seeing from switching to Python may in fact be the benefits of switching to a language which is more suited to the problem domain that he is working in.
This is not to say that Haskell is bad, it just means that it wasn't the right language for what he was trying to do. In fact the title of his talk implied that he was aware of that at when he started using it, but that he chose Haskell anyway because he thought it was the "cool" thing to do. He now apparently realized that it was a mistake to put "feelings" ahead of practicality.
I believe that there is no one size fits all language that is best for everything. I have used at least a dozen different languages for commercial projects at various times, and I don't think that having an emotional attachment to a language is a good idea.
The reasons that he gives for why Python is good for AI also happen to be the reasons why it is good for humans to use in the right sorts of problem domains.
So far as AI is concerned, I make very limited use of it and have been very disappointed in how it works out in practical terms. I suspect that a major problem is that English is in fact a very poor means of communicating ideas when it comes to programming, and that some other means of expression will have to be developed to make effective use of AI. That is, I think we need a programming language that operates at a higher level such that AI is just another stage in the compiler, rather than trying to figure out how to put concepts into English and hoping the AI can figure out what it is we were trying to say.
This is a much faster way of working than typing a mass of code into an editor for a few hours, hitting compile, and then wading your way through masses of compiler errors, followed by wading your way through masses of seg faults and the like
Of course, if you wrote a proper spec, designed the program, wrote the test spec, and reviewed it before diving into that text editor, there's a high probability that it would compile and run correctly first time. Proper design process saves a lot of time overall. Thank goodness engineers who build bridges and aeroplanes don't do it like software developers!
"Proper spec"
I have worked with people who were writing safety critical software for diesel engine controllers (for big lorries). They did the "spec, design, test spec, pseudo-code, code, test" cycle. It was very slow and expensive, and it most certainly didn't work first time. It was closer to working first time, and it had fewer latent bugs - but for most development, a faster cycle where you get to discover the spec is wrong is a better idea.
If you are writing a non-trivial program in Haskell, then no, it is very unlikely that your program will compile and run correctly the first time after doing all of what you just said.
And as for aircraft and bridge engineers, they very fortunately for their eventual customers don't work on new designs the way you claim to write software. They test their assumptions very, very, thoroughly as they go along, and adjust their designs and specifications when things aren't working as originally assumed.
I have worked on software for doing things like testing safety critical components in automobiles. It is routine for the product specifications to embed incorrect assumptions and require revision after testing has turned up problems. That's what the phrase "back to the drawing board" implies.
That's why it takes several years to develop a new mechanical product when correctness matters. Doing the specifications and drawings is the easy part. It's all the testing, failure analysis, and going back and correcting the initial design and specifications that takes time. This is why there is so much emphasis on modelling mechanical designs in software these days. It allows for more rapid incremental testing of designs virtually instead of having to build a succession of prototypes. With more problems caught in virtual testing as opposed to physical prototypes, the design iteration cycle is much faster.
When planes fall out of the sky or new bridges do fall down these days, it's usually because someone wrote a spec and built the thing without testing it because "the spec looks good and so should be right". I can think of several aircraft and new bridge failures in recent years because of cutting corners in the form of reliance on specifications rather than testing.
It's a truly horrible ecosystem. I remember trying to port it to 64-bit Solaris once. Even staying with all the standard GNU tools that already existed there it was a nightmare. I succeeded, eventually, after a long sequence of cross-compilation stages to port tools and compiler. Never again.
Not used Haskel but I imagine it's advantages such as strong type safety mean compilation takes longer than with other languages. You don't get owt for nowt.
Using a faster development iteration language may be legitimate if that's the critical factor, but one needs to be aware of the then corresponding downsides of doing so (often runtime errors instead of compile time errors).
Moving a project to another language just so it's easier to use with so-called "AI" seems like a decision where I hope the maker has an organ donor card (as they appear to be brain-dead).
(pure) functional programming languages might actually be a better match for AI, but of course they can't.
The referential transparency and the denotational semantics of declarative languages could be a natural fit for artificial reasoning (theorem proving) systems but AI is largely a glorified pattern matching system which has been trained on an enormous corpus of procedural (imperative) code.
An AI directed theorem prover might have some merit in this context but I wouldn't wager my money on that.
Hope and Miranda were the two functional languages that interested me back when — I am guessing they are now either very niche or extinct.
Hope and Miranda... I am guessing they are now either very niche or extinct.
Bob Hope has an uncredited appearance in the film "Scared Stiff (1953)" died in 2003, aged 100.
Carmen Miranda appears as "Carmelita Castinha", was aged 46 when she died in 1955
Bing Crosby is also uncredited, died in 1977, aged 74. "Bing" lives on in the guise of a search engine https://www.bing.com
He admitted that Haskell was a poor choice for the original version to begin with and that he chose it because he thought phrases like "type safety" sounded cool. Type safety is probably not that significant in terms of where your problems are going to be when doing usage analytics.
Python meanwhile has loads of high quality libraries that do exactly the sorts of things that usage analytics need to do, and code that someone else has written and that loads of other people have tested in real world conditions is code that you don't have to write, test, and debug yourself.
The pragmatic choice from the start would have been to use Python for this sort of problem.
"The people and ecosystems that use it well are going to move much faster than the people and ecosystems that do not."
That's a sales pitch, not a business strategy. Talking about a future that hasn't happened or even started to pan out yet. No one has taken AI and beat the tech bros at their own game with it. There has been no disruption. No paradigm shift. Just a bunch of delusional wannabes calling themselves software engineers now and a bunch of CVEs. There is no proof that the work "generated" by LLMs is actually faster than any of the more "legacy" processes once you're finally through cleaning up the mess in QC. If there was, we'd have AI firms putting traditional software out of business already. It's been over 2 years since coding was "dead." All we have is downsizing on the assumption AI will fill the skill gap. It has not.
Also, keep telling yourselves the deck isn't absolutely stacked against you with this AI stuff and submit yourself and your org to the all seeing eye out of FOMO and the slim hope you'll be the next big thing and not just put out of business by the AI you spend so much time training on your business domain. Like seriously, did we all forget how this fucking tech works folks? Do you really think you can do anything about it if they decide to fuck you?
They totally won't upload your entire orgs data to their cloud and if they "accidentally" do, they totally promise to delete it without looking at it. Pinky promise. It was only for QC. We can totally trust these guys. /s
People are fucking stupid to fall for this.
