3 ms·

There's nothing intrinsically wrong with Haskell, but it does indeed attract lots of fundamentalists. That said, these overwhelmingly tend to be lower skilled o

There's nothing intrinsically wrong with Haskell, but it does indeed attract lots of fundamentalists. That said, these overwhelmingly tend to be lower skilled or beginning. You learn some concepts like immutable state, referential transparency and static typing, at which point you become rabidly evangelical about functional programming... at the expense of all other paradigms. People complain about imperative blub programmers, but then they proceed to forget that concatenative, logic, array and message passing OO also exist. It's purely a functional-imperative dichotomy to some people. And so you begin to shoehorn absolutely everything into the new magic potion you've learned. Erlang? How can I build concurrent and robust systems with it, it's dynamically typed and the syntax is scary! (Yes, people who somehow managed to learn Haskell syntax proceed to cry like babies over having to figure out some clause delimiters. The irony is enough to power the US steel industry for a year.) Mutable state and its evil becomes the next cargo cult, type systems means I no longer have to test my software, and other similar misconceptions abound. But, I don't mind. Most tend to grow out of it eventually. You feel hardcore at first, but you're struck by humility once you learn more and more. By the way, Cards Against Humanity is quite nice.

pron 12y ago
> but then they proceed to forget that concatenative, logic, array and message passing OO also exist. Right. I think, in general, PFP (pure-FP, i.e. Haskell and a few more obscure languages) sells itself as a solution to a problem and some people start believing it's the only solution to the problem, rather than one of many (and probably not the best one, at that). Not that Haskell's virtues aren't real -- they are -- but they come at significant cost, and are often available come much cheaper with other approaches. For example, referential-transparency-everywhere is just one of several solutions to the problem of mutable shared state, and, IMO at least, not among the best solutions. Even when it comes to provable correctness, which Haskell touts as a relatively unique feature (at least relative to mainstream languages) people forget -- or more likely, don't know -- that there are fully verifiable imperative languages out there (with their own serious problems -- correctness is never free), that have actually been used by the industry to write some very important, safety-critical software, and have been actually put to the test much more than Haskell. In fact, one of Haskell's marketing advantages is that, after 20 years, it is still at the stage of selling the dream. Because it has hardly been used where its strengths are supposed to matter most (complex programs employing a lot of concurrency), it gets to sell its "promising initial results" without having to contend with too much disappointment, which invariably arrives once a technology has been well tested. It's the promising NBA rookie who got picked first in the draft but has never played a full quarter, getting people to say, "if only they'd get him off the bench...".
- jcadam 12y ago
  > that there are fully verifiable imperative languages out there (with their own serious problem -- correctness is never free), that have actually been used by the industry to write some very important, safety-critical software, and have been actually put to the test much more than Haskell. Ada is absolutely painful to work with as a developer (I used to work in Aerospace). But if you could get your code to compile, it stood a very good chance of just working.
- dragonwriter 12y ago
  I would just like to point out that, for the number of time you have say, in different phrasing, that Haskell is not the best solution to the problems it aims to solve, you provide not one bit of argument or evidence to support that for any of the areas you say it about. Anyway, lots of the reported production uses of Haskell are in exactly the areas it is supposed to be strong; the problem for sharing that experience is many of them are in internal proprietary systems, not publicly-available or open-source software, so external evaluators don't have the code -- or even, often, a chance to interact with the software.
  - pron 12y ago
    > you provide not one bit of argument or evidence to support that for any of the areas you say it about. Well, this isn't a very technical discussion, but I can quickly list them: for shared mutation I think the Clojure approach of transactional/atomic mutation everywhere rather than RT-everywhere is simpler; for correctness/side-effects, imperative effect systems may be easier (well, they don't quite exist other than in a very limited, experimental form, in Koka and Java 8's pluggable type systems -- but Haskell doesn't provide a very fine-grained side-effect-control either). For correctness, Esterel (which has been well proven) and its descendants, seems a lot more sophisticated in terms of proving correctness, while being more intuitive (of course, Esterel introduces a limited computation model, but so does Haskell -- or languages in the same vain -- if they are to be decidable). > the problem for sharing that experience is many of them are in internal proprietary systems Yes, that, too, is a problem, but the bigger problem is that uses in the industry are vanishingly rare -- and the bigger the domain challenge, the rarer still they are. For example, I don't think there exists a single case of a Haskell program that tackles complexity in such a way that implementing it in, say, Java or Clojure, is prohibitively expensive.

pron 12y ago

> but then they proceed to forget that concatenative, logic, array and message passing OO also exist. Right. I think, in general, PFP (pure-FP, i.e. Haskell and a few more obscure languages) sells itself as a solution to a problem and some people start believing it's the only solution to the problem, rather than one of many (and probably not the best one, at that). Not that Haskell's virtues aren't real -- they are -- but they come at significant cost, and are often available come much cheaper with other approaches. For example, referential-transparency-everywhere is just one of several solutions to the problem of mutable shared state, and, IMO at least, not among the best solutions. Even when it comes to provable correctness, which Haskell touts as a relatively unique feature (at least relative to mainstream languages) people forget -- or more likely, don't know -- that there are fully verifiable imperative languages out there (with their own serious problems -- correctness is never free), that have actually been used by the industry to write some very important, safety-critical software, and have been actually put to the test much more than Haskell. In fact, one of Haskell's marketing advantages is that, after 20 years, it is still at the stage of selling the dream. Because it has hardly been used where its strengths are supposed to matter most (complex programs employing a lot of concurrency), it gets to sell its "promising initial results" without having to contend with too much disappointment, which invariably arrives once a technology has been well tested. It's the promising NBA rookie who got picked first in the draft but has never played a full quarter, getting people to say, "if only they'd get him off the bench...".

jcadam 12y ago
> that there are fully verifiable imperative languages out there (with their own serious problem -- correctness is never free), that have actually been used by the industry to write some very important, safety-critical software, and have been actually put to the test much more than Haskell. Ada is absolutely painful to work with as a developer (I used to work in Aerospace). But if you could get your code to compile, it stood a very good chance of just working.
dragonwriter 12y ago
I would just like to point out that, for the number of time you have say, in different phrasing, that Haskell is not the best solution to the problems it aims to solve, you provide not one bit of argument or evidence to support that for any of the areas you say it about. Anyway, lots of the reported production uses of Haskell are in exactly the areas it is supposed to be strong; the problem for sharing that experience is many of them are in internal proprietary systems, not publicly-available or open-source software, so external evaluators don't have the code -- or even, often, a chance to interact with the software.
- pron 12y ago
  > you provide not one bit of argument or evidence to support that for any of the areas you say it about. Well, this isn't a very technical discussion, but I can quickly list them: for shared mutation I think the Clojure approach of transactional/atomic mutation everywhere rather than RT-everywhere is simpler; for correctness/side-effects, imperative effect systems may be easier (well, they don't quite exist other than in a very limited, experimental form, in Koka and Java 8's pluggable type systems -- but Haskell doesn't provide a very fine-grained side-effect-control either). For correctness, Esterel (which has been well proven) and its descendants, seems a lot more sophisticated in terms of proving correctness, while being more intuitive (of course, Esterel introduces a limited computation model, but so does Haskell -- or languages in the same vain -- if they are to be decidable). > the problem for sharing that experience is many of them are in internal proprietary systems Yes, that, too, is a problem, but the bigger problem is that uses in the industry are vanishingly rare -- and the bigger the domain challenge, the rarer still they are. For example, I don't think there exists a single case of a Haskell program that tackles complexity in such a way that implementing it in, say, Java or Clojure, is prohibitively expensive.