3 ms·

Could you elaborate on this? I would agree with "Haskell is not an ML" but I think the MLs (SML, OCaml, Mythryl, F#) are close to Haskell, and closer to Haskell

Could you elaborate on this? I would agree with "Haskell is not an ML" but I think the MLs (SML, OCaml, Mythryl, F#) are close to Haskell, and closer to Haskell than to other programming languages, certainly closer than to Scala. Haskell is lazy, pure, and has typeclasses, while MLs are strict, impure, and (sometimes, usually) have modules, ... while there might be a lot of other differences, there are a lot of similarities too, between algebraic datatypes, Hindley-Milner, pattern matching, etc...

michaelochurch 13y ago
Not grandparent, but let me try. ML (Ocaml, I should say, because that's my experience) is like a functional C. As a production language, I'd recommend it highly. It has excellent garbage collection. It generates blazingly fast native code. I can't speak either way about Haskell's use in production. I'm sure that many people have made it work. I just don't know how hard it is in practice. Haskell is lazy, for one, which makes it hard to reason about performance. You can have production memory leaks that are a bitch to debug. It also has a much more powerful, but also more complex type system. Explicit functors (Ocaml) are replaced by implicit type classes, which make the language more attractive (I'll grant that) but also make it easier to hang yourself by the monads. Haskell's still a great language, and there are a million things that recommend it. However, I don't see it as occupying the same space as the ML family. The main similarity is that both use Hindley-Milner type inference, but there are a lot of differences, too. Finally, Haskell is pure (except in the IO Monad, and a couple others) while Ocaml's not. You have stateful arrays and ref cells in Ocaml, and use them all the time when you're writing high-performance production code. In Haskell, any IO is to be done "in the IO monad" (which means, "in the context of evaluating an IO a", the latter being a thunk that does IO and returns an a.)
- ky3 13y ago
  It also has a much more powerful, but also more complex type system. To be precise, it's type _inference_ of Damas-Hindley-Milner + Typeclasses that poses the most gotchas. (Plain vanilla DHM is just ML. You can hack Haskell without class, but you can't get the class out of Haskell.) Experience with Prolog helps, since a form of logical deduction, generally speaking, is what's happening behind the scenes. You could think of the compiler as applying AI to figure out the types. This kind of AI is magic when it works and baffling when it barfs. One way out is to skip the AI entirely and annotate all the types by hand. Now the compiler only has to check types, not infer them. When it stumbles over imperfect code, the error messages become a lot more decipherable.

michaelochurch 13y ago

Not grandparent, but let me try. ML (Ocaml, I should say, because that's my experience) is like a functional C. As a production language, I'd recommend it highly. It has excellent garbage collection. It generates blazingly fast native code. I can't speak either way about Haskell's use in production. I'm sure that many people have made it work. I just don't know how hard it is in practice. Haskell is lazy, for one, which makes it hard to reason about performance. You can have production memory leaks that are a bitch to debug. It also has a much more powerful, but also more complex type system. Explicit functors (Ocaml) are replaced by implicit type classes, which make the language more attractive (I'll grant that) but also make it easier to hang yourself by the monads. Haskell's still a great language, and there are a million things that recommend it. However, I don't see it as occupying the same space as the ML family. The main similarity is that both use Hindley-Milner type inference, but there are a lot of differences, too. Finally, Haskell is pure (except in the IO Monad, and a couple others) while Ocaml's not. You have stateful arrays and ref cells in Ocaml, and use them all the time when you're writing high-performance production code. In Haskell, any IO is to be done "in the IO monad" (which means, "in the context of evaluating an IO a", the latter being a thunk that does IO and returns an a.)

ky3 13y ago
It also has a much more powerful, but also more complex type system. To be precise, it's type _inference_ of Damas-Hindley-Milner + Typeclasses that poses the most gotchas. (Plain vanilla DHM is just ML. You can hack Haskell without class, but you can't get the class out of Haskell.) Experience with Prolog helps, since a form of logical deduction, generally speaking, is what's happening behind the scenes. You could think of the compiler as applying AI to figure out the types. This kind of AI is magic when it works and baffling when it barfs. One way out is to skip the AI entirely and annotate all the types by hand. Now the compiler only has to check types, not infer them. When it stumbles over imperfect code, the error messages become a lot more decipherable.