Surprising decision in a time when writing code is cheap and so many projects migrate to Rust.
After 7 years in production, Scarf has reluctantly moved away from Haskell
291–300 of 320 posts
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#292Earlier quoted context omitted.
> The only complaint against Haskell was about long compilation times. There is also this > How do we make library docs full of copy-pastable, realistic examples, not just beautiful types? Which is useful for humans as well as agents. Haskell indeed has a very bad track record of documenting its libraries. For many people, just having the function signatures is documentation enough. Rust is equally bad at compile tim…
> Rust is equally bad at compile times OCaml enters the room...
Is OCaml compilation slow? I was under the impression that it's quite snappy.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#293python? that extremely brittle ecosystem?
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#294Earlier quoted context omitted.
I don't really understand your comment. Are you saying it's "career suicide" to not use AI slop?
Yes. To add more nuance to what I'm saying the trajectory of the industry and society is heading towards this. Your company may not be like this now, but the future is where this is all converging. I can tell you at my current company as of now, if you're not using AI it is essentially career suicide for that specific company. I think these statements are true: 1. An expert using AI is better than an expert without u…
AI makes people produce consistently worse results.
I will not under any circumstances use AI, not least because it cannot possibly solve a problem I have.
At work, I've already had to "fix" some incredibly faulty projects caused by well-intentioned people thinking they can use AI to write code. I started with `rm -rf *` and moved on from there.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#295Earlier quoted context omitted.
Even Emacs Lisp has had a byte code compiler since forever, and since Emacs 28 it compiles to native machine code via libgccjit. Toy lisp interpreters are easy and fun and everywhere, often written in lisp itself, but the same books that teach them go on to teach compilers. SICP chapter 4 is the metacircular evaluator, chapter 5 is the compiler. That ordering is the point: interpretation is the pedagogy, compilation…
Great comment Don, should have been one level up on the thread chain, though. :)
We can move it if you tell us what the parent should be.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#296Earlier quoted context omitted.
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'…
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 too…
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.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#297Earlier quoted context omitted.
exactly, i find the article a wierd take. i would have thougt that being able to catch errors at compile time is the assurance that the LLM generated code is actually decent. so does this mean that the LLM writes code that is so good that the compiler does not find any more errors? or is it due to the nature of haskell that makes it hard to write bad code to begin with? or just that because the haskell compiler catch…
"proving code correct has been a research topic at some point." It has been an area of active research for 40 years. But almost all the research returned the null result, meaning that the program proving didn't improve code quality (basically it didn't work). Yet somehow a group of programmers, usually fresh out of academia falls for program proving each generation. Strong types do really help but you need a good com…
I've been successfully practicing programming with proof of correctness since the 1970s. The confusion I see with most people failing at this is that they're trying to write code first and then prove it correct. The idea promoted by Dijkstra, Hoare, et al is to write the code and the proof together, with each of these aspects of the task supporting the other. The result is (in my experience) a better program developed as quickly (even when not counting on vastly decreased debugging time) as pure coding. Similarly with strong lexical typing: One does not try to create a typing model for a hunk of arbitrary code. Instead, one develops the type model along with the code, with each of those aspects supporting the other. Putting it all together: Coding, Typing (and other Constraining) and Proving are done together, with each of these activities supporting the others. It does take time to learn such a methodology. And it takes extra understanding to maintain types, constraints and proofs as the program evolves, i.e. "maintenance".
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#298Earlier quoted context omitted.
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 too…
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…
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.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#299Earlier quoted context omitted.
Having worked professionally with Common Lisp, I can tell you that’s not even remotely true. Besides, “machine code generation” is not a fundamental part of Lisp. Some of the most famous implementations were pure interpreters.
Such as? Having known Lisp since 1996, and avid digital archaeologist, I wonder which famous implementations are those.
Ok, tell me how you're an "avid digital archaeologist" and you're not aware of what I'm about to tell you.
The original Lisp as designed by John McCarthy was interpreted. That became Lisp 1.5, which ran on several mainframes of the time.
Programs were represented directly as S-expressions and evaluated recursively. This is one of the defining features of Lisp - the metacircular evaluator! Almost any Lisp text which covers the implementation of the language will describe this. It's emblematic of what Lisp is!
Interlisp was interpreted up until its final versions, which added some JIT capabilities.
The PC versions of Lisp, like muLisp and XLisp, were interpreted. muLisp introduced compilation in later versions.
If you count Scheme as a Lisp, there are probably more Scheme interpreters than there are compilers.
The reason that several Lisp implementations added compilation in later versions is because the hardware limitations of the time meant interpreters had a substantial handicap against compilers. But compilation was never a fundamental feature of Lisp.
Re: After 7 years in production, Scarf has reluctantly moved away from Haskell
#300Earlier quoted context omitted.
The issue with formal proofs is that we might end up with correct code that does the wrong thing. I mean, something that the market doesn't care about. At the same time a buggy set of PHP scripts does what people care about and captures the market. Think about 20+ years ago and you find a lot of examples.
https://xkcd.com/224/ lol Zuckerberg became rich on php, which grinds my gears almost as much as the genocide thing. In fairness, my peers at $corp used to ship while I was sad-Wojciech "no you can't create tech debt". The universe is cruel to people who care.
php is a great language. there is a reason why the majority of the web runs on it.