Anti-LLM Sentiment Considered Harmful

1

The recent anti-LLM sentiment on this forum feels misguided to me.

I adopted Haskell at work about five years ago, but only a small subset of our microservices ended up using it. The main reason is not the language itself, but the ecosystem challenges around it.

In practice, adopting Haskell in industry often means taking on a significant maintenance burden. I’ve probably averaged an extra 10–15 hours of work per week dealing with ecosystem gaps, library limitations, abandoned packages, missing integrations, or implementations that does not fully match official specs. I don’t want to single out specific libraries or maintainers because maintaining open source software is difficult and often thankless work. But the reality is that many of the tools companies need to confidently standardize on Haskell either do not exist, are incomplete, or require substantial internal investment.

LLMs are the first thing that has materially changed that equation for me.

Since December, I’ve been aggressively rewriting services in Haskell specifically because LLMs made it finally feel practical. They dramatically reduce the cost of filling ecosystem gaps, debugging obscure issues, writing integrations, understanding unfamiliar codebases, porting libraries, and maintaining internal tooling.

For the first time, I feel confident that ecosystem shortcomings are no longer a hard blocker. If a library is missing, abandoned, incomplete, or needs to be adapted to our use case, I now feel that my team can realistically bridge that gap ourselves with the help of LLMs.

That shift has completely changed how my team thinks about our roadmap. Instead of worrying about whether the ecosystem can support us long term, we’re excited that we can standardize on a stack we genuinely enjoy using and systematically close the remaining gaps over time.

Ironically, I think LLMs may end up being one of the best things to happen to Haskell adoption. And honestly, I think the community should be far more concerned about Haskellers gradually moving to Rust because of ecosystem and tooling frustrations than about LLM adoption.

33 Likes
2

Like we’ve always said: avoid success at all costs. It rings even truer if you consider the wider societal impact.

Edit: Credit to @boarders on mastodon: Boarders: "each passing year brings ever more wisdom to "avo…" - Mathstodon

26 Likes
3

If you genuinely believe that the alternative (critical PRs sitting ignored for years, missing libraries never being built, and ecosystem gaps remaining unresolved indefinitely) is preferable, then I don’t think you’re actually interested in seeing Haskell succeed in industry.

5 Likes
4

I too have nondescript issues with how the ecosystem is currently structured and I will not divulge them. It’s safe to assume we’re in lockstep on most of these things.

Moving to Rust… for what? Is the implication that Haskell and Rust are interchangeable? I only have about two weeks of experience in the latter, but it was more than enough for me to comprehend just how much of a pain in the butt keeping track of allocations is.

7 Likes
5

These are issues with a lack of individuals willing to have vision in these areas and review PRs more than no-one being willing to code. The best uses of LLMs (as I understand it) require expert reviewers, which is more what we’d lack.

I don’t think you’d keep expert reviewers if you’re asking them to stop writing code and just review slop.

10 Likes
6

If you told anyone 10 years ago what is possible today with LLMs they would not have believed you.

It’s an absolutely marvelous achievement that they can create working code at all. I mean yeah, it is futuristic.

And yet, there’s some bitter aftertaste. And for me it’s mostly:

  • people not understanding that they’re probabilistic tools
    • they hallucinate all the time
    • they make subtle errors all the time
    • reviewing slop is hard
  • a swath of low-effort one-off vibecode projects that neither have strong visions, nor any particularly good QA
    • someone vibe-coded an operating system and showed it off on reddit, then an actual hardware driver engineer noted that they can include his work when the next linux release is out (and LLMs are trained on it)… legal? Yeah. A bit disrespectful? Also yeah.
  • the mechanisms that used to exist in open source are starting to break down (trust relationships between open source maintainers and end users, etc.)
  • an insane obsession in industry with productivity, but not with excellence… at times I’m really struggling to maintain motivation and goodwill

Then there’s all the other parts of this: the social impact, the cognitive impact, the political impact, the environmental impact… the greed and scam tactics of big AI corporations.

Some of my lecturer friends are saying universities are in a deep crisis and they don’t know what to do with students cheating and turning in slop and nothing else.

It’s all around us. It’s everywhere. In the news, in every other discussion, in private chats. It’s exhausting.

But what this technology does with our industry as a whole is deeply troubling to me and has made me quite emotional recently. I don’t think open source will continue in the same fashion as it did, that’s for sure. And I’m looking back at ~15 years of open source involvement and how much of my time and energy and focus I invested in all of this. And the future does not look very appealing to me.

Is that the fault of LLMs? Maybe not… it’s largely about how we use them. But it appears it is very challenging to use them in a sensible and responsible way.

55 Likes
7

I’m glad to see LLMs lowering the barrier for people trying to use Haskell. They can understand gaps in Haskell tooling, explain concepts and APIs that are poorly documented or undocumented, and reduce some of the routine work involved in maintaining libraries, such as setting up CI and answering user questions.

