5 ms·

We dance around this issue in the comments to every Haskell story, but the reason Haskell is hard to market is that it's bad. It's a research language being sho

We dance around this issue in the comments to every Haskell story, but the reason Haskell is hard to market is that it's bad. It's a research language being shoehorned into production by a few people who really love it. Some details of this have been given in this thread; let me suggest the following threads for more: 1) https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocamlers_critiques_of_haskell/cugohyn/ https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocam... 2) https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_ocaml/fa4bnsw/ https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_oc... Yes, the Haskell community hates that guy and considers him a troll. But he does functional programming professionally as part of a private consultancy and wrote a book on OCaml. If anyone's equipped to understand what's wrong with Haskell, it's him. Haskell has had 30 years to get its act together. Any benefits it has are drowned out by a sea of buggy tooling and accidental complexity (monads, etc.). Ask yourself this: if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? Time to move on.

todd8 6y ago
> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? Well, one reason we might get stuck on a “suboptimal” language is network effects outside of the criteria we use to compare languages: what language does an organization already have experience with, does the (only) current compiler support the target hardware and system, it’s to late now to write the Linux kernel in Haskell, etc. However, I agree with you. Despite the time I’ve invested in learning Haskell, I’ve personally decided to spend my time developing in other languages. If Haskell is the magic wand right there in front of us that will give us programs without flaws, how come almost nobody has picked it up and shown us working programs that took less development effort and fewer flaws. We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell), but hledger isn’t the same program as ledger it has different features, I have no idea how long it took to write, how many flaws it has versus the original, how different the developer skills were, how much time and defects were saved by it being a redesign, etc. And these are small single developer efforts (now with numerous contributors). From everything I can gather, they are both excellent. So in this case there is no compelling advantage demonstrated for Haskell, and this supports your point.
- pwm 6y ago
  > We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell) I'm confused. Do you know he is a prolific Haskeller and maintains many libs?
  - tome 6y ago
    I don't understand how that's relevant to the point.
  - todd8 6y ago
    I'm confused. Do you know that he wrote ledger in C++?
    - pwm 6y ago
      Sorry, I thought you were making a point I did not get citing him in comparison with a haskell project. Apologies, I misunderstood.
      - todd8 6y ago
        No worries, I probably wasn't very clear. I wish that someone like John Wiegley would give us his thoughts on Haskell/Lisp/C++. I have a lot of respect for him; he's made big contributions to Emacs and wrote a Common Lisp version of ledger in addition to his C++ version.
somewhereoutth 6y ago
Following links in your 1), I liked https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf 'The Genuine Sieve of Eratosthenes' by Melissa E. O’Neill. Somewhat damning and to your point. Are there any theoretical barriers to writing algorithms in a pure and lazy language with the same space/time complexity as a side-effectful and strict language? I suppose quicksort (also mentioned) is an obvious candidate for study in this regard.
- spekcular 6y ago
  There's also hash tables. IIRC, Haskell didn't have a good hash table implementation until relatively recently because people religiously avoided mutable data structures. (And the implementation I'm thinking of is not purely functional.)
  - centimeter 6y ago
    Haskell has had good HAMTs for quite some time. There isn’t really any benefit to using a mutable hash table over that. In fact, it would probably be slower given the way copying GC works with mutable values.
    - spekcular 6y ago
      Yes, there is a benefit: correctly implemented hash tables are faster. Haskell's GC may prevent a good implementation, but that's a problem with Haskell, not with hash tables.
      - yakshaving_jgt 6y ago
        Writing the fastest possible implementation of something is rarely a valid business goal. The ideal is the midpoint on a Venn diagram of 1) fast enough for our purposes, 2) logically robust, 3) cheap to implement. Besides, if something absolutely must be the fastest implementation possible and this can’t be done in Haskell, then there’s no reason why one couldn’t drop to the FFI at that point. You could even use template Haskell and write inline-C. It works.
