4 ms·

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

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.
    - tome 7y ago
      Naturally by "sum types" I mean "sum types plus the associated language-level conveniences that make them reasonable to work with". Perhaps case statements may be enough. Perhaps arbitrary lambdas are needed. Anyway, they're not reasonable to work with in Python. I'm not particularly familiar with C++ but I doubt they're reasonable to work with in that language either.
      - ncmncm 7y ago
        C++ will probably be getting an equivalent of match statements in a near-future Standard. ("Near" means "before civilization collapses".)
- verttii 7y ago
  I think declarative is a paradigm, a way of thinking and reasoning about code, rather than a means to an end. Declarative code would obviously raise the abstraction level (as it hides implementation details that you produce with imperative code). I don't see how imperative code would hold an equal abstraction power. As for ADTs and the like, these are very basic features used all over Haskell code, combined with pattern matching. There are much more advanced abstraction concepts that are used all over Haskell libraries. I'm sure C++ has good facilities for abstraction. However, as it lacks many of the very advanced abstractions that Haskell has, I find it far fetched that C++ could be described as an equally high level language as the likes of Haskell. From what I understand, that's not even the intention of C++ to begin with. Btw thanks for that reference to Mark Dominus, seems like interesting stuff!

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.
  - tome 7y ago
    Naturally by "sum types" I mean "sum types plus the associated language-level conveniences that make them reasonable to work with". Perhaps case statements may be enough. Perhaps arbitrary lambdas are needed. Anyway, they're not reasonable to work with in Python. I'm not particularly familiar with C++ but I doubt they're reasonable to work with in that language either.
    - ncmncm 7y ago
      C++ will probably be getting an equivalent of match statements in a near-future Standard. ("Near" means "before civilization collapses".)
verttii 7y ago
I think declarative is a paradigm, a way of thinking and reasoning about code, rather than a means to an end. Declarative code would obviously raise the abstraction level (as it hides implementation details that you produce with imperative code). I don't see how imperative code would hold an equal abstraction power. As for ADTs and the like, these are very basic features used all over Haskell code, combined with pattern matching. There are much more advanced abstraction concepts that are used all over Haskell libraries. I'm sure C++ has good facilities for abstraction. However, as it lacks many of the very advanced abstractions that Haskell has, I find it far fetched that C++ could be described as an equally high level language as the likes of Haskell. From what I understand, that's not even the intention of C++ to begin with. Btw thanks for that reference to Mark Dominus, seems like interesting stuff!