5 ms·

I see. I think I have a visceral reaction whenever people express sentiments like that, partially because it's Haskell marketing/branding that has worked too we

I see. I think I have a visceral reaction whenever people express sentiments like that, partially because it's Haskell marketing/branding that has worked too well. IMO, Haskell's insistence on purity (which has been an excellent choice advertising wise) has harmed other functional languages. "If you're gonna learn a FP language, why bother with a half-baked impure language?" is a sentiment I've seen thrown around multiple times. This is somebody else's point I read, but there's also a cognitive dissonance between 1. Haskell is pure, so it's very easy to reason about anything and 2. Imperative programming is just as easy in Haskell as any other language if you use the do notation. Could you give an example of OCaml's designers removing too much stuff? Are you talking about the lackluster stdlib here haha? As for laziness, I agree. I like lazy semantics (I'd argue they might almost be strictly superior than strict semantics), but there's too many things it sacrifices. Being able to reason about resource/time composability, having stack traces, having a debugger, etc. is amazing.

nnq 9y ago
To be honest, what gave me a "bitter taste" after looking at OCaml was not the lack of purity or "which stdlib" issue, but the lack of any kind of usable polymorphism. I mean, having to write + or +. or +/ instead of having something like a Typeclass for nice polymorphic operators? Feels like an annoying straightjacket and syntactic noise. And I don't understand the tradeoff: since I see types a lot like "compiler checked documentation that can also work as basic tests", I see no value in type inference for functions - I'd rather have only local type inference for variables, specify manually all the types of all the functions (this helps you think better anyway) and instead be free to binge on polymorphic operators and functions/methods. Haskell almost seemed to deliver that with its typeclasses. But then its laziness and monads and weird handling of records make it too weird for practical use for me. Is there an "OCaml with typeclasses or other form of polymorphism"? :)
- chillee 9y ago
  I guess the closest thing to what you want in Ocaml is modular implicits. http://tycon.github.io/modular-implicits.html http://tycon.github.io/modular-implicits.html As far as the tradeoff, my view on types is a bit different than yours, I think. First, a quick note: > specify manually all the types of all the functions This is usually encouraged in OCaml, in the form of a .mli file. I think types can be a lot more than "compiler checked documentation that can also work as basic tests". They allow you to encode invariants that allow the compiler to check more than basic stuff. I thought this video had a good example. https://www.youtube.com/watch?v=-J8YyfrSwTk&t=20m10s https://www.youtube.com/watch?v=-J8YyfrSwTk&t=20m10s
  - nnq 9y ago
    wow, that video rocks! thx!
- thedufer 9y ago
  As Haskell shows, typeclasses are not ruled out by type inference. There is a reason they can't be added to OCaml, though, and it is functors. OCaml's functors are fundamentally incompatible with typeclasses. I think one of the problems with getting new people into OCaml is that you feel the pain of not having typeclasses long before you understand the power of functors.

nnq 9y ago

To be honest, what gave me a "bitter taste" after looking at OCaml was not the lack of purity or "which stdlib" issue, but the lack of any kind of usable polymorphism. I mean, having to write + or +. or +/ instead of having something like a Typeclass for nice polymorphic operators? Feels like an annoying straightjacket and syntactic noise. And I don't understand the tradeoff: since I see types a lot like "compiler checked documentation that can also work as basic tests", I see no value in type inference for functions - I'd rather have only local type inference for variables, specify manually all the types of all the functions (this helps you think better anyway) and instead be free to binge on polymorphic operators and functions/methods. Haskell almost seemed to deliver that with its typeclasses. But then its laziness and monads and weird handling of records make it too weird for practical use for me. Is there an "OCaml with typeclasses or other form of polymorphism"? :)

chillee 9y ago
I guess the closest thing to what you want in Ocaml is modular implicits. http://tycon.github.io/modular-implicits.html http://tycon.github.io/modular-implicits.html As far as the tradeoff, my view on types is a bit different than yours, I think. First, a quick note: > specify manually all the types of all the functions This is usually encouraged in OCaml, in the form of a .mli file. I think types can be a lot more than "compiler checked documentation that can also work as basic tests". They allow you to encode invariants that allow the compiler to check more than basic stuff. I thought this video had a good example. https://www.youtube.com/watch?v=-J8YyfrSwTk&t=20m10s https://www.youtube.com/watch?v=-J8YyfrSwTk&t=20m10s
- nnq 9y ago
  wow, that video rocks! thx!
thedufer 9y ago
As Haskell shows, typeclasses are not ruled out by type inference. There is a reason they can't be added to OCaml, though, and it is functors. OCaml's functors are fundamentally incompatible with typeclasses. I think one of the problems with getting new people into OCaml is that you feel the pain of not having typeclasses long before you understand the power of functors.