4 ms·

I feel you're unfairly comparing Haskell to the likes of C/C++ that it's not really a rival with. Haskell is a (very) high level language, not a procedural lang

I feel you're unfairly comparing Haskell to the likes of C/C++ that it's not really a rival with. Haskell is a (very) high level language, not a procedural language to build systems on. A more appropriate comparison would be with commonly used high level languages such as Java and Python. The comparison here is meaningful because you'd build similar software with them as you would with Haskell.

ncmncm 7y ago
There is no such language as C/C++. Well-written programs in C++ are very different from programs in good C. (Bad programs are all alike.) C++ programs may be easily as "high level" as Haskell ones, higher than is possible in Java. C++ is clearly the language to beat, as no mainstream production language rivals its performance or expressiveness.
- verttii 7y ago
  Forgive my ignorance, but how can C++ programs be easily as high level as Haskell, which is declarative, garbage collected and curried by default? Does C++ even have algebraic data types, not to mention more advanced stuff like GADTs etc. that are incorporated in Haskell? I haven't been able to get exposure to a language that is comparable in abstraction power with Haskell, except for DSLs.
  - ncmncm 7y ago
    "Declarative" is a means to an end. Imperative gets you there at the same rate. Garbage collection compensates for inadequate resource management facilities. Currying is a neat trick that is fun when you find a way to make it do something useful. Algebraic data types and GADTs are clever ideas very far removed from most real problems faced by real programmers, who have problems no language helps much with, and where the best we, as language designers, can do is try to keep the hell out of the way. C++ has lots of such stuff too, mostly in template land. They can be useful to maximize the generality of libraries -- sometimes enabling great libraries -- but for most programmers most of the time they are at best a distraction, and more typically generate mysteries that absorb unbounded time. Mark Dominus has some of the most insightful writing on the experience of coding Haskell.
    - danielscrubs 7y ago
      “Real programmers don’t use x” - said by every proud programmer that don’t want to learn new concepts since the beginning of time.
      - ncmncm 7y ago
        Real C++ programmers use the hell out of features added because of demonstrated industrial need. Many of them were copied from ML, others Haskell entirely lacks. Haskell has some features C++ doesn't need, that would just make programs harder to understand without actually making the language more powerful.
        tome 7y ago
        Would be helpful if you gave some examples!
        verttii 7y ago
        Unfortunately, without concrete examples it's hard to grasp what features you really mean.
    - tome 7y ago
      > Algebraic data types ... are clever ideas very far removed from most real problems faced by real programmers Everything else you've said has a case that can be made for it but algebraic data types being removed from real problems is utterly false. The contortions that Python programmers (myself being one of them) have to go through in the absence of ADTs are mind boggling. There's no language without sum types that wouldn't be significantly improved by their addition.
      - ncmncm 7y ago
        All variables are sum types in Python. In Haskell as in C++, they serve as an escape valve where the formal type system is too constraining. In C++, we see std::optional, std::variant, and boost::result, and don't find we need many more. Product types are ad-hoc structs, analogous to lambdas as ad-hoc functions. They are important to enable compounding of libraries from different sources, aside from their frequent convenience. Compounding libraries is still hard for other reasons, and so not useful as often as might be hoped. In Python you have the opposite problem of C++ and Haskell: everything could be anything, and you would like them to be guaranteed to be only one or a few things.

ncmncm 7y ago

There is no such language as C/C++. Well-written programs in C++ are very different from programs in good C. (Bad programs are all alike.) C++ programs may be easily as "high level" as Haskell ones, higher than is possible in Java. C++ is clearly the language to beat, as no mainstream production language rivals its performance or expressiveness.

verttii 7y ago
Forgive my ignorance, but how can C++ programs be easily as high level as Haskell, which is declarative, garbage collected and curried by default? Does C++ even have algebraic data types, not to mention more advanced stuff like GADTs etc. that are incorporated in Haskell? I haven't been able to get exposure to a language that is comparable in abstraction power with Haskell, except for DSLs.
- ncmncm 7y ago
  "Declarative" is a means to an end. Imperative gets you there at the same rate. Garbage collection compensates for inadequate resource management facilities. Currying is a neat trick that is fun when you find a way to make it do something useful. Algebraic data types and GADTs are clever ideas very far removed from most real problems faced by real programmers, who have problems no language helps much with, and where the best we, as language designers, can do is try to keep the hell out of the way. C++ has lots of such stuff too, mostly in template land. They can be useful to maximize the generality of libraries -- sometimes enabling great libraries -- but for most programmers most of the time they are at best a distraction, and more typically generate mysteries that absorb unbounded time. Mark Dominus has some of the most insightful writing on the experience of coding Haskell.
  - danielscrubs 7y ago
    “Real programmers don’t use x” - said by every proud programmer that don’t want to learn new concepts since the beginning of time.
    - ncmncm 7y ago
      Real C++ programmers use the hell out of features added because of demonstrated industrial need. Many of them were copied from ML, others Haskell entirely lacks. Haskell has some features C++ doesn't need, that would just make programs harder to understand without actually making the language more powerful.
      - tome 7y ago
        Would be helpful if you gave some examples!
      - verttii 7y ago
        Unfortunately, without concrete examples it's hard to grasp what features you really mean.
  - tome 7y ago
    > Algebraic data types ... are clever ideas very far removed from most real problems faced by real programmers Everything else you've said has a case that can be made for it but algebraic data types being removed from real problems is utterly false. The contortions that Python programmers (myself being one of them) have to go through in the absence of ADTs are mind boggling. There's no language without sum types that wouldn't be significantly improved by their addition.
    - ncmncm 7y ago
      All variables are sum types in Python. In Haskell as in C++, they serve as an escape valve where the formal type system is too constraining. In C++, we see std::optional, std::variant, and boost::result, and don't find we need many more. Product types are ad-hoc structs, analogous to lambdas as ad-hoc functions. They are important to enable compounding of libraries from different sources, aside from their frequent convenience. Compounding libraries is still hard for other reasons, and so not useful as often as might be hoped. In Python you have the opposite problem of C++ and Haskell: everything could be anything, and you would like them to be guaranteed to be only one or a few things.