5 ms·

I can't do OO anymore after I learned FP!

pdpi 8y ago
Keep trying, then. I found myself in that space for a while, but everything kind of made sense when the "Erlang is the most object-oriented language in the market" meme clicked into place: a (micro-)service, an Erlang-style actor and an object are almost the exact same unit of abstraction, applied in different ways. The model is always the same: you communicate by message passing — and, for the most part, you want your objects to be given orders rather than be asked questions. When I went back to Java, it became evident how damaging the "everything is an object" mentality of Java really is — it really pushes people towards a whole bunch of anti-patterns. One obvious example is that structs are not objects, and you shouldn't try to make them be. Getters/setters are a clear sign that your entity is a struct rather than an object — if you're at that stage, stop trying to apply OOP principles around its design. Another recurring problem is abusing inheritance, and underusing interfaces. I've written maybe 2-3 abstract classes over the last few years, and, when I code review a PR with any abstract classes (or inheritance of any sort) in it, I can almost always get the original author to factor it away while agreeing that it was a problem in the design. I suggest giving Kotlin a try. Data classes are as close to structs as you'll ever get in the JVM (until Valhalla ships), delegation is crazy easy to achieve, inheritance is heavily discouraged (by having everything be final by default), bare functions and extension functions help keep interfaces clean, and the lambda situation is much better than Java's (receiver lambdas are the language's killer feature, IMO).
Koshkin 8y ago
Aren't these things orthogonal to each other?
- crimsonalucard 8y ago
  OOP as described by java and C++ involves a graph of objects changing each others' state. This is not an orthogonal pattern to functional programming. If you're thinking of functions operating on immutable objects and returning new objects then that is not typically what we refer to as a OOP pattern though technically it may fit the definition.
  - pjmlp 8y ago
    Java and C++ are just one way of doing OOP. More universities should spend time teaching BETA, Self, CLOS, Smalltak, component based architectures.
    - crimsonalucard 8y ago
      I know. The dominant paradigm has changed the definition of the vernacular. Right now the default definition of OOP is the Java and C++ way unless you explicitly state otherwise.
pjmlp 8y ago
I wonder how many of us managed to use Smalltalk and CLOS then.

pdpi 8y ago

Keep trying, then. I found myself in that space for a while, but everything kind of made sense when the "Erlang is the most object-oriented language in the market" meme clicked into place: a (micro-)service, an Erlang-style actor and an object are almost the exact same unit of abstraction, applied in different ways. The model is always the same: you communicate by message passing — and, for the most part, you want your objects to be given orders rather than be asked questions. When I went back to Java, it became evident how damaging the "everything is an object" mentality of Java really is — it really pushes people towards a whole bunch of anti-patterns. One obvious example is that structs are not objects, and you shouldn't try to make them be. Getters/setters are a clear sign that your entity is a struct rather than an object — if you're at that stage, stop trying to apply OOP principles around its design. Another recurring problem is abusing inheritance, and underusing interfaces. I've written maybe 2-3 abstract classes over the last few years, and, when I code review a PR with any abstract classes (or inheritance of any sort) in it, I can almost always get the original author to factor it away while agreeing that it was a problem in the design. I suggest giving Kotlin a try. Data classes are as close to structs as you'll ever get in the JVM (until Valhalla ships), delegation is crazy easy to achieve, inheritance is heavily discouraged (by having everything be final by default), bare functions and extension functions help keep interfaces clean, and the lambda situation is much better than Java's (receiver lambdas are the language's killer feature, IMO).

Koshkin 8y ago

Aren't these things orthogonal to each other?

crimsonalucard 8y ago
OOP as described by java and C++ involves a graph of objects changing each others' state. This is not an orthogonal pattern to functional programming. If you're thinking of functions operating on immutable objects and returning new objects then that is not typically what we refer to as a OOP pattern though technically it may fit the definition.
- pjmlp 8y ago
  Java and C++ are just one way of doing OOP. More universities should spend time teaching BETA, Self, CLOS, Smalltak, component based architectures.
  - crimsonalucard 8y ago
    I know. The dominant paradigm has changed the definition of the vernacular. Right now the default definition of OOP is the Java and C++ way unless you explicitly state otherwise.

pjmlp 8y ago

I wonder how many of us managed to use Smalltalk and CLOS then.