centimeter 6y ago
> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? The young economist looks down and sees a $20 bill on the street and says, “Hey, look a twenty-dollar bill!” Without even looking, his older and wiser colleague replies, “Nonsense. If there had been a twenty-dollar lying on the street, someone would have already picked it up by now.” Industry makes collective bad engineering decisions all the time, usually driven by secondary factors like institutional momentum or hiring constraints. Did you read the article? It talked about a bunch of things like that. If you equate market cap with quality, then Java is probably the best language of all time. > wrote a book on OCaml I find it hard to believe that anyone who’s really used both prefers OCaml over Haskell. OCaml is nice compared to most crap, but as someone who’s spent years working with both, Haskell wins almost every time. It’s interesting, actually - I don’t know anyone who’s used Haskell and doesn’t like it. Almost everyone who vocally complains about it hasn’t really used it. Reading that guy’s reddit posts, I have to conclude he’s some kind of troll - most of the things he criticizes Haskell for are way worse in OCaml, or just completely disconnected from reality.
- throwaway518365 6y ago
  > I find it hard to believe that anyone who’s really used both prefers OCaml over Haskell. I've actually used Haskell, Ocaml and Purescript for several years and a lot of locs, and I actually like Ocaml better. Reasons: - The module system -- a very intuitive way to structure code - Poly variants - Strictness -- predictable performance and easy debugging - Allowing side effects - Private types -- better than newtypes imo since you can upcast to it's structural counterpart - Really good type inference -- you never have to write type signatures. Haskell and Purescript type inference is ok-ish and sometimes craps out, which is part of why type signatures for each function is recommended. - Stupidly fast compiler -- yes it matters, try contributing to the Idris codebase. It's like trying to contribute to the linux kernel, you'll wait 30+ minutes for it to compile. - Very fast programs - An actual package manager (stack uninstall?) It is an overall better experience for me. And the language features that are coming down the pipeline are looking great: - Modular implicits - a more sound ad hoc polymorphism system than typeclasses. Typeclasses can't handle simple things like if half of the Haskell ecosystem uses one Filterable typeclass and the other half uses a different Filterable. - Algebraic effects - a strongly typed system for writing effects that will be part of multicore -- delimited continuations / conditions and restarts These days I'm more interested in Erlang/Elixir though. I just don't think static typing is all that after having spent so much time with Haskell/Purescript/Idris/Ocaml. There are really nice benefits you get with dynamic typing that you don't with static, and there are better ways to deal with those problems that won't be noticeably worse in most business applications with just a little bit of coding discipline, such as good testing habits and having good fault tolerance built into the language. I do like Haskell though, it's definitely really fun to program in. It's just not something I'd use for anything. If I really needed something with strong static typing I'd either go with Ocaml or Idris.
