4 ms·

You may have a point with Rust, but you don’t have a point with C++, and certainly not with other mainstream languages like Python, Scala, Java, C#, and others.

by mlthoughts2018 7y ago

You may have a point with Rust, but you don’t have a point with C++, and certainly not with other mainstream languages like Python, Scala, Java, C#, and others. 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.

tome 7y ago
> 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++.
- mlthoughts2018 7y ago
  > “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.
  - tome 7y ago
    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)
    - mlthoughts2018 7y ago
      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.
      - tome 7y ago
        > 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.
      - efnx 7y ago
        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?

tome 7y ago

> 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++.

mlthoughts2018 7y ago
> “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.
- tome 7y ago
  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)
  - mlthoughts2018 7y ago
    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.
    - tome 7y ago
      > 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.
    - efnx 7y ago
      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?