3 ms·

Yeah I have no particular axe to grind on Haskell’s behalf. I’m a Lisp guy who has to write C++ all day like everyone else. Lazy is a ridiculous default, the c

Yeah I have no particular axe to grind on Haskell’s behalf. I’m a Lisp guy who has to write C++ all day like everyone else. Lazy is a ridiculous default, the combinatorial explosion created by GHC extensions makes C compiler quirks look like a gentle massage in comparison, and building Haskell is a friggin migraine on wheels. But for whatever reason, those folks are on average in my experience, serious as a heart attack.

ineedasername 5y ago
I'll take your word for it then, since I have seen similar opinions expressed before, but when you say "serious" what particular qualities are you thinking about?
- benreesman 5y ago
  See a problem, realize it’s a graph, realize it’s traveling salesman, reduce it to 3SAT, and start grinding it out in MiniSAT before I can type “jupyter lab”.
  - eru 5y ago
    That's not particularly Haskell specific. What's more Haskell specific is recognizing many problems can be solved easier when seen through the lens of parsers, interpreters and/or compilers. Haskell's and the whole ML family of languages are great at writing parsers etc. In fact they were originally invented for implementing other languages.
    - CactusOnFire 5y ago
      I have always figured the appeal of Haskell, Clojure, et al., is to transpile your task and turn any software problem into your language of choice.
      - eru 5y ago
        Yes, though that's related, but not really want I wanted to say. I meant that solving a problem in Haskell can often mean eg writing something a bit like a parser.
eru 5y ago
Lazy made historical sense as a default: it forced them to deal with side-effects properly. For a new language I would suggest that without annotation, only pure, total functions are allowed. Haskell makes you annotate side-effecting functions with a tag (like IO). But it allows divergent and partial functions just fine. That's why they can't just remove the laziness. I propose that the latter would also need a tag. The nice thing about total functions is that the choice between evaluation orders becomes purely a matter of optimization, and won't change anything about semantics. Some languages like Agda already do something a bit like this. (Also note that total functions are not Turing complete. But that's a feature, not a bug.)
beanjuiceII 5y ago
ever check this out? https://github.com/Kindelia/HVM https://github.com/Kindelia/HVM

ineedasername 5y ago

I'll take your word for it then, since I have seen similar opinions expressed before, but when you say "serious" what particular qualities are you thinking about?

benreesman 5y ago
See a problem, realize it’s a graph, realize it’s traveling salesman, reduce it to 3SAT, and start grinding it out in MiniSAT before I can type “jupyter lab”.
- eru 5y ago
  That's not particularly Haskell specific. What's more Haskell specific is recognizing many problems can be solved easier when seen through the lens of parsers, interpreters and/or compilers. Haskell's and the whole ML family of languages are great at writing parsers etc. In fact they were originally invented for implementing other languages.
  - CactusOnFire 5y ago
    I have always figured the appeal of Haskell, Clojure, et al., is to transpile your task and turn any software problem into your language of choice.
    - eru 5y ago
      Yes, though that's related, but not really want I wanted to say. I meant that solving a problem in Haskell can often mean eg writing something a bit like a parser.

eru 5y ago

Lazy made historical sense as a default: it forced them to deal with side-effects properly. For a new language I would suggest that without annotation, only pure, total functions are allowed. Haskell makes you annotate side-effecting functions with a tag (like IO). But it allows divergent and partial functions just fine. That's why they can't just remove the laziness. I propose that the latter would also need a tag. The nice thing about total functions is that the choice between evaluation orders becomes purely a matter of optimization, and won't change anything about semantics. Some languages like Agda already do something a bit like this. (Also note that total functions are not Turing complete. But that's a feature, not a bug.)

beanjuiceII 5y ago

ever check this out? https://github.com/Kindelia/HVM https://github.com/Kindelia/HVM