4 ms·

I view this as more of a general, why should somebody learn Ocaml instead of Haskell? There's a couple of reasons. #1. Ocaml's type system is nearly as expres

I view this as more of a general, why should somebody learn Ocaml instead of Haskell? There's a couple of reasons. #1. Ocaml's type system is nearly as expressive as Haskell's and includes several features that Haskell's does not. Polymorphic variants and functors being notable ones. #2. Laziness is very hard to get right in practice. I'm sure Haskell enthusiasts will not be very happy with that statement, but I think it's true. It's the reason why one of the biggest users of Haskell (and the most notable example of Haskell in industry), Standard Chartered, uses their own Haskell compiler that's strict by default. #3. Less productive in practice. For example, long build times are a huge problem in practice. See https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/ https://www.reddit.com/r/haskell/comments/45q90s/is_anything... for comments from the Haskell community, including GHC maintainers. Really though, I don't think you can really go that wrong with either. Transferring from each language to the other one isn't very difficult, and they're both excellent languages.

chillee 9y ago
I wrote this on my phone a couple hours ago, and I wanted to add a couple qualifiers that might be misleading to people. Laziness being hard to deal with isn't the only reason Standard Chartered uses their own compiler that's strict by default. However, they have noted that they do think strict haskell is a lot easier to deal with.
- tome 9y ago
  > they have noted that they do think strict haskell is a lot easier to deal with That's news to me. Where did they note that? Lennart Augustsson explicitly says "I don't think strict or lazy matters that much in practice; they both work fine". http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-evaluation-in.html http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...
  - chillee 9y ago
    I was basing off of this CUFP report regarding Standard Chartered's use of Haskell. http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, debugging and exception propagation. The chief downside of strict semantics, in their experience, is the increased difficulty of modular composition FWIW, I am a bit jealous of how laziness makes it easier to achieve function composition, and that was something that I wish was easier in strict semantics.
    - tome 9y ago
      Unless I've missed something there is no claim in that document about why SCB chose Mu to be strict.
      - dllthomas 9y ago
        The quoted passage can be interpreted as one - presumably the implication is that it had those attributes relative to alternative semantics (and might have been expected to do so).
        tome 9y ago
        It's unfortunate that a short passage from an article not even written by either of the authors of Mu would be taken as evidence that SCB thought that strictness was better than laziness.
        chillee 9y ago
        I mean, if you want a direct quote from Lennart Augustsson, here's a quick transcription of the relevant parts of the relevant video. https://www.youtube.com/watch?v=hgOzYZDrXL0 https://www.youtube.com/watch?v=hgOzYZDrXL0 > So strictness is really fantastic, I must say. Stack traces work. When something goes wrong, you can say "so you call things from there to there to there". It's the single most time saving thing from Mu compared to Haskell, because things do go wrong from now and then, and it's so great to know exactly what went wrong... And strict languages have what I call resource composition. So if you understand the complexity of 2 parts you can stick them together and nothing weird happens. They add up. That's not true in lazy languages. And debugging, it's sensible in strict languages. And exceptions, they actually work! Strictness is great. It's terrible, also. So it has nice resource composition but it doesn't compose nicely semantically. So laziness has some good things as well. I think laziness is a much nicer way of programming except for these pesky resources. You definitely need some lazy functions, even C has lazy functions. And then he goes on to talk about the ways that they allow laziness in a strict language, and when they need laziness. Screenshots of relevant slides. Considering that the report was pretty much a summary of the talks given at CUFP, I don't know why you would cast doubt on its legitimacy. https://i.imgur.com/fqr5P8g.jpg https://i.imgur.com/fqr5P8g.jpg https://i.imgur.com/HieskA0.jpg https://i.imgur.com/HieskA0.jpg
tome 9y ago
> It's the reason why one of the biggest users of Haskell (and the most notable example of Haskell in industry), Standard Chartered, uses their own Haskell compiler that's strict by default. No it's not. The reason Mu is strict is that it was designed to target an existing strict runtime.
- yawaramin 9y ago
  That begs the question: why target Haskell to an existing strict runtime instead of using Haskell's own delayed evaluation runtime?
  - dllthomas 9y ago
    I always understood it to be for interoperability with existing software targeting that runtime, but I'm not sure that was more than assumption.
    - tome 9y ago
      That is correct.
