> You can’t do this in Haskell. You really do have to learn all the complex hierarchy of paradigm-committing patterns
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++.
> “The only slightly unusual concepts Haskell 98 has (from a functional programming point of view) are monads, type classes and laziness.“
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.
I'm sorry, I'm not sure what this has to do with the "you can focus on subsets of the language" claim being no weaker for Haskell than it is for C++. Perhaps you can clarify?
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 wanted to write professional software in Haskell using only the IO monad and modules of functions. How would you do it? I don’t believe it can actually be done in a serious way.
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.
> Suppose you wanted to write professional software in Haskell using only the IO monad and modules of functions. How would you do it? I don’t believe it can actually be done in a serious way.
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.
I must be missing the point here because if you wanted to “write ... Haskell using only the IO monad and modules of functions” you could simply write your modules (Haskell supports modules) and then write your IO. Done.
Is that what you mean? Or is this really about something else?
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++.