[muragekibicho]

I'm not trying to be reductive but the article's a lot of words for "We're vibecoding our app now and the glorious (almost almighty) Haskell compiler is too slow for the agent to iterate it's mistakes until it gets it right."

[marcosdumay]

Mixed with some complaints on how the community doesn't like vibe-coding, and that if you insist on not letting AI think for you, you will be left to die in the dust of the other competitors.

The amount of certainty random people have that LLMs have already revolutionized software development seems to be directly proportional to the media awareness of the AI companies finance unsustainability.

[jimbokun]

Maybe overly verbose but makes an important point.

Slow compile times should have been a deal breaker for how they impacted human coders. LLM coding just makes the problem more stark.

[andersmurphy]

Yeah compile times have always mattered. It's why games often have a scripting layer in lua despite the engines being C/C++.

[weinzierl]

This thought completely neglects the idea that Haskell probably needs significantly less compiler runs because every run catches more errors and gives more information about them.

And that is not even considering how often the agent needs to run tests to get it right.

[derdi]

It seems pretty clear that they do only minimal live testing during the "open a ticket, implement something, deploy it in production, all while the customer is still on the call" cycles. So your second concern is probably not relevant in this particular setting.

Regarding the first, I think you're probably right, but then again, if there is a 15-minute base cost, it's hard to amortize that through fewer incremental runs of the compiler.

(Which isn't to say that I think they are doing the right thing.)

[aviaviavi]

The number of compiler runs doesn't matter as much as the total elapsed time it takes to finish the task. In just about every test we ran, LLMs are faster at building in Python than Haskell.

[andersmurphy]

Lisp/smalltalk programmers have been going on about this tradeoff for a long time. It mattered before LLMs too. Lisp/Clojure repl allowing you to compile tiny parts of your program inside your running program is incredible for your feedback/iteration loop.

Ironically, this is also what makes them shine with LLMs, the LLM has access to the running program and can modify it while it's running to get feedback instantly.

Complex type systems are cool. But, they are not free. I say this as someone who's first programming language was Haskell.

[cubefox]

> I say this as someone who's first programming language was Haskell.

Amazing. How did that happen? Is it true that functional programming is only counterintuitive because almost everyone starts out with an imperative language?

[andersmurphy]

Philip Walder (one of the creators of Haskell) was our lecturer for my CS introductory course. I'd never done any programming before then.

Yes, imperative languages were initially counter intuitive to me. OO was even worse. SQL was fine as it's more declarative/functional.

[lelanthran]

> The number of compiler runs doesn't matter as much as the total elapsed time it takes to finish the task. In just about every test we ran, LLMs are faster at building in Python than Haskell.

How much faster? IOW, what's the difference (in minutes/seconds, not in percentages) between vibing Haskell and vibing Python?

[lenkite]

I am wondering whether next year there will be re-write of Scarf after the vibe-code degenerative collapse of their source code into un-maintainability. At some point, the LLM patch/fix cycle will devolve into straitjacket.

[whateveracct]

Haskell Foundation member mind got cursed by wearing the CEO hat and he forgot to "avoid (success at all costs)" kek

[ghc]

I was puzzled by this article at first, but when you put it that way it makes more sense. The author also had a presentation awhile back about why Haskell is a terrible language for startups to adopt. I imagine that in the current venture environment vibe coding is being pushed heavily by investors since companies are effectively in an arms race where feature development cost is moving towards zero and investors don't care about individual companies because they have a portfolio of bets.

[pdimitar]

I don't think it has almost anything to do with vibe-coding. When I tried Haskell and OCaml some 3 years ago, they were infuriating in terms of tooling and just needless friction (don't ask, forgot, but it was mostly around package management and just entering a project and be able to run the program was a saga).

Iteration speed is not only to appease business people. As a long-time dev I prefer for my PL and its tooling to not stand in my way. I want to be enabled, not be left a scarred veteran with badges of honor like "Managed to install 5 dependencies and compile and run! And it only took me 3 hours!" or some such.

Compare to Golang, Rust, Elixir, and no small amount of others -- you add a dependency, run a command, twiddle your thumbs 30 seconds, done.

I want to solve problems. Not troubleshoot tooling that should have been prod-ready 10 years ago.

[ghc]

I've been using Haskell for 20 years. I've been running a company built on Haskell for 10. I have a very large legacy Haskell codebase. I've invested in several companies built on Haskell. Your anecdote is about your own lack of familiarity, nothing more.

Yes, companies can get into trouble with Haskell compile times, memory use, etc., but enforcing disciplined coding rules and advances in tooling solved the majority of the problems by 2016.

We use LLMs to assist in writing Haskell and have for several years. We keep track of compile times to catch regressions and on our largest code base an agent-driven change takes an average of 96 seconds (as of this month) to compile. Agents looking to do quick compile checks during code writing can run with flags that make the compilation run in less than 5 seconds. In all cases, running out test suites takes a lot longer than compile times.

The only time this isn't true is when you compile from cold start, as you would when using multiple work trees...which is the expected behavior when vibe coding features. So yes, I believe the issues they're running into have a lot to do with vibe coding. Check out all their integrations...Haskell's probably a poor match for what they do, but vibe coding integrations is probably what they need to do to get new customers.

[pdimitar]

To comment separately: lack of familiarity is true of course but do consider your bias -- familiarity should come quickly and easily. Long gone are my days where I wanted to wear badges of honor and suffer through difficult tooling, and I am willing to bet that's true for a lot of programmers.

We want to iterate and progress. You likely are used to Haskell's tooling quirks long time ago. Everyone else outside of the ecosystem does not have that advantage.

[pdimitar]

IMO from the info given in the OP it seems to me that they never actually needed Haskell, not playing to its strengths anyway, especially if they felt Python was an adequate replacement -- which it absolutely is not if you value the compile-time finding of bugs, better known as "a strong static typing system". But that's a separate discussion vector.

[markusde]

Somewhat of a tangent but it is actually called "glorious" in the official docs https://downloads.haskell.org/~ghc/7.4.1/docs/html/users_gui...

[woadwarrior01]

Granted LLMs aren't very good at the ML family of languages. Isn't vibecoding a lot safer with a typed language? Going from Haskell to Python is going from one end of the typing spectrum to the other.