3 ms·

After reading the article (BTW a good one), one thing intrigues me: why the author left Haskell for Lisp(s) ?

by huqedato 3y ago

deleted 3y ago
[deleted]
behnamoh 3y ago
At some point you realize Haskell and/or its ecosystem keeps breaking things too much and you move on.
- ParetoOptimal 3y ago
  I love Haskell and know there are efforts to fix this, but I find it hard to disagree.
  - tome 3y ago
    Not just efforts, but both GHC HQ and the Core Libraries Committee making stability a top priority. Expect casual breaking changes in the Haskell world to become a thing of the past, in very short order (in fact the most recent release of GHC (9.8) had very few breaking changes).
    - ParetoOptimal 3y ago
      I've been out of the loop for a bit, so that's great news to hear!
kccqzy 3y ago
I did the same and I treat Haskell as a rite of passage. At this point it's cliche to say that Haskell makes you a better programmer in other languages, but it's true. You really immerse yourself in Haskell for a few years, and you become a better programmer even when you aren't writing Haskell. I'm referring to universal things like "making invalid states unrepresentable" or "preferring to parse than to validate" or "functional core imperative shell" that can work well and lead to cleaner code in any language. (The actual reason I left Haskell was because I switched my employer. Choosing an employer is IMO a bit more important than choosing the language to code in.)
- ParetoOptimal 3y ago
  Non-mainstream languages can be a very positive signal for employers I've found.
- mst 3y ago
  I've bounced off haskell several times now (I'm probably due another attempt this year, I continue to be convinced the problem is one or more 'aha' moments that I just haven't managed to make click yet). The "functional core, imperative shell" approach is -fantastic- though and I'm not sure where I picked it up from but a lot of my (especially async/event driven) code looks at least close to that. It occurs to me that this may be why I've yet to be significantly bothered by function colouring when writing async/await based code in Perl and/or JS, but I'd probably have to give that more thought before I go beyond 'maybe' with that particular idea.
  - kccqzy 3y ago
    I agree with you. The function coloring "problem" in the Haskell world is basically the distinction between a pure function and an IO function. I put the word "problem" in quotes because it's abundantly clear to any Haskeller that it isn't a problem but rather a beneficial constraint on programming that, sadly, other languages don't enforce in their type systems. The whole point of type systems is to add constraints and prevent you from writing certain hopefully nonsensical programs (if not we might as well go back to untyped lambda calculus which is Turing complete). Haskell just goes further than most languages. When you stick with this kind of constraints, you eventually naturally lead to approaches like "functional core imperative shell" which is an improvement in code quality and clarity. For a junior programmer, the benefit of such constraints is greater because they do need the compiler to tell them no. The benefit is somewhat reduced for senior programmers because experience leads them to naturally avoid things that a Haskell compiler would have yelled at them for.
colingw 3y ago
Hi. I actually left Haskell for Rust. And when I say "left", I mean I don't start new projects in it. I still maintain my libraries. I wrote Haskell for 10 years or so, both FOSS and professionally. I've "been around the block" so to speak and consider myself to have a decent view of the landscape. Overall, Rust lets me code in the style I want while being very resource efficient. I write Rust professionally.
- Hizonner 3y ago
  The part that confused me was your leaving Haskell for Rust and then leaving Rust for Lisp. Were both of those transitions aimed at some common goal? I mean, if I left Haskell, I think the main reason would be to to shed the load of thinking simultaneously about laziness and how it interacts with optimization. OK, almost any non-Haskell language gets you out of that. But choosing to leave Haskell specifically for Rust would be about efficiency first and foremost, especially improving on the size and complexity of the RTS (and its limited platform support). I could also see wanting the concurrent programming benefits of Rust's ownership system. And it's nice to be able to write embedded or kernel code. And there's a bandwagon to jump on. Lisp, on the other hand, doesn't really seem like an improvement over Haskell in any of those ways. It solves different problems. Lisp feels like it's on the "opposite side" of Haskell from Rust. So why did you "reverse" and try Lisp to begin with? I agree that Rust is ugly, by the way. Honestly I think it started with keeping the C syntax and went from there.
  - colingw 3y ago
    I should make it clear that I haven't left Rust; I write it every day professionally. I transitioned from Haskell to Rust to capture efficiency and small binaries. Since I'm in the game of shipping CLI tools, this was important for me. You're right though that Lisp is on the other end of that; we're back to bigger runtimes with no tree-shaking, since that would hinder debugging. For now I'm experimenting with the Interactive Programming paradigm because the debugging story is just too good. For long-lived programs, this may be the way to go. Rust code can be made nice to look at it, but it isn't the default nor the trend.
crote 3y ago
I can't speak for the author, but I do know the reason I personally left it: Haskell-the-language is amazing, Haskell-the-ecosystem is awful. Like the other commenter I completely agree that knowing Haskell makes you a better programmer, and when I code in other languages I really miss certain parts of it. On the other hand, the entire Haskell ecosystem feels like a half-finished PhD thesis, and often-promoted libraries suffer from fundamental flaws which are "open research questions". There's a constant drive in many Haskellers to make their code as abstract, type-safe, and generic as possible, but unfortunately practicality and ease of use are often forgotten along the way. It's a great language, but if you're trying to write production code which builds upon the wider ecosystem you're in for a world of pain. In 2024 Rust has probably rifled enough through Haskell's pockets to make it mostly irrelevant as anything but a testbed for programming language researchers.