deleted 6y ago
[deleted]
nilkn 6y ago
I read those two links. If I ignore some of the points that were valid 10 years ago but not anymore (e.g., there's now stack), and if I ignore some of the personal anecdotes, I come away feeling like much of what is said is not necessarily wrong but is nevertheless an exceptionally negative take. I think you can make almost any tool sound broken and unusable if you use nasty enough and strong enough language about a few examples. Also, there really is very little substance behind the actual language criticism. It's hard to make a blanket statement that typeclasses are "overkill"; they seem to be showing up all over the place in new languages. Similarly, type annotations are incredibly useful and are also showing up all over the place these days outside of Haskell-land. The point on non-strict evaluation is by far the strongest and most legitimate.
ashtonkem 6y ago
> Haskell is best at solving problems that Haskell invented and other languages do not have. That is the most succinct explanation I've ever seen of Haskell.
sjakobi 6y ago
jdh30, the author of both comments, is a massive OCaml fanboy and Haskell hater. I've seen him try to take Haskell performance numbers and interpret them using the wrong units to make them look worse. I'd take anything that he says about Haskell with a big, big grain of salt!
- mjburgess 6y ago
  The comments I've just read of his, are at least, all heavily referenced. After spending nearly a decade thinking about haskell, everything here rings very true. It's a language whose sales pitch begins by assuming you are using the language: here are all these solutions to problems you now have. Laziness is the wrong default; it's a catastrophe for writing programs. It requires the whole category-theoretic infrastructure of haskell to solve, and then, imparts insurmountable complexity on writing anything real world.
  - deleted 6y ago
    [deleted]

todd8 6y ago

> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? Well, one reason we might get stuck on a “suboptimal” language is network effects outside of the criteria we use to compare languages: what language does an organization already have experience with, does the (only) current compiler support the target hardware and system, it’s to late now to write the Linux kernel in Haskell, etc. However, I agree with you. Despite the time I’ve invested in learning Haskell, I’ve personally decided to spend my time developing in other languages. If Haskell is the magic wand right there in front of us that will give us programs without flaws, how come almost nobody has picked it up and shown us working programs that took less development effort and fewer flaws. We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell), but hledger isn’t the same program as ledger it has different features, I have no idea how long it took to write, how many flaws it has versus the original, how different the developer skills were, how much time and defects were saved by it being a redesign, etc. And these are small single developer efforts (now with numerous contributors). From everything I can gather, they are both excellent. So in this case there is no compelling advantage demonstrated for Haskell, and this supports your point.

pwm 6y ago
> We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell) I'm confused. Do you know he is a prolific Haskeller and maintains many libs?
- tome 6y ago
  I don't understand how that's relevant to the point.
- todd8 6y ago
  I'm confused. Do you know that he wrote ledger in C++?
  - pwm 6y ago
    Sorry, I thought you were making a point I did not get citing him in comparison with a haskell project. Apologies, I misunderstood.
    - todd8 6y ago
      No worries, I probably wasn't very clear. I wish that someone like John Wiegley would give us his thoughts on Haskell/Lisp/C++. I have a lot of respect for him; he's made big contributions to Emacs and wrote a Common Lisp version of ledger in addition to his C++ version.

somewhereoutth 6y ago

Following links in your 1), I liked https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf 'The Genuine Sieve of Eratosthenes' by Melissa E. O’Neill. Somewhat damning and to your point. Are there any theoretical barriers to writing algorithms in a pure and lazy language with the same space/time complexity as a side-effectful and strict language? I suppose quicksort (also mentioned) is an obvious candidate for study in this regard.

spekcular 6y ago
There's also hash tables. IIRC, Haskell didn't have a good hash table implementation until relatively recently because people religiously avoided mutable data structures. (And the implementation I'm thinking of is not purely functional.)
- centimeter 6y ago
  Haskell has had good HAMTs for quite some time. There isn’t really any benefit to using a mutable hash table over that. In fact, it would probably be slower given the way copying GC works with mutable values.
  - spekcular 6y ago
    Yes, there is a benefit: correctly implemented hash tables are faster. Haskell's GC may prevent a good implementation, but that's a problem with Haskell, not with hash tables.
    - yakshaving_jgt 6y ago
      Writing the fastest possible implementation of something is rarely a valid business goal. The ideal is the midpoint on a Venn diagram of 1) fast enough for our purposes, 2) logically robust, 3) cheap to implement. Besides, if something absolutely must be the fastest implementation possible and this can’t be done in Haskell, then there’s no reason why one couldn’t drop to the FFI at that point. You could even use template Haskell and write inline-C. It works.

centimeter 6y ago

> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? The young economist looks down and sees a $20 bill on the street and says, “Hey, look a twenty-dollar bill!” Without even looking, his older and wiser colleague replies, “Nonsense. If there had been a twenty-dollar lying on the street, someone would have already picked it up by now.” Industry makes collective bad engineering decisions all the time, usually driven by secondary factors like institutional momentum or hiring constraints. Did you read the article? It talked about a bunch of things like that. If you equate market cap with quality, then Java is probably the best language of all time. > wrote a book on OCaml I find it hard to believe that anyone who’s really used both prefers OCaml over Haskell. OCaml is nice compared to most crap, but as someone who’s spent years working with both, Haskell wins almost every time. It’s interesting, actually - I don’t know anyone who’s used Haskell and doesn’t like it. Almost everyone who vocally complains about it hasn’t really used it. Reading that guy’s reddit posts, I have to conclude he’s some kind of troll - most of the things he criticizes Haskell for are way worse in OCaml, or just completely disconnected from reality.

throwaway518365 6y ago
> I find it hard to believe that anyone who’s really used both prefers OCaml over Haskell. I've actually used Haskell, Ocaml and Purescript for several years and a lot of locs, and I actually like Ocaml better. Reasons: - The module system -- a very intuitive way to structure code - Poly variants - Strictness -- predictable performance and easy debugging - Allowing side effects - Private types -- better than newtypes imo since you can upcast to it's structural counterpart - Really good type inference -- you never have to write type signatures. Haskell and Purescript type inference is ok-ish and sometimes craps out, which is part of why type signatures for each function is recommended. - Stupidly fast compiler -- yes it matters, try contributing to the Idris codebase. It's like trying to contribute to the linux kernel, you'll wait 30+ minutes for it to compile. - Very fast programs - An actual package manager (stack uninstall?) It is an overall better experience for me. And the language features that are coming down the pipeline are looking great: - Modular implicits - a more sound ad hoc polymorphism system than typeclasses. Typeclasses can't handle simple things like if half of the Haskell ecosystem uses one Filterable typeclass and the other half uses a different Filterable. - Algebraic effects - a strongly typed system for writing effects that will be part of multicore -- delimited continuations / conditions and restarts These days I'm more interested in Erlang/Elixir though. I just don't think static typing is all that after having spent so much time with Haskell/Purescript/Idris/Ocaml. There are really nice benefits you get with dynamic typing that you don't with static, and there are better ways to deal with those problems that won't be noticeably worse in most business applications with just a little bit of coding discipline, such as good testing habits and having good fault tolerance built into the language. I do like Haskell though, it's definitely really fun to program in. It's just not something I'd use for anything. If I really needed something with strong static typing I'd either go with Ocaml or Idris.

deleted 6y ago

[deleted]

nilkn 6y ago

I read those two links. If I ignore some of the points that were valid 10 years ago but not anymore (e.g., there's now stack), and if I ignore some of the personal anecdotes, I come away feeling like much of what is said is not necessarily wrong but is nevertheless an exceptionally negative take. I think you can make almost any tool sound broken and unusable if you use nasty enough and strong enough language about a few examples. Also, there really is very little substance behind the actual language criticism. It's hard to make a blanket statement that typeclasses are "overkill"; they seem to be showing up all over the place in new languages. Similarly, type annotations are incredibly useful and are also showing up all over the place these days outside of Haskell-land. The point on non-strict evaluation is by far the strongest and most legitimate.

ashtonkem 6y ago

> Haskell is best at solving problems that Haskell invented and other languages do not have. That is the most succinct explanation I've ever seen of Haskell.

sjakobi 6y ago

jdh30, the author of both comments, is a massive OCaml fanboy and Haskell hater. I've seen him try to take Haskell performance numbers and interpret them using the wrong units to make them look worse. I'd take anything that he says about Haskell with a big, big grain of salt!

mjburgess 6y ago
The comments I've just read of his, are at least, all heavily referenced. After spending nearly a decade thinking about haskell, everything here rings very true. It's a language whose sales pitch begins by assuming you are using the language: here are all these solutions to problems you now have. Laziness is the wrong default; it's a catastrophe for writing programs. It requires the whole category-theoretic infrastructure of haskell to solve, and then, imparts insurmountable complexity on writing anything real world.
- deleted 6y ago
  [deleted]