But that is true for many other languages of the similar caliber, like Rust and C++ are also extremely complicated!
Those Haskell threads are full of exaggerations. I don't know/use a lot of Haskell concepts and I can still produce software with it. You can be just fine with IO and passing everything as arguments. Which is, well, what article is talking about.
I think the major troubles for beginners with C++ is that you can't do anything out of the box like work with files, create a directory or perform a HTTP request. Whereas python or java are ready to use.
The closest thing i can think of in Python is passing a mutable object (like an empty list) as a default param value. C++ is littered with bug-prone landmines like that.
Every time someone has suggested I learn Haskell the discussion goes similar to suggesting I learn German. Sure German from a language perspective has some advantages over English in some situations. Some even argue that it's an objectively better language. But I live in Pennsylvania and speak English as a first language. Outside of moving to Germany/Switzerland/Austria, how do the advantages of German provide enough benefit for me to invest the massive amounts of time to become fluent?
Sure if we could turn back the clock on Computer Science education and have everyone learn lisp as their first language maybe we'd all be avid Haskellers these days and be better off for it. But given how history went it is "harder" to learn and less productive to work in due to external factors alone, regardless of how intrinsically easy/hard the language may be (which is entirely subjective).
I'd go as far as saying it's essential for anyone who likes programming beyond just a profession. Same with lisp.
You don't need to learn all of the language extensions or how to architect serious applications with free as the OP said but it's very useful knowledge and one of the pedestals from which all other languages should be judged.
Plus you'll understand why Idris and dependent types are an interesting future development in safety and language design. While also understanding the source and inspiration of many features in far more popular languages like JS and Rust. And there may be a real future in it via PureScript and other similar projects.
I mean, the rule of three is just insane. How is anyone supposed to anticipate that behavior?
In C++, you can focus on subsets of the language that eschew whole huge paradigms (like templating or inheritance) and you’re roughly no worse off in terms of the scope of practical programs you can write with basic software patterns.
You can’t do this in Haskell. You really do have to learn all the complex hierarchy of paradigm-committing patterns and use nearly all of them nearly all the time, making it much harder to learn than C++ even though C++ is complicated.
Languanges can be complicated in different ways, and Haskell is unique in that you have to engage with every complicated aspect of it nearly all the time.
Err, no you don't. The only slightly unusual concepts Haskell 98 has (from a functional programming point of view) are monads, type classes and laziness. Haskell 98 is a perfectly decent language to write computer programs in. In fact it's even perfectly decent if you largely avoid monads and type classes!
The "you can focus on subsets of the language" claim is no weaker for Haskell than it is for C++.
Exactly. The way they manifest in Haskell requires huge time investment before you can write basic programs. For example, how do you write dynamic dispatch in Haskell 98?
If you give an answer that either (a) involves exotic use of type classes or (b) say “don’t desire dynamic dispatch in a functional paradigm and instead restructure the whole program to avoid needing it” then you’ve proven my point.
That fact that you think monads, type classes and laziness, being “three” concepts (except really they unpack into way more top-level concepts, especially the first two), means you have a huge blind spot. Your experience makes you think of them as self-contained things but they aren’t and even just those three things yield huge complexity sprawl in Haskell.
Your claim now seems to be "Haskell contains a great deal of complexity" or "You can't implement dynamic dispatch in Haskell" which are different things entirely.
(FWIW I'm not quite sure what dynamic dispatch is or whether I've ever needed it, in Haskell, C++ or Python)
Suppose you’re using C++ but you don’t want any objects, exceptions or templating. Ok, you’ll be fine. It will be a lot like C, but you’ll be fine. Nothing will be substantially harder to solve, design or implement.
People write professional software in OCaml and Scheme so I hardly believe your suggestion is impossible.
> Suppose you’re using C++ but you don’t want any objects, exceptions or templating. Ok, you’ll be fine. It will be a lot like C, but you’ll be fine.
Sure, and the same applies to Haskell, except with Standard ML instead of C.
I'm not suggesting that one would be particularly productive like that, only that the level of complexity of Haskell is about the same order as the level of complexity of C++, and one can reduce one's subset of Haskell (all the way down to SML if necessary) in the same way that one can reduce one's subset of C++ (all the way down to C if necessary).
> Nothing will be substantially harder to solve, design or implement.
That surely can't be the case. If it were then objects, exceptions and templating would never have been implemented.
Is that what you mean? Or is this really about something else?