It’s an academic language, designed as a substrate to grow papers in.
If JS infamously has dozens of build systems, Haskell has almost nobody working on tooling. Instead you get many smart people writing libraries for building super abstract spaghetti code - which is great for research and advancing the state of the art (sometimes the wacko abstractions turn out to be good ideas that trickle down into regular programming languages), but would someone please write some tooling as well.
I love Haskell, it’s fun, mind-expanding and absolutely worth learning. Maybe one day it will be ready for prime time, but until then I’d suggest an ML for “real” software.
Not sure I would say that all aspects of tooling are bad though. Stackage for example is great and I wish there was anything even close to it in other languages.
Being productive with it requires rewiring your brain, which depending on what kind of business you run might not be worth it more often than not (same applies to the crab language).
Like it or not, most problems you will want to solve are not "purely functional" but rely on sound management of shared mutable state.
Haskell advocates will say shared mutable state is done better in Haskell than other languages. They will trot out blog posts claiming that Haskell is also a better imperative language than other imperative languages. It isn't.
Just look at all of the theoretical mumbo-jumbo associated with something like Lenses...now look at the utterly trivial problem they solve.
Even for a FP tool, Haskell is riddled with cruft. Look at the set of compiler pragmas that are pretty much required to be in any useful Haskell. Including basic crap like overloading the String type. These are hacks, pure and simple.
You could go on and on and on. Most of the original Haskell advocates from the initial explosion of advocacy around ten years ago have moved on to Rust and other language communities. They gave up, and they were the gurus.
Anyway, like most programming hype, there is no stopping it...you just need to get on the Haskell hype wagon for a while, realize it is a waste of time, then get off and try to inform others.
> Like it or not, most problems you will want to solve are not "purely functional" but rely on sound management of shared mutable state.
This is a claim which is certainly not true in all domains. For example, web applications and compilers, two of Haskell's "killer problem domains", do not heavily rely on shared mutable state. That said, Haskell's approach to shared mutable state is no less sensible than the rest of the language.
> Just look at all of the theoretical mumbo-jumbo associated with something like Lenses...now look at the utterly trivial problem they solve.
With all due respect if you believe this then I'm not sure you fully appreciate the problem that they solve. The terminology is indeed obtuse though.
> Even for a FP tool, Haskell is riddled with cruft. Look at the set of compiler pragmas that are pretty much required to be in any useful Haskell. Including basic crap like overloading the String type. These are hacks, pure and simple.
That's not fair. Haskell is a language that is (de facto) defined as a basis, the Report, plus a set of modernising features which have been implemented since. They're not hacks, they are deliberate optional language features. It's a different approach to most modern languages but no worse. A combined set of such features, called GHC2021, is the new "standard" and enables a huge swath of them by default.
If anything I'd say there is very little hype around Haskell. People look at it and think it's cool, but that's not because of people hyping it up. In fact every post/article I've read about Haskell has been extremely measured and open about its shortcomings.
Sorry if you just wanted to get something off your chest, but it makes me sad to see a perfectly fine language disparaged unfairly.
I dunno. It's not a perfect language but it's sufficient. The bar is pretty low.
Type classes were first proposed around 1989 and Haskell adopted them early on. They made parametric polymorphism tractable. C++ finally adopted Concepts in C++20.
There's literally cruft in any useful language that has been around long enough. Keep searching for that diamond though. It's out there somewhere.
zarzavat|3 years ago
If JS infamously has dozens of build systems, Haskell has almost nobody working on tooling. Instead you get many smart people writing libraries for building super abstract spaghetti code - which is great for research and advancing the state of the art (sometimes the wacko abstractions turn out to be good ideas that trickle down into regular programming languages), but would someone please write some tooling as well.
I love Haskell, it’s fun, mind-expanding and absolutely worth learning. Maybe one day it will be ready for prime time, but until then I’d suggest an ML for “real” software.
troppl|3 years ago
welterde|3 years ago
hobo_mark|3 years ago
My104thaccount|3 years ago
[deleted]
newaccount2021|3 years ago
Haskell advocates will say shared mutable state is done better in Haskell than other languages. They will trot out blog posts claiming that Haskell is also a better imperative language than other imperative languages. It isn't.
Just look at all of the theoretical mumbo-jumbo associated with something like Lenses...now look at the utterly trivial problem they solve.
Even for a FP tool, Haskell is riddled with cruft. Look at the set of compiler pragmas that are pretty much required to be in any useful Haskell. Including basic crap like overloading the String type. These are hacks, pure and simple.
You could go on and on and on. Most of the original Haskell advocates from the initial explosion of advocacy around ten years ago have moved on to Rust and other language communities. They gave up, and they were the gurus.
Anyway, like most programming hype, there is no stopping it...you just need to get on the Haskell hype wagon for a while, realize it is a waste of time, then get off and try to inform others.
johnday|3 years ago
This is a claim which is certainly not true in all domains. For example, web applications and compilers, two of Haskell's "killer problem domains", do not heavily rely on shared mutable state. That said, Haskell's approach to shared mutable state is no less sensible than the rest of the language.
> Just look at all of the theoretical mumbo-jumbo associated with something like Lenses...now look at the utterly trivial problem they solve.
With all due respect if you believe this then I'm not sure you fully appreciate the problem that they solve. The terminology is indeed obtuse though.
> Even for a FP tool, Haskell is riddled with cruft. Look at the set of compiler pragmas that are pretty much required to be in any useful Haskell. Including basic crap like overloading the String type. These are hacks, pure and simple.
That's not fair. Haskell is a language that is (de facto) defined as a basis, the Report, plus a set of modernising features which have been implemented since. They're not hacks, they are deliberate optional language features. It's a different approach to most modern languages but no worse. A combined set of such features, called GHC2021, is the new "standard" and enables a huge swath of them by default.
If anything I'd say there is very little hype around Haskell. People look at it and think it's cool, but that's not because of people hyping it up. In fact every post/article I've read about Haskell has been extremely measured and open about its shortcomings.
Sorry if you just wanted to get something off your chest, but it makes me sad to see a perfectly fine language disparaged unfairly.
agentultra|3 years ago
Type classes were first proposed around 1989 and Haskell adopted them early on. They made parametric polymorphism tractable. C++ finally adopted Concepts in C++20.
There's literally cruft in any useful language that has been around long enough. Keep searching for that diamond though. It's out there somewhere.
ParetoOptimal|3 years ago
In theory this is correct, but incorrect in practice.
- Sincerely a real world Haskell programmer