After reading the article (BTW a good one), one thing intrigues me: why the author left Haskell for Lisp(s) ?

deleted 3y ago

[deleted]

behnamoh 3y ago

At some point you realize Haskell and/or its ecosystem keeps breaking things too much and you move on.

ParetoOptimal 3y ago
I love Haskell and know there are efforts to fix this, but I find it hard to disagree.
- tome 3y ago
  Not just efforts, but both GHC HQ and the Core Libraries Committee making stability a top priority. Expect casual breaking changes in the Haskell world to become a thing of the past, in very short order (in fact the most recent release of GHC (9.8) had very few breaking changes).
  - ParetoOptimal 3y ago
    I've been out of the loop for a bit, so that's great news to hear!

kccqzy 3y ago

I did the same and I treat Haskell as a rite of passage. At this point it's cliche to say that Haskell makes you a better programmer in other languages, but it's true. You really immerse yourself in Haskell for a few years, and you become a better programmer even when you aren't writing Haskell. I'm referring to universal things like "making invalid states unrepresentable" or "preferring to parse than to validate" or "functional core imperative shell" that can work well and lead to cleaner code in any language. (The actual reason I left Haskell was because I switched my employer. Choosing an employer is IMO a bit more important than choosing the language to code in.)

ParetoOptimal 3y ago
Non-mainstream languages can be a very positive signal for employers I've found.
mst 3y ago
I've bounced off haskell several times now (I'm probably due another attempt this year, I continue to be convinced the problem is one or more 'aha' moments that I just haven't managed to make click yet). The "functional core, imperative shell" approach is -fantastic- though and I'm not sure where I picked it up from but a lot of my (especially async/event driven) code looks at least close to that. It occurs to me that this may be why I've yet to be significantly bothered by function colouring when writing async/await based code in Perl and/or JS, but I'd probably have to give that more thought before I go beyond 'maybe' with that particular idea.
- kccqzy 3y ago
  I agree with you. The function coloring "problem" in the Haskell world is basically the distinction between a pure function and an IO function. I put the word "problem" in quotes because it's abundantly clear to any Haskeller that it isn't a problem but rather a beneficial constraint on programming that, sadly, other languages don't enforce in their type systems. The whole point of type systems is to add constraints and prevent you from writing certain hopefully nonsensical programs (if not we might as well go back to untyped lambda calculus which is Turing complete). Haskell just goes further than most languages. When you stick with this kind of constraints, you eventually naturally lead to approaches like "functional core imperative shell" which is an improvement in code quality and clarity. For a junior programmer, the benefit of such constraints is greater because they do need the compiler to tell them no. The benefit is somewhat reduced for senior programmers because experience leads them to naturally avoid things that a Haskell compiler would have yelled at them for.

colingw 3y ago

Hi. I actually left Haskell for Rust. And when I say "left", I mean I don't start new projects in it. I still maintain my libraries. I wrote Haskell for 10 years or so, both FOSS and professionally. I've "been around the block" so to speak and consider myself to have a decent view of the landscape. Overall, Rust lets me code in the style I want while being very resource efficient. I write Rust professionally.

Hizonner 3y ago
The part that confused me was your leaving Haskell for Rust and then leaving Rust for Lisp. Were both of those transitions aimed at some common goal? I mean, if I left Haskell, I think the main reason would be to to shed the load of thinking simultaneously about laziness and how it interacts with optimization. OK, almost any non-Haskell language gets you out of that. But choosing to leave Haskell specifically for Rust would be about efficiency first and foremost, especially improving on the size and complexity of the RTS (and its limited platform support). I could also see wanting the concurrent programming benefits of Rust's ownership system. And it's nice to be able to write embedded or kernel code. And there's a bandwagon to jump on. Lisp, on the other hand, doesn't really seem like an improvement over Haskell in any of those ways. It solves different problems. Lisp feels like it's on the "opposite side" of Haskell from Rust. So why did you "reverse" and try Lisp to begin with? I agree that Rust is ugly, by the way. Honestly I think it started with keeping the C syntax and went from there.
- colingw 3y ago
  I should make it clear that I haven't left Rust; I write it every day professionally. I transitioned from Haskell to Rust to capture efficiency and small binaries. Since I'm in the game of shipping CLI tools, this was important for me. You're right though that Lisp is on the other end of that; we're back to bigger runtimes with no tree-shaking, since that would hinder debugging. For now I'm experimenting with the Interactive Programming paradigm because the debugging story is just too good. For long-lived programs, this may be the way to go. Rust code can be made nice to look at it, but it isn't the default nor the trend.

crote 3y ago

I can't speak for the author, but I do know the reason I personally left it: Haskell-the-language is amazing, Haskell-the-ecosystem is awful. Like the other commenter I completely agree that knowing Haskell makes you a better programmer, and when I code in other languages I really miss certain parts of it. On the other hand, the entire Haskell ecosystem feels like a half-finished PhD thesis, and often-promoted libraries suffer from fundamental flaws which are "open research questions". There's a constant drive in many Haskellers to make their code as abstract, type-safe, and generic as possible, but unfortunately practicality and ease of use are often forgotten along the way. It's a great language, but if you're trying to write production code which builds upon the wider ecosystem you're in for a world of pain. In 2024 Rust has probably rifled enough through Haskell's pockets to make it mostly irrelevant as anything but a testbed for programming language researchers.