3 ms·

From your post, I gather you are not very familiar with Ocaml module system. It's both where type-level programming happens and what F# doesn't have. You might

by brmgb 6y ago

From your post, I gather you are not very familiar with Ocaml module system. It's both where type-level programming happens and what F# doesn't have. You might be confusing your lack of knowledge of the languages with lack of the language. From my point of view, Ocaml is a lot nicer than Haskell (let's not talk about Scala).

smabie 6y ago
I'm very familar with the OCaml module system. If modular implicits were a thing, I'd say OCaml would be great. But functors are a poor substitute for typeclasses, atleast without modular implicits. Why would you assume that I'm not aware of a core feature of OCaml? Why would I even post about OCaml if I knew nothing (or hadn't written production code in it) about it?
- momentoftop 6y ago
  Functors are indeed a poor substitute for typeclasses if I want ad-hoc polymorphism. If I want ad-hoc polymorphism, I want typeclasses. I find Scala's implicits to be a poor substitute (though not as poor as functors), and I'm sceptical that modular implicits are going to compare to typeclasses. But that's not why I care about functors. I use functors to package a bunch of types and values in a way that depends on a package of other types and values, which was their purpose from the beginning. In Haskell, I often want to do just this, but I find typeclasses (and associated types etc) to be a poor substitute for functors. For this reason, I keep an eye on backpack.
- brmgb 6y ago
  > the idea of "type-level" programming isn't really a thing in the OCaml community. > I'm very familar with the OCaml module system These two statements don't seem compatible to me. > functors are a poor substitute for typeclasses, atleast without modular implicits. First, there are more than functors to Ocaml module system. First-class modules are a thing. Then, how are functors a poor substitute to type class ? Modular implicits is mostly sugar to avoid explicitly mentioning modules. That doesn't directly add anything to Ocaml capabilities.
  - smabie 6y ago
    First place modules and higher order modules are a hack to get around the limited polymorphism that OCaml provides. Like, just compare OCaml code to Haskell code. Haskell is way more concise, way more powerful, and less messy. Like we can't have real monads in OCaml, because no HKT. And the module system isn't a solution. We have to be careful to import the right stuff, because >> and >>= exist for each separate monad. So now we have to write code that's not general, not polymorphic, and just ugly. Haskell is a more powerful language than OCaml, full stop. OCaml programmers always talk about the module system, but it's honestly not very impressive. Typeclasses are a much more elegant solution. I want to just be able to fmap things, and bind things, I don't want to have to think about the concrete types I'm working with. Also the lack of function polymorphism is super shitty. And I think most agree that using different functions for arithmetic on floating points is stupid, inelegant, and a waste of time. Modular implicit could solve this problem, and allow typeclasses like programming in OCaml.
    - yawaramin 6y ago
      > First place modules First-class modules. The points that you're bringing up are points that 99% of programmers don't care about. You're fighting about OCaml vs Haskell features but the really is that most people looking at alternatives in this niche are just going to go with Go or Rust (neither of which has higher-kinded types). The reality is that OCaml offers a very simple and elegant base language, a powerful module system, a limited amount of type-level programming support (locally abstract types, GADTs, etc.), and probably the biggest draw of all: super-fast compile times. Seriously, no matter how impressive the Haskell compiler is–ocamlc and ocamlopt and BuckleScript all run rings around every variant of Haskell compiler. You are criticizing OCaml on criteria that it honestly did not choose to optimize in. Would you criticize Haskell on its lack of a powerful module system, on its lack of strictness by default, on its complex runtime, on its confusing error messages that arise from ad-hoc polymorphism, and on its slow compiles? Sure you could, but it didn't choose to optimize for those. It doesn't make sense to fixate on things that were never a goal in the first place. If those things are your goals then you would simply find a compiler that offers them.

by brmgb 6y ago

smabie 6y ago

I'm very familar with the OCaml module system. If modular implicits were a thing, I'd say OCaml would be great. But functors are a poor substitute for typeclasses, atleast without modular implicits. Why would you assume that I'm not aware of a core feature of OCaml? Why would I even post about OCaml if I knew nothing (or hadn't written production code in it) about it?

momentoftop 6y ago
Functors are indeed a poor substitute for typeclasses if I want ad-hoc polymorphism. If I want ad-hoc polymorphism, I want typeclasses. I find Scala's implicits to be a poor substitute (though not as poor as functors), and I'm sceptical that modular implicits are going to compare to typeclasses. But that's not why I care about functors. I use functors to package a bunch of types and values in a way that depends on a package of other types and values, which was their purpose from the beginning. In Haskell, I often want to do just this, but I find typeclasses (and associated types etc) to be a poor substitute for functors. For this reason, I keep an eye on backpack.
brmgb 6y ago
> the idea of "type-level" programming isn't really a thing in the OCaml community. > I'm very familar with the OCaml module system These two statements don't seem compatible to me. > functors are a poor substitute for typeclasses, atleast without modular implicits. First, there are more than functors to Ocaml module system. First-class modules are a thing. Then, how are functors a poor substitute to type class ? Modular implicits is mostly sugar to avoid explicitly mentioning modules. That doesn't directly add anything to Ocaml capabilities.
- smabie 6y ago
  First place modules and higher order modules are a hack to get around the limited polymorphism that OCaml provides. Like, just compare OCaml code to Haskell code. Haskell is way more concise, way more powerful, and less messy. Like we can't have real monads in OCaml, because no HKT. And the module system isn't a solution. We have to be careful to import the right stuff, because >> and >>= exist for each separate monad. So now we have to write code that's not general, not polymorphic, and just ugly. Haskell is a more powerful language than OCaml, full stop. OCaml programmers always talk about the module system, but it's honestly not very impressive. Typeclasses are a much more elegant solution. I want to just be able to fmap things, and bind things, I don't want to have to think about the concrete types I'm working with. Also the lack of function polymorphism is super shitty. And I think most agree that using different functions for arithmetic on floating points is stupid, inelegant, and a waste of time. Modular implicit could solve this problem, and allow typeclasses like programming in OCaml.
  - yawaramin 6y ago
    > First place modules First-class modules. The points that you're bringing up are points that 99% of programmers don't care about. You're fighting about OCaml vs Haskell features but the really is that most people looking at alternatives in this niche are just going to go with Go or Rust (neither of which has higher-kinded types). The reality is that OCaml offers a very simple and elegant base language, a powerful module system, a limited amount of type-level programming support (locally abstract types, GADTs, etc.), and probably the biggest draw of all: super-fast compile times. Seriously, no matter how impressive the Haskell compiler is–ocamlc and ocamlopt and BuckleScript all run rings around every variant of Haskell compiler. You are criticizing OCaml on criteria that it honestly did not choose to optimize in. Would you criticize Haskell on its lack of a powerful module system, on its lack of strictness by default, on its complex runtime, on its confusing error messages that arise from ad-hoc polymorphism, and on its slow compiles? Sure you could, but it didn't choose to optimize for those. It doesn't make sense to fixate on things that were never a goal in the first place. If those things are your goals then you would simply find a compiler that offers them.