4 ms·

I'm disappointed that I have yet to see a decent discussion on HN on comparing the ML-style module system with OOP. It's really worth talking about. Also, OCam

I'm disappointed that I have yet to see a decent discussion on HN on comparing the ML-style module system with OOP. It's really worth talking about. Also, OCaml is sometimes called a "higher-order imperative programming language" instead of a functional programming language. It does have strict evaluation and first-class mutation, after all. I would argue that there is NOTHING awkward about writing code in it, controlling for libraries and development tools.

silentbicycle 17y ago
I've wondered what the real difference is between a parametric module system that allows you to substitute along common interfaces, versus an object system that allows "duck" typing, mixins, or interface inheritance. In practice, the difference is that the former comes with type inference. :) I think it'd help if there were more books on OCaml. The French O'Reilly one is pretty good (and free online, http://caml.inria.fr/pub/docs/oreilly-book/ http://caml.inria.fr/pub/docs/oreilly-book/), but the Joshua Smith one is awful, and there aren't many others in English. Also, the OCaml syntax scares some people, and its error messages are pretty unclear, particularly if you haven't learned how to work with the flow of H-M typing. These (and other similar issues) aren't fundamental problems with the language, though, just rough edges in the implementation.
- jganetsk 17y ago
  > I've wondered what the real difference is between a parametric module system that allows you to substitute along common interfaces, versus an object system that allows "duck" typing, mixins, or interface inheritance. In practice, the difference is that the former comes with type inference. :) In OCaml, I can create a module with multiple types, hide information about both of them, and write code sees both of their privates at the same time. In OOP, this can't be done as elegantly (only through the use of inheritance, friends, or inner classes). And this is just the tip of the iceberg; there's a lot more flexibility. Books would help, as would improving the quality of the error messages (which are literal translations from French). However, neither of these are problems with the language itself... you can improve them without changing a single line of code or iota of the specification. Type error messages will with HM always be hard (I think understanding an OCaml error message is a PSPACE-complete problem). But, Haskell has great type error messages, so again, this can be improved. However, I still stand by my claim that the language itself doesn't force programs to be awkwardly structured, as is claimed throughout this discussion.

silentbicycle 17y ago

I've wondered what the real difference is between a parametric module system that allows you to substitute along common interfaces, versus an object system that allows "duck" typing, mixins, or interface inheritance. In practice, the difference is that the former comes with type inference. :) I think it'd help if there were more books on OCaml. The French O'Reilly one is pretty good (and free online, http://caml.inria.fr/pub/docs/oreilly-book/ http://caml.inria.fr/pub/docs/oreilly-book/), but the Joshua Smith one is awful, and there aren't many others in English. Also, the OCaml syntax scares some people, and its error messages are pretty unclear, particularly if you haven't learned how to work with the flow of H-M typing. These (and other similar issues) aren't fundamental problems with the language, though, just rough edges in the implementation.

jganetsk 17y ago
> I've wondered what the real difference is between a parametric module system that allows you to substitute along common interfaces, versus an object system that allows "duck" typing, mixins, or interface inheritance. In practice, the difference is that the former comes with type inference. :) In OCaml, I can create a module with multiple types, hide information about both of them, and write code sees both of their privates at the same time. In OOP, this can't be done as elegantly (only through the use of inheritance, friends, or inner classes). And this is just the tip of the iceberg; there's a lot more flexibility. Books would help, as would improving the quality of the error messages (which are literal translations from French). However, neither of these are problems with the language itself... you can improve them without changing a single line of code or iota of the specification. Type error messages will with HM always be hard (I think understanding an OCaml error message is a PSPACE-complete problem). But, Haskell has great type error messages, so again, this can be improved. However, I still stand by my claim that the language itself doesn't force programs to be awkwardly structured, as is claimed throughout this discussion.