5 ms·
The last time I've checked, OOP and functional programming are orthogonal concepts. EDIT: It means that there is no problem for the language to have both OOP &
by tasubotadas 3y ago
The last time I've checked, OOP and functional programming are orthogonal concepts.
EDIT: It means that there is no problem for the language to have both OOP & Functional. They don't have to choose one over another.
- Cthulhu_ 3y agoThat must've been a while ago, I find factors of both working pretty well together. Most languages are a mix nowadays anyway.
- kaba0 3y agoWhy would they be orthogonal? There are entire languages built on top both, like F# and Scala.
- tasubotadas 3y ago>Scala Exactly
- maleldil 3y agoThat's what orthogonal means. They're separate things, and they don't interefere with each other.
- layer8 3y agoOrthogonal means they are independent principles that can be combined freely and don’t contradict each other.
- chriswarbo 3y ago> there is no problem for the language to have both OOP & Functional. They don't have to choose one over another. Sure a language can have both; but us programmers still have to choose one or the other when modelling some domain. The article is basically describing the "expression problem": how to implement a solution in a way that allows new cases to be added https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem The OOP approach makes it easy to add new sorts of data: we just write a new subclass, with implementations for all the interface's methods. However, it's hard to add new sorts of operations: we would have to add new methods to the interface, and update every subclass to implement those methods (very hard if we're writing a library that third parties are subclassing!) The functional/ADT approach makes it easy to add new sorts of operations: we just write a new function, which pattern-matches on all the constructors. However, it's hard to add new sorts of data: we would have to add new constructors to the ADT, and update every function to pattern-match on those constructors (very hard if we're writing a library that third parties are pattern-matching on!) When we're choosing how to represent something, it's important to consider whether future extensions are more likely to be adding new sorts of data (in which case the OOP representation may be best) or more likely to be adding new sorts of operations (in which case the ADT representation may be best). Having to extend such representations in their intended way can feel very natural and satisfying; but having to extend them the other way can be frustrating and laborious.
- tasubotadas 3y agoIf you are doing subclasses you are doing OOP wrong.
- ovis 3y agoDo you consider implementing an interface to be subclassing? And if so, what's the OO alternative? Prototypes?
- tasubotadas 3y agoInterfaces are fine. Anything that works like traits :)
- munificent 3y agoTIL that I've been doing OOP wrong for the past twenty years.
- tasubotadas 3y agonp. https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/ https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2... https://media.pragprog.com/titles/tpp20/inheritance-tax.pdf https://media.pragprog.com/titles/tpp20/inheritance-tax.pdf
- munificent 3y agoYes, I read it the year it came out. :)