dllthomas 9y ago
For those who don't already know an ML, just saying "functor" isn't helpful (the term is too overloaded). "Parameterized modules" might be a better term for that context. For those who don't know, ML-style modules are significantly more interesting than most module systems, and let you pass modules as arguments to modules at import.

chillee 9y ago

I wrote this on my phone a couple hours ago, and I wanted to add a couple qualifiers that might be misleading to people. Laziness being hard to deal with isn't the only reason Standard Chartered uses their own compiler that's strict by default. However, they have noted that they do think strict haskell is a lot easier to deal with.

tome 9y ago
> they have noted that they do think strict haskell is a lot easier to deal with That's news to me. Where did they note that? Lennart Augustsson explicitly says "I don't think strict or lazy matters that much in practice; they both work fine". http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-evaluation-in.html http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...
- chillee 9y ago
  I was basing off of this CUFP report regarding Standard Chartered's use of Haskell. http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, debugging and exception propagation. The chief downside of strict semantics, in their experience, is the increased difficulty of modular composition FWIW, I am a bit jealous of how laziness makes it easier to achieve function composition, and that was something that I wish was easier in strict semantics.
  - tome 9y ago
    Unless I've missed something there is no claim in that document about why SCB chose Mu to be strict.
    - dllthomas 9y ago
      The quoted passage can be interpreted as one - presumably the implication is that it had those attributes relative to alternative semantics (and might have been expected to do so).
      - tome 9y ago
        It's unfortunate that a short passage from an article not even written by either of the authors of Mu would be taken as evidence that SCB thought that strictness was better than laziness.
        chillee 9y ago
        I mean, if you want a direct quote from Lennart Augustsson, here's a quick transcription of the relevant parts of the relevant video. https://www.youtube.com/watch?v=hgOzYZDrXL0 https://www.youtube.com/watch?v=hgOzYZDrXL0 > So strictness is really fantastic, I must say. Stack traces work. When something goes wrong, you can say "so you call things from there to there to there". It's the single most time saving thing from Mu compared to Haskell, because things do go wrong from now and then, and it's so great to know exactly what went wrong... And strict languages have what I call resource composition. So if you understand the complexity of 2 parts you can stick them together and nothing weird happens. They add up. That's not true in lazy languages. And debugging, it's sensible in strict languages. And exceptions, they actually work! Strictness is great. It's terrible, also. So it has nice resource composition but it doesn't compose nicely semantically. So laziness has some good things as well. I think laziness is a much nicer way of programming except for these pesky resources. You definitely need some lazy functions, even C has lazy functions. And then he goes on to talk about the ways that they allow laziness in a strict language, and when they need laziness. Screenshots of relevant slides. Considering that the report was pretty much a summary of the talks given at CUFP, I don't know why you would cast doubt on its legitimacy. https://i.imgur.com/fqr5P8g.jpg https://i.imgur.com/fqr5P8g.jpg https://i.imgur.com/HieskA0.jpg https://i.imgur.com/HieskA0.jpg

tome 9y ago

> It's the reason why one of the biggest users of Haskell (and the most notable example of Haskell in industry), Standard Chartered, uses their own Haskell compiler that's strict by default. No it's not. The reason Mu is strict is that it was designed to target an existing strict runtime.

yawaramin 9y ago
That begs the question: why target Haskell to an existing strict runtime instead of using Haskell's own delayed evaluation runtime?
- dllthomas 9y ago
  I always understood it to be for interoperability with existing software targeting that runtime, but I'm not sure that was more than assumption.
  - tome 9y ago
    That is correct.

dllthomas 9y ago

For those who don't already know an ML, just saying "functor" isn't helpful (the term is too overloaded). "Parameterized modules" might be a better term for that context. For those who don't know, ML-style modules are significantly more interesting than most module systems, and let you pass modules as arguments to modules at import.