7 ms·

In trying to figure out why Haskell hasn't been widely adopted, I think it's very hard to disentangle legitimate criticisms of the language (unpredictable perfo

In trying to figure out why Haskell hasn't been widely adopted, I think it's very hard to disentangle legitimate criticisms of the language (unpredictable performance, overcomplicated and bizarre APIs, etc.) from the simple fact that learning it with an imperative background is like starting from scratch, even for experienced programmers. This is true even if you look at the base language, without involving Template Haskell or any of the weird language extensions. Ultimately, asking programmers to relearn how to be programmers (or, more relevantly, asking businesses to accept that overhead and/or a vastly reduced hiring pool) is just too large of an ask for whatever marginal gain you might expect from using a "superior" programming language. To be clear, I learned Haskell for fun and got to what I'd consider an intermediate level of expertise. It was an incredibly enriching experience, and gave me a new perspective on programming in general. But it was hard, and the rabbit hole just keeps going---sure, you can juggle monads in your sleep, but are you proficient with the `lens` library? No? Well, I can recommend you a pile of textbooks that might help.

anitil 4y ago
This is where I'm at. I don't know if I'll ever get useful software out of it, but I really enjoy the mental challenge. I actually find it a bit of an ugly language to look at (backticks, hanging single quotes etc) but I like how it reveals the underlying structure of problems that I haven't been able too replicate in other languages. Though I'd recommend a youtube channel called 'Low Level Javascript' (really!) which comes close in developing some of their parser combinator library.
- toastal 4y ago
  Hanging single quotation marks? You mean the ‘prime’ symbol? This comes up a lot in math to generate more variables that need a similar name—that’s why it ends up in Haskell and related languages. It’s not something weird. Granted the ASCII tick/apostrophe is neither the proper symbol for primes nor quotation marks (should be curly), but programmers are reluctant towards Unicode.
y2bd 4y ago
What about Rust? Rust doesn’t go as in-depth as Haskell when it comes to modeling effects in the type system, but it still has a relatively complex type system on top of dealing with the borrow checker (which is almost as joked about as Monads at this point). Even with that difficulty, Rust seems to be a lot more successful than Haskell, and has existed for far less time. If it’s because Rust is still mostly imperative, then you could look to Clojure or even Scala—less complicated when it comes to types, but also (usually) much less imperative. Both I feel are more popular than Haskell.
- caconym_ 4y ago
  I was thinking about Rust a lot when I wrote this comment, actually. IMO, imperative vs. functional aside, Rust does suffer from a lot of the same learning curve issues people commonly pin on Haskell. Rust has plenty of libraries with weird, excessively "clever" APIs, weird experimental language features, a complicated metaprogramming facility, and so on. Personally, I have found lifetimes in Rust more annoying to deal with in semi-nontrivial situations than anything I ever encountered in Haskell, and it doesn't help that things that seem like they should work often don't. (I always figure that's the language telling me that I should use a different memory management strategy, and I generally follow its advice, but I digress.) This is very much my opinion, but I'd attribute Rust's success over Haskell to three main points: * Functional vs. imperative, skill curves. Rust is still vastly more familiar to most programmers at a first impression, and IMO it also has a lower skill floor. * Rust's tooling feels a lot more modern and streamlined. `cargo` is a joy to use. Maybe Haskell's ecosystem has improved, but back when I was actively using it, it was clearly inferior to Rust's. For me, this manifested mainly in significantly greater difficulties managing dependencies and reproducing builds. This stuff is a first-class priority for the Rust team, and it shows. * Somewhat related to the last point, Rust is "cool". It isn't burdened by decades of academic cruft; it just feels approachable, modern, and relevant in a way Haskell doesn't. The last two points aren't really Haskell's fault. I think the Rust team has done an absolutely top-tier job of making the language approachable and usable, obviously building on lessons of the past (including Haskell, Stack, cabal, haddock, etc.) and I'd almost say it's succeeded despite the essential nature of the Rust language itself.
quadrifoliate 4y ago
> ...earning it with an imperative background is like starting from scratch, even for experienced programmers. This is true even if you look at the base language, without involving Template Haskell or any of the weird language extensions. As a somewhat experienced programmer, I would actually say that the language extensions are an important part in disincentivizing learning Haskell for me, because even if I learn the base language, it seems like I would need to understand all these weird extensions to read real-life code, which always seems to involve half a dozen of them.
- mbrodersen 4y ago
  Yep agree. Keeping track of what all the language extensions do is not worth the effort compared with more leading edge languages like Agda and Idris.
  - ParetoOptimal 4y ago
    As of GHC 9.0.2 the GHC2021 language pragma is available and it consists of the most popular language extensions. https://downloads.haskell.org/~ghc/9.2.1/docs/html/users_guide/exts/control.html#extension-GHC2021 https://downloads.haskell.org/~ghc/9.2.1/docs/html/users_gui... Also typically language extensions are pretty simple, single purpose, and well documented.
    - klysm 4y ago
      Is this structured like rust editions? If so I think that could be very useful for the ecosystem.
    - quadrifoliate 4y ago
      > Also typically language extensions are pretty simple, single purpose, and well documented. I will try again to explain with an example how these extensions are borderline user-hostile. One of those extensions in your article linked above is apparently something called `DoAndIfThenElse` which enables if..then..else syntax with if and then on the same line, so far as I can tell [1]. When building programs that assume this extension without declaring that pragma, you get helpful error messages like "Unexpected semi-colons in conditional" [2]. Dealing with oddities like this seems to be routine any time I work on a Haskell project that's not a tutorial, and the constant need to go hunting for these error messages and add random pragma headers saps energy and is discouraging. There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim. Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases. I think whoever is steering the ship in Haskell/GHC land should really focus on ways to freeze new language extensions, and make the current ones well-documented in addition to providing options like the one you linked. Newer languages have environments that are much friendlier towards newcomers in terms of both documentation and (for lack of a better word) runnability of real-world code. ---------------------------------------- [1] I would really like to know why this is considered a popular language extension, and/or why it was needed, but let's skip over that for the moment. [2] https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-language-extension.html https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-lang... [3] https://gitlab.haskell.org/ghc/ghc/-/issues/18631 https://gitlab.haskell.org/ghc/ghc/-/issues/18631
antupis 4y ago
Haskell is hard language I have like tried to learn it several times and no luck. I did not have same problem with Clojure and Rust where I was productive like first day.
- ge96 4y ago
  Curious what method you used? I recently bought a book, I'm only learning it to port a Haskell project to C++, if I can even do that.
  - antupis 4y ago
    I have read http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters and then start implementing something useful based on examples. This process read book x and then implement something has worked with all other languages. I think big part is that Haskell has all kinda custom operators which are basically ungooglable.
    - bitmapper 4y ago
      https://hoogle.haskell.org/ https://hoogle.haskell.org/ can be helpful for this
- Iceland_jack 4y ago
  Most people require several attempts before they get over the hump
ParetoOptimal 4y ago
> asking businesses to accept that overhead and/or a vastly reduced hiring pool) is just too large of an ask for whatever marginal gain you might expect from using a "superior" programming language. I feel the burden of proof for the claim "superior languages make only marginal differences" is one that is very high and one you have not met.
- caconym_ 4y ago
  That's probably why I put 'superior' in "air quotes". The null hypothesis would be that all reasonably well supported modern general-purpose programming languages are about as productive as each other on average. I have my own anecdotal opinion(s)^[1], but the onus is really on anybody claiming language X is superior (no air quotes there) to prove it to the rest of us. In this case, by using air quotes, I meant to draw attention to the fact that the aforementioned proposition regarding Haskell's superiority is (AFAIK) unproven, as well as to illustrate the skeptical attitude a practical business leader might have toward embracing it, for what I consider to be totally fair reasons. Also note that I'm not necessarily using 'marginal' in a pejorative sense. A marginal improvement can be significant. ^[1] Anecdotally I think Haskell is transcendently good for certain kinds of problems, and a huge pain in the ass for others.
  - ParetoOptimal 4y ago
    > In this case, by using air quotes, I meant to draw attention to the fact that the aforementioned proposition regarding Haskell's superiority is (AFAIK) unproven, I noticed that and considered (and should have said) this to prevent any miscommunication: I feel the burden of proof for the claim "language choice makes only marginal differences" is one that is very high and one you have not met. Then if we want to disprove the null hypothesis there we give one programmer brainfuck and the other Python ;)
    - caconym_ 4y ago
      > Then if we want to disprove the null hypothesis there we give one programmer brainfuck and the other Python Hence "reasonably well supported modern general-purpose programming languages". I think this null hypothesis is where most sufficiently jaded working programmers end up, and business leaders without a programming background will start there because it's all Greek to them. I'm not here to prove its correctness, just to raise it as a very real factor working against Haskell's adoption. Nothing would delight me more than for somebody to come along and unequivocally prove that Haskell is a silver bullet. But the point here, really, is that nobody has yet.
jose_zap 4y ago
Most of the popular languages in use today have big corporations backing them. I would say that this is a major reason why Haskell and other niche programming languages are not more widely adopted.
vintermann 4y ago
Back when I learned it, it may have been true that Haskell's adoption was hurt by functional programming being an exotic thing. But that isn't really the case today, is it? Almost all the cool power features of Haskell have been adopted by the rest of the world. Type inference, pattern matching, explicit nulls, algebraic data structures, rich type systems... although it isn't usually enforced, the world has woken up to the fact that "mutable state is dangerous and should be avoided whenever possible". Writing a program without any reassignment isn't nearly as alien to a programmer starting out today as it was 20 years ago. Back then, even passing a function as an argument was edgy (and, in C/C++, risky). I think what's hampered Haskell, and made at least me reluctant to pick it up again, is that for all the ridiculous talent working on Haskell, there hasn't come some brilliant fix to the space leaks thing. Almost as if there's something fundamentally hard about composability and laziness. I'm really not sold on laziness by default anymore, it costs so much more than it tastes - and for everything else, Haskell is a victim of its own success in that so many of the things it pioneered has gone mainstream.
- jose_zap 4y ago
  You can do enable strict evaluation by default in Haskell, though. So, that must not be the reason why the language is not mainstream. More likely, network effects can explain how something makes it to the mainstream. For example having a big corporation behind the development and marketing of the language.
- caconym_ 4y ago
  I wrote a bit about this here: https://news.ycombinator.com/item?id=31663316 https://news.ycombinator.com/item?id=31663316 In brief, I think Haskell is still the purest expression of what makes it great. This is both a good thing, for the reasons I outlined there, and a bad thing, because e.g. stringing together a few iterator methods in Rust may be a functional style but it still prepares you for the concepts you'll encounter in Haskell about as well as zooming a Hot Wheels around on the kitchen floor prepares you to drive a lap in an F1 car without stalling out or flying off the track. People with a modern imperative background know this intuitively---or maybe they just assume it, and happen to be correct---as soon as they look at a page of nontrivial Haskell code. One thing people seem to miss about laziness in Haskell is that it's (unfortunately?) really tightly coupled with how "control structures" are expressed. For instance, instead of writing a loop with some infinite or indefinite condition, you might declare a list using a generator function and iterate over its values. I would like to see how other similar languages (e.g. Purescript) have done away with it, and how it impacts them. But my recollection from when I actually knew Haskell is that it was an incredibly powerful feature tightly integrated with the language design, not only from a data perspective but also from a perspective of allowing code structures to map much more closely onto the data structures they're manipulating. (This is a big part of why, as I think I mentioned somewhere else in this thread, Haskell is so ergonomically suited for working with tree-like linked data structures.)

anitil 4y ago

This is where I'm at. I don't know if I'll ever get useful software out of it, but I really enjoy the mental challenge. I actually find it a bit of an ugly language to look at (backticks, hanging single quotes etc) but I like how it reveals the underlying structure of problems that I haven't been able too replicate in other languages. Though I'd recommend a youtube channel called 'Low Level Javascript' (really!) which comes close in developing some of their parser combinator library.

toastal 4y ago
Hanging single quotation marks? You mean the ‘prime’ symbol? This comes up a lot in math to generate more variables that need a similar name—that’s why it ends up in Haskell and related languages. It’s not something weird. Granted the ASCII tick/apostrophe is neither the proper symbol for primes nor quotation marks (should be curly), but programmers are reluctant towards Unicode.

y2bd 4y ago

What about Rust? Rust doesn’t go as in-depth as Haskell when it comes to modeling effects in the type system, but it still has a relatively complex type system on top of dealing with the borrow checker (which is almost as joked about as Monads at this point). Even with that difficulty, Rust seems to be a lot more successful than Haskell, and has existed for far less time. If it’s because Rust is still mostly imperative, then you could look to Clojure or even Scala—less complicated when it comes to types, but also (usually) much less imperative. Both I feel are more popular than Haskell.

caconym_ 4y ago
I was thinking about Rust a lot when I wrote this comment, actually. IMO, imperative vs. functional aside, Rust does suffer from a lot of the same learning curve issues people commonly pin on Haskell. Rust has plenty of libraries with weird, excessively "clever" APIs, weird experimental language features, a complicated metaprogramming facility, and so on. Personally, I have found lifetimes in Rust more annoying to deal with in semi-nontrivial situations than anything I ever encountered in Haskell, and it doesn't help that things that seem like they should work often don't. (I always figure that's the language telling me that I should use a different memory management strategy, and I generally follow its advice, but I digress.) This is very much my opinion, but I'd attribute Rust's success over Haskell to three main points: * Functional vs. imperative, skill curves. Rust is still vastly more familiar to most programmers at a first impression, and IMO it also has a lower skill floor. * Rust's tooling feels a lot more modern and streamlined. `cargo` is a joy to use. Maybe Haskell's ecosystem has improved, but back when I was actively using it, it was clearly inferior to Rust's. For me, this manifested mainly in significantly greater difficulties managing dependencies and reproducing builds. This stuff is a first-class priority for the Rust team, and it shows. * Somewhat related to the last point, Rust is "cool". It isn't burdened by decades of academic cruft; it just feels approachable, modern, and relevant in a way Haskell doesn't. The last two points aren't really Haskell's fault. I think the Rust team has done an absolutely top-tier job of making the language approachable and usable, obviously building on lessons of the past (including Haskell, Stack, cabal, haddock, etc.) and I'd almost say it's succeeded despite the essential nature of the Rust language itself.

quadrifoliate 4y ago

> ...earning it with an imperative background is like starting from scratch, even for experienced programmers. This is true even if you look at the base language, without involving Template Haskell or any of the weird language extensions. As a somewhat experienced programmer, I would actually say that the language extensions are an important part in disincentivizing learning Haskell for me, because even if I learn the base language, it seems like I would need to understand all these weird extensions to read real-life code, which always seems to involve half a dozen of them.

mbrodersen 4y ago
Yep agree. Keeping track of what all the language extensions do is not worth the effort compared with more leading edge languages like Agda and Idris.
- ParetoOptimal 4y ago
  As of GHC 9.0.2 the GHC2021 language pragma is available and it consists of the most popular language extensions. https://downloads.haskell.org/~ghc/9.2.1/docs/html/users_guide/exts/control.html#extension-GHC2021 https://downloads.haskell.org/~ghc/9.2.1/docs/html/users_gui... Also typically language extensions are pretty simple, single purpose, and well documented.
  - klysm 4y ago
    Is this structured like rust editions? If so I think that could be very useful for the ecosystem.
  - quadrifoliate 4y ago
    > Also typically language extensions are pretty simple, single purpose, and well documented. I will try again to explain with an example how these extensions are borderline user-hostile. One of those extensions in your article linked above is apparently something called `DoAndIfThenElse` which enables if..then..else syntax with if and then on the same line, so far as I can tell [1]. When building programs that assume this extension without declaring that pragma, you get helpful error messages like "Unexpected semi-colons in conditional" [2]. Dealing with oddities like this seems to be routine any time I work on a Haskell project that's not a tutorial, and the constant need to go hunting for these error messages and add random pragma headers saps energy and is discouraging. There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim. Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases. I think whoever is steering the ship in Haskell/GHC land should really focus on ways to freeze new language extensions, and make the current ones well-documented in addition to providing options like the one you linked. Newer languages have environments that are much friendlier towards newcomers in terms of both documentation and (for lack of a better word) runnability of real-world code. ---------------------------------------- [1] I would really like to know why this is considered a popular language extension, and/or why it was needed, but let's skip over that for the moment. [2] https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-language-extension.html https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-lang... [3] https://gitlab.haskell.org/ghc/ghc/-/issues/18631 https://gitlab.haskell.org/ghc/ghc/-/issues/18631

antupis 4y ago

Haskell is hard language I have like tried to learn it several times and no luck. I did not have same problem with Clojure and Rust where I was productive like first day.

ge96 4y ago
Curious what method you used? I recently bought a book, I'm only learning it to port a Haskell project to C++, if I can even do that.
- antupis 4y ago
  I have read http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters and then start implementing something useful based on examples. This process read book x and then implement something has worked with all other languages. I think big part is that Haskell has all kinda custom operators which are basically ungooglable.
  - bitmapper 4y ago
    https://hoogle.haskell.org/ https://hoogle.haskell.org/ can be helpful for this
Iceland_jack 4y ago
Most people require several attempts before they get over the hump

ParetoOptimal 4y ago

> asking businesses to accept that overhead and/or a vastly reduced hiring pool) is just too large of an ask for whatever marginal gain you might expect from using a "superior" programming language. I feel the burden of proof for the claim "superior languages make only marginal differences" is one that is very high and one you have not met.

caconym_ 4y ago
That's probably why I put 'superior' in "air quotes". The null hypothesis would be that all reasonably well supported modern general-purpose programming languages are about as productive as each other on average. I have my own anecdotal opinion(s)^[1], but the onus is really on anybody claiming language X is superior (no air quotes there) to prove it to the rest of us. In this case, by using air quotes, I meant to draw attention to the fact that the aforementioned proposition regarding Haskell's superiority is (AFAIK) unproven, as well as to illustrate the skeptical attitude a practical business leader might have toward embracing it, for what I consider to be totally fair reasons. Also note that I'm not necessarily using 'marginal' in a pejorative sense. A marginal improvement can be significant. ^[1] Anecdotally I think Haskell is transcendently good for certain kinds of problems, and a huge pain in the ass for others.
- ParetoOptimal 4y ago
  > In this case, by using air quotes, I meant to draw attention to the fact that the aforementioned proposition regarding Haskell's superiority is (AFAIK) unproven, I noticed that and considered (and should have said) this to prevent any miscommunication: I feel the burden of proof for the claim "language choice makes only marginal differences" is one that is very high and one you have not met. Then if we want to disprove the null hypothesis there we give one programmer brainfuck and the other Python ;)
  - caconym_ 4y ago
    > Then if we want to disprove the null hypothesis there we give one programmer brainfuck and the other Python Hence "reasonably well supported modern general-purpose programming languages". I think this null hypothesis is where most sufficiently jaded working programmers end up, and business leaders without a programming background will start there because it's all Greek to them. I'm not here to prove its correctness, just to raise it as a very real factor working against Haskell's adoption. Nothing would delight me more than for somebody to come along and unequivocally prove that Haskell is a silver bullet. But the point here, really, is that nobody has yet.

jose_zap 4y ago

Most of the popular languages in use today have big corporations backing them. I would say that this is a major reason why Haskell and other niche programming languages are not more widely adopted.

vintermann 4y ago

Back when I learned it, it may have been true that Haskell's adoption was hurt by functional programming being an exotic thing. But that isn't really the case today, is it? Almost all the cool power features of Haskell have been adopted by the rest of the world. Type inference, pattern matching, explicit nulls, algebraic data structures, rich type systems... although it isn't usually enforced, the world has woken up to the fact that "mutable state is dangerous and should be avoided whenever possible". Writing a program without any reassignment isn't nearly as alien to a programmer starting out today as it was 20 years ago. Back then, even passing a function as an argument was edgy (and, in C/C++, risky). I think what's hampered Haskell, and made at least me reluctant to pick it up again, is that for all the ridiculous talent working on Haskell, there hasn't come some brilliant fix to the space leaks thing. Almost as if there's something fundamentally hard about composability and laziness. I'm really not sold on laziness by default anymore, it costs so much more than it tastes - and for everything else, Haskell is a victim of its own success in that so many of the things it pioneered has gone mainstream.

jose_zap 4y ago
You can do enable strict evaluation by default in Haskell, though. So, that must not be the reason why the language is not mainstream. More likely, network effects can explain how something makes it to the mainstream. For example having a big corporation behind the development and marketing of the language.
caconym_ 4y ago
I wrote a bit about this here: https://news.ycombinator.com/item?id=31663316 https://news.ycombinator.com/item?id=31663316 In brief, I think Haskell is still the purest expression of what makes it great. This is both a good thing, for the reasons I outlined there, and a bad thing, because e.g. stringing together a few iterator methods in Rust may be a functional style but it still prepares you for the concepts you'll encounter in Haskell about as well as zooming a Hot Wheels around on the kitchen floor prepares you to drive a lap in an F1 car without stalling out or flying off the track. People with a modern imperative background know this intuitively---or maybe they just assume it, and happen to be correct---as soon as they look at a page of nontrivial Haskell code. One thing people seem to miss about laziness in Haskell is that it's (unfortunately?) really tightly coupled with how "control structures" are expressed. For instance, instead of writing a loop with some infinite or indefinite condition, you might declare a list using a generator function and iterate over its values. I would like to see how other similar languages (e.g. Purescript) have done away with it, and how it impacts them. But my recollection from when I actually knew Haskell is that it was an incredibly powerful feature tightly integrated with the language design, not only from a data perspective but also from a perspective of allowing code structures to map much more closely onto the data structures they're manipulating. (This is a big part of why, as I think I mentioned somewhere else in this thread, Haskell is so ergonomically suited for working with tree-like linked data structures.)