Of course, you can always abuse any LLM to produce low-quality output regardless of the language.

From an economic perspective, a lot of money and capital is flowing into the LLM industry; I hope at least the Haskell community can benefit from this trend.

12 Likes
8

Whether the Haskell community adopts AI will have little impact on the trajectory of AI itself. What it will impact is whether Haskell becomes irrelevant over the next decade or manages to build a healthy, sustainable community.

I just read about another company moving away from Haskell, and that should be a wake-up call for anyone who cares about the future of Haskell.

7 Likes
9

Haskell isn’t becoming irrelevant anytime soon. AI doesn’t really have a part to play tbh.

Also that’s not a wake up call. Companies and managers and “leadership” do dumb stuff all the time.

This is speaking as someone who has been doing Haskell professionally for a decade now. I’m not worried and AI is really unimpressive and arguably a negative.

10 Likes
10

I guess you mean scarf I saw the CEO keep complaining about compiler speed and stalling him with AI, lol.

3 Likes
11

Yep, it’s Scarf. Their founder is a huge Haskell fan, and they’re still switching away from it. I also just adopted their ClickHouse package at work, which I guess is now likely to be abandoned.

1 Like
13

I can resonate with the OP. Learning about AI tools, capabilities, limitations and recent developments has been a hobby of mine for the past few months. I am wholly convinced that in the hands of a good engineer, AI coding agents can massively increase productivity, while at the same time actually increasing the quality of the work. The main reason for that is having much more time left after solving the problem to actually make the solution nice and tested.

There’s indeed a negative sentiment on this forum, expressed by some vocal people. Don’t let it bring you down though. As with any new technology, there will be dissenters. There are also still plenty of programmers who code on effectively a type writer, as opposed to an editor with a language server, multi cursor, extensions and whatnot.

I think the best thing we can do is show really cool and beautiful stuff and say how LLMs helped us write it faster and how it helped improve code quality.

See this PR for example: Making sure you're not a bot!

I used opencode (with one of its free models) to speed up the development of that PR, and I’m very happy with the result. The goal of the PR was to improve typing and to make it easier to run/test the script, while having the same functionality. That makes it very easy to argue that the quality of code strictly improved.

I could have done the same without LLMs, because I have quite some expertise in both Nix and Python. However, I would not have been able to go from never having seen that code before, to a PR in just a single day, and that is the power of the LLM.

15 Likes
14

My perspective on the matter is that reviewing LLM-generated PRs is incredibly tiring. A human is able to design something that spans several files over the course of several days, and this is simply not something that LLMs are good at, since they have to get their context re-injected all the time, but also lose some of the context to compaction because the context window is fairly limited. They inflict such a burden on the reviewer (me) that I have no appetite to use those tools on my colleagues.

It’s very difficult (maybe impossible?) for this technology to approach the cognitive capacity of a human brain in a way that produces PRs that are easily readable, as well as PRs that follow the same design or vision. Moreover the tools themselves are optimised for spending tokens so that you can help their owners repay their investors. As such, alongside the lack of reproducible results, I don’t consider them adequate development tools.

16 Likes
15

This would not help convince me. I don’t see quality as a big problem. My main problem is the concentration of power in like three immoral companies. That has never been good for the world.

20 Likes
16

Those wondering, why people don’t embrace AI, can consult with AI and obtain a short summary.

Why would they bother to discuss this topic with humans ?

17 Likes
17

Ironically, I think LLMs may end up being one of the best things to happen to Haskell adoption.

100%.

People might want to ignore all that vibe-coding nonsense for a moment. There is another, very positive side: Everyone now has a professional pair programmer available 24/7, who teaches idiomatic Haskell really well and helps improve your code to a high level. It’s never been this fast or enjoyable to dive into Haskell (if you want).

Remember the talk: “How to Learn Haskell in Less Than 5 Years”. It’s over, man :slight_smile: .

I wish I had such tool 10 yrs ago when I started my Haskell journey…

8 Likes
18

Professional in that you pay for it, or competent?

6 Likes
19

Competent. For example by asking WHY the code should be this way and not the other. Or by improving code to be “more” idiomatic. Its about asking, not about to let THEM do all the things. And yes, It’s always worth to pay for that.

3 Likes
20

I find this supposed pair programmer to be superficially very competent but not someone I would hire - good coworkers/employees are people who don’t need that level of focus from me.

I’ve given AI a fair shake by now, but I just moved slower with it and I don’t see a path to that improving given the current tech. Maybe the way I work is just weird, but I find that AI requires so much synchronous attention that I have to work a lot harder during the workday to get output when I use it. Because without AI, coding Haskell & keeping up with mgmt expectations was pretty effortless. I was hoping AI would level that up - same output, but do it while I’m doing other stuff. NOPE :​/

6 Likes
21

Would you mind sharing your setup then? I fear that my many encounters with LLMs have only raised statistically probable code, not good code. Or maybe all your code is so great that your LLM has no choice but to produce good code?

3 Likes