4 ms·

This post is also a great demonstration as to why a programming language cannot be evaluated as a feature checklist. OCaml's object system is certainly awesome

by evmar 12y ago

This post is also a great demonstration as to why a programming language cannot be evaluated as a feature checklist. OCaml's object system is certainly awesome but in practice you'll find it is unevenly used -- some never use it, while I'm sure there are others who use it heavily. Because it behaves in a way that is not quite compatible with the rest of the language it is inconvenient to mix APIs that use the two styles of programming. Another comment here on HN links to a post that summarizes with the rule of thumb of simply "don't use objects". The lesson is that any given feature exists in an ecosystem of other features and its utility is dictated by many things (impedance mismatch with the rest of the language or even language cultural problems) other than the specification itself.

haifeng 12y ago
Excellent point!
rwmj 12y ago
I have a slightly more nuanced point of view. I pretty much write OCaml code for a living, and rarely use objects, but that's because they are rarely useful (as a general concept, nothing to do with OCaml). To give a concrete example of a program where I happened to use objects for the first time in ages[1], most of the program works by defining a set of types[2], and then using simple functions to work on those types. The program is essentially: transform the input structure to another structure to another structure. All the structures are publicly defined making it really easy to understand the program and debug when things go wrong. The flow of execution is simple and obvious, and the compiler picks up possible errors in that flow because of the strong typing. But there happened to be one place that I wanted the ability to hide data + use implicit variant code alongside that data, and then I switched over to using objects[3]. It's a narrow use case and I've written a lot of code without ever needing that. Of course in OOP languages you essentially have to use objects to get any work done, and so people go crazy and it's impossible to follow the flow of execution. [1] https://github.com/libguestfs/libguestfs/tree/master/v2v https://github.com/libguestfs/libguestfs/tree/master/v2v [2] https://github.com/libguestfs/libguestfs/blob/master/v2v/types.mli https://github.com/libguestfs/libguestfs/blob/master/v2v/typ... [3] https://github.com/libguestfs/libguestfs/blob/master/v2v/types.mli#L164-L193 https://github.com/libguestfs/libguestfs/blob/master/v2v/typ...
- djur 12y ago
  I'm not a very experienced OCaml developer but after several iterations on a simple game engine in OCaml I found that there were a few places I could significantly reduce boilerplate by using objects. Entities in a game frequently need to carry around their own internal state.

by evmar 12y ago

haifeng 12y ago

Excellent point!

rwmj 12y ago

I have a slightly more nuanced point of view. I pretty much write OCaml code for a living, and rarely use objects, but that's because they are rarely useful (as a general concept, nothing to do with OCaml). To give a concrete example of a program where I happened to use objects for the first time in ages[1], most of the program works by defining a set of types[2], and then using simple functions to work on those types. The program is essentially: transform the input structure to another structure to another structure. All the structures are publicly defined making it really easy to understand the program and debug when things go wrong. The flow of execution is simple and obvious, and the compiler picks up possible errors in that flow because of the strong typing. But there happened to be one place that I wanted the ability to hide data + use implicit variant code alongside that data, and then I switched over to using objects[3]. It's a narrow use case and I've written a lot of code without ever needing that. Of course in OOP languages you essentially have to use objects to get any work done, and so people go crazy and it's impossible to follow the flow of execution. [1] https://github.com/libguestfs/libguestfs/tree/master/v2v https://github.com/libguestfs/libguestfs/tree/master/v2v [2] https://github.com/libguestfs/libguestfs/blob/master/v2v/types.mli https://github.com/libguestfs/libguestfs/blob/master/v2v/typ... [3] https://github.com/libguestfs/libguestfs/blob/master/v2v/types.mli#L164-L193 https://github.com/libguestfs/libguestfs/blob/master/v2v/typ...

djur 12y ago
I'm not a very experienced OCaml developer but after several iterations on a simple game engine in OCaml I found that there were a few places I could significantly reduce boilerplate by using objects. Entities in a game frequently need to carry around their own internal state.