6 ms·

> I'm surprised they've not introduced fundamental features to solve or mitigate this problem. The problem is, to completely solve space leaks, Haskell should

> I'm surprised they've not introduced fundamental features to solve or mitigate this problem. The problem is, to completely solve space leaks, Haskell should abandon pervasive laziness. But laziness is sold as one of the best things about Haskell, and most Haskellers do love laziness because it improves composability. I myself hate pervasive laziness, and I'm all for removing it from the language. Unfortunately this argument will fail to convince most Haskellers because they're already sold on the bright sides of pervasive laziness. Ok, this is all good, but from here there's one really annoying aspect of the Haskell community. They try to twist the reality to convince themselves. The typical reaction when these kinds of arguments are brought on the Haskell community is "space leaks are actually rare in the real world applications". Yes, this is the saying from the very community that emphasizes on program correctness. Sure, buffer overflow and memory leaks also rarely happen in other languages? Isn't "exact resource usage" also a part of correctness? At least in a broader sense? Even SPJ (one of the designers of the language) admits laziness should retire now (it was a good experiment to develop purely functional ways, but now the disadvantages outweigh the advantages), but most Haskellers will never agree with this because laziness does also have advantages, and they love it. I actually gave up waiting for the Haskell community to abandon pervasive laziness, so just moved to other languages. Sometimes I get a sense that many Haskellers treat hardware as merely implementation details.

nine_k 11y ago
What other languages did you move to?
- crimsonalucard 11y ago
  Try Scheme aka Dr. Racket. It's up there as one of the "hacker" functional languages that everyone loves but no one really uses in production. Scheme is deceptively simple though,.. so simple that you won't recognize it's beauty and uniqueness until you're really deep in. When I started learning scheme I quickly lost interest due to the fact that I felt I wasn't learning anything new. It wasn't until I discovered sicp and had my mind blown again and again after every lecture did I realize how great lisps are. I recommend checking the course out: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...
  - the_af 11y ago
    Dr Racket is indeed very interesting, but I don't think it's in the same business as Haskell, i.e. statically typed "pure" functional languages. I would have thought, if laziness-by-default was your main problem with Haskell, a proper alternative would be something like SML or OCaml, not a Lisp/Scheme.
    - AnimalMuppet 11y ago
      Is F# lazy? A very quick glance seems to indicate that it is not.
      - lgas 11y ago
        It's strict by default with optional laziness.
    - acveilleux 11y ago
      Racket can be optionally strongly typed. That said, I'm with you on OCaml (or even F#) being a more natural alternative.
gmfawcett 11y ago
While it's not publicly available, there is a strict dialect of Haskell called Mu, owned by Standard Chartered. See https://www.youtube.com/watch?v=hgOzYZDrXL0 https://www.youtube.com/watch?v=hgOzYZDrXL0 . It would be nice if the rest of us could play with it, but so it goes.
crimsonalucard 11y ago
>Sometimes I get a sense that many Haskellers treat hardware as merely implementation details. This is the ideal. The pinnacle of abstraction that HL languages strive for. When you (inevitably) need to think about hardware in a extremely complicated system it means you hit a design flaw in the abstraction. What a lot of haskellers don't realize is that laziness can be one aspect of this flaw.
chriswarbo 11y ago
> I actually gave up waiting for the Haskell community to abandon pervasive laziness, so just moved to other languages. I certainly wouldn't hold my breath for Haskell abandoning pervasive laziness. It's a core principle of the language (Haskell is, after all, "being lazy with class"); if it were removed, the result would be Haskell in name only. If you don't want pervasive laziness then using a different language is absolutely the correct thing to do. That's not a bad thing; it's just a case of having different tools for different jobs. Haskell may be the best fit for some projects but not others.
- LukeHoersten 11y ago
  Completely agree. Laziness has too many benefits not to justify the added complexity of thunks and thunk-based space leaks. If you don't agree, don't use Haskell =)
dragonwriter 11y ago
> I myself hate pervasive laziness, and I'm all for removing it from the language. If you want a ML-derivative without pervasive laziness, there are plenty out there (F#, OCaml, Alice ML and others.) It would make more sense to extend those with appropriate type-system features than try to redesign Haskell from the ground up without pervasive laziness.
codygman 11y ago
> Even SPJ (one of the designers of the language) admits laziness should retire now (it was a good experiment to develop purely functional ways, but now the disadvantages outweigh the advantages) Do you have a source for this? I recall him saying something similar but different in spirit.

nine_k 11y ago

What other languages did you move to?

crimsonalucard 11y ago
Try Scheme aka Dr. Racket. It's up there as one of the "hacker" functional languages that everyone loves but no one really uses in production. Scheme is deceptively simple though,.. so simple that you won't recognize it's beauty and uniqueness until you're really deep in. When I started learning scheme I quickly lost interest due to the fact that I felt I wasn't learning anything new. It wasn't until I discovered sicp and had my mind blown again and again after every lecture did I realize how great lisps are. I recommend checking the course out: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/ http://ocw.mit.edu/courses/electrical-engineering-and-comput...
- the_af 11y ago
  Dr Racket is indeed very interesting, but I don't think it's in the same business as Haskell, i.e. statically typed "pure" functional languages. I would have thought, if laziness-by-default was your main problem with Haskell, a proper alternative would be something like SML or OCaml, not a Lisp/Scheme.
  - AnimalMuppet 11y ago
    Is F# lazy? A very quick glance seems to indicate that it is not.
    - lgas 11y ago
      It's strict by default with optional laziness.
  - acveilleux 11y ago
    Racket can be optionally strongly typed. That said, I'm with you on OCaml (or even F#) being a more natural alternative.

gmfawcett 11y ago

While it's not publicly available, there is a strict dialect of Haskell called Mu, owned by Standard Chartered. See https://www.youtube.com/watch?v=hgOzYZDrXL0 https://www.youtube.com/watch?v=hgOzYZDrXL0 . It would be nice if the rest of us could play with it, but so it goes.

crimsonalucard 11y ago

>Sometimes I get a sense that many Haskellers treat hardware as merely implementation details. This is the ideal. The pinnacle of abstraction that HL languages strive for. When you (inevitably) need to think about hardware in a extremely complicated system it means you hit a design flaw in the abstraction. What a lot of haskellers don't realize is that laziness can be one aspect of this flaw.

chriswarbo 11y ago

> I actually gave up waiting for the Haskell community to abandon pervasive laziness, so just moved to other languages. I certainly wouldn't hold my breath for Haskell abandoning pervasive laziness. It's a core principle of the language (Haskell is, after all, "being lazy with class"); if it were removed, the result would be Haskell in name only. If you don't want pervasive laziness then using a different language is absolutely the correct thing to do. That's not a bad thing; it's just a case of having different tools for different jobs. Haskell may be the best fit for some projects but not others.

LukeHoersten 11y ago
Completely agree. Laziness has too many benefits not to justify the added complexity of thunks and thunk-based space leaks. If you don't agree, don't use Haskell =)

dragonwriter 11y ago

> I myself hate pervasive laziness, and I'm all for removing it from the language. If you want a ML-derivative without pervasive laziness, there are plenty out there (F#, OCaml, Alice ML and others.) It would make more sense to extend those with appropriate type-system features than try to redesign Haskell from the ground up without pervasive laziness.

codygman 11y ago

> Even SPJ (one of the designers of the language) admits laziness should retire now (it was a good experiment to develop purely functional ways, but now the disadvantages outweigh the advantages) Do you have a source for this? I recall him saying something similar but different in spirit.