4 ms·

Hearing people say that they dislike OOP is like hearing people say they dislike power drills. It's one tool of many, and it has its time and place. I think wha

Hearing people say that they dislike OOP is like hearing people say they dislike power drills. It's one tool of many, and it has its time and place. I think what most people truly dislike are situations where someone has tried to use a power drill to cut down a tree, and refuses to spend time learning about chainsaws. Building a compiler? Try functional programming. Building a fault tolerant service? Try the actor model. Building a set of reusable components? Try OOP.

enriquto 6y ago
But a power drill is a single tool, OOP is more like a collection of techniques. I prefer Pike's analogy that OOP is like woodworking. Sure, it is a self-consistent body of knowledge, and there are very beautiful things that you can make using wood. But that does not mean that everything that can be build in wood sould, nor that basic tenets of woodworking (e.g., the "direction of the grain") make any sense at all when you are using different materials.
- Rochus 6y ago
  Maybe the comparison with a single tool is too simple, but actually OOP is just another way to organize code. We should not forget that the first C++ compiler just translated everything to plain C including virtual tables an such. So we can obviously write object-oriented programs using plain C. The integration in the language makes programming more comfortable. The level of OO support in a language varies: C on one end, and Smalltalk on the other where even loops and control structures are objects. Wirth identified the essence of OO in extensible types (which is the only OO mechanism available in original Oberon). Kay identified the essence of OO in sending messages to (active) objects. Quite different views under the same term, but both views represent aspects of solid software engineering. The people who flatly devaluate OO have simply not noticed that they also devaluate parts of their favorite ideology.
- wvenable 6y ago
  I like this analogy -- especially since like with woodworking it's not hard to incorporate another material/paradigm (steel, plastic, etc) into the project as necessary when you need more strength or flexibility. And like with programming paradigms, not everyone has experience in both woodworking, plastics, and steel production.
- amdelamar 6y ago
  That's a great metaphor for OOP. What is the full quote or reference from? This is all I could find: https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
  - enriquto 6y ago
    Yes, that seems to be it. Pike's quote from that interview: (...) let me say that I'm not much of a fan of object-oriented design. I've seen some beautiful stuff done with OO, and I've even done some OO stuff myself, but it's just one way to approach a problem. For some problems, it's an ideal way; for others, it's not such a good fit. Here's an analogy. If you want to make some physical artifact, you might decide to build it purely in wood because you like the way the grain of the wood adds to the beauty of the object. In fact many of the most beautiful things in the world are made of wood. But wood is not ideal for everything. No amount of beauty of the grain can make wood conduct electricity, or support a skyscraper, or absorb huge amounts of energy without breaking. Sometimes you need metal or plastic or synthetic materials; more often you need a wide range of materials to build something of lasting value. Don't let the fact that you love wood blind you to the problems wood has as a material, or to the possibilities offered by other materials. The promoters of object-oriented design sometimes sound like master woodworkers waiting for the beauty of the physical block of wood to reveal itself before they begin to work. "Oh, look; if I turn the wood this way, the grain flows along the angle of the seat at just the right angle, see?" Great, nice chair. But will you notice the grain when you're sitting on it? And what about next time? Sometimes the thing that needs to be made is not hiding in any block of wood.
- esperent 6y ago
  Much as I love woodworking, I think that's a dismissive analogy, since the immediate assumption is that you can only build small things out of wood. You can't build skyscrapers or highways or particle accelerators out of wood, for those you need metal and concrete. A fairer analogy would be to say that OOP is a particular architectural style, and FP is another.
- PaulDavisThe1st 6y ago
  OOP is like Japanese woodworking: no screws, no nails, no glue. You can build beautiful things with it (though it requires great skill to do it correctly and accurately). You can mix Japanese woodworking with European woodworking by using screws, nails and glue whenever you feel like it. Its simpler than pure Japanese woodworking, not as pretty, quicker to construct, doesn't last as well. You can even forego Japanese woodworking entirely, but to do so is to throw away an entire culture's worth of knowledge about how to cut, shape and join wood, so likely not a great idea.
leafboi 6y ago
What if I told you that OOP only provides illusions of reuseable components and that most OOP components aren't really that reuseable. In order to build reuseable components you need components that compose well. Object composition does not allow for composition without specific glue code for each integration. For example: functions addOne and addTwo can compose to form addThree with a single general function composition operator, no glue code needed and no need for addOne or addTwo to be aware of each other. (addThree = addOne . addTwo) OneAdder and TwoAdder cannot compose without specific glue code or specific interface code to allow for DI. ThreeAdder = composeAdder(OneAdder, TwoAdder) would be implementation specific. Additionally ThreeAdder(TwoAdder, OneAdder) makes ThreeAdder aware of TwoAdder and OneAdder. These are not qualities of reuseability. The existence of a mutating object breaks reuseability. OOP does have it's use cases but the hate does comes from somewhere. One of the main downsides of OOP is the fact that current practices makes it one of the least reusable paradigms ever. DI and object composition are illusions. That being said it's not all that bad... not all business apps need the form of extreme reuseability that FP provides, so OOP is often good enough.
- contravariant 6y ago
  Don't end your class names with -er.
  - leafboi 6y ago
    Naming is a superficial issue that is subjective as opposed to a structural problem that is pervasive. The point of the example wasn't to talk about naming. It was to talk about a fundamental structural problem with OOP.
    - PaulDavisThe1st 6y ago
      Clearly you are not familiar with the classic aphorism: "There are 2 hard problems in computer science: cache invalidation, and naming things" or its cousin: "There are 2 hard problems in computer science: cache invalidation, naming things and off-by-one errors".
- 6y ago
dnautics 6y ago
Every functional programming system I've worked in have been way more reusable than the OOP systems that I have worked in. It's just that the idioms for reusability are different, and even different between fps (julia uses multiple dispatch and elixir uses behaviours and protocols).
chongli 6y ago
I'm one of those people that dislike OOP. I would call it more of a Swiss army knife than a power drill. It's a complicated mashup of different tools, many of which are not very good. A lot of people don't seem to mind this though. I, personally, am a believer in minimalism. Features which experts tell beginners to avoid should be removed. That's very hard to do with programming languages that need to support legacy code though. So I always look for new programming languages that try to do things differently, with as few features as possible.
- AnimalMuppet 6y ago
  The problem is, if you remove the parts the experts tell beginners to avoid, then those parts are gone even when those beginners have become experts. Analogy: You talk to some master chefs. You tell them that the sharp knives are dangerous; they should get rid of them. They're going to tell you to get lost. The knives are valuable to them precisely because they are sharp. Sure, an amateur like me could seriously cut himself on one. So?
  - chongli 6y ago
    Master chefs will tell you sharp knives are safer than dull ones because dull knives tend to slip instead of cutting. That’s been my experience too, as someone who loves to cook and keeps his knives sharp. I don’t think your analogy is appropriate though. My original analogy, the Swiss Army knife, conveys what I think is the core of the problem with OOP: it takes unrelated, powerful tools, and ties them together in a way that makes them unwieldy and more difficult to use. This problem is inherent to the object itself. It ties together unrelated concepts: polymorphism, data abstraction, mutable state, inheritance, and modules. Hence the Swiss Army knife analogy. Other languages (namely functional languages) give you all of these powerful tools but you get them separately, so they’re easier to control.
    - igouy 6y ago
      Master chefs have learned to keep their fingers away from the blade — sharp knives cut to the bone.
lmm 6y ago
Some tools are just bad. I've yet to find a case where OOP was actually better than not using OOP. (e.g. a library of reusable functions and datastructures is the best way to build a set of reusable components, in my experience).
- dnautics 6y ago
  I'm about as anti OOP as they come but I think this is uncharitable; There have been, historically, use cases where OOP was legitimately the best thing around. I think that it might be worth reconsidering on a few grounds: 1) performance bottlenecks are generally no longer CPU computation (network tends to dominate for many many things), and there is nonzero overhead to most functional operations. 2) coordination-free concurrency can in many cases often overcome computational bottlenecks, and non-OOP is far more effective for the code author in dealing with/grokking concurrency. 3) in the intervening time, functional patterns for some things (like UI) have been discovered which make fp a good fit for things that in the past were understandably the domain of OOP.

enriquto 6y ago

But a power drill is a single tool, OOP is more like a collection of techniques. I prefer Pike's analogy that OOP is like woodworking. Sure, it is a self-consistent body of knowledge, and there are very beautiful things that you can make using wood. But that does not mean that everything that can be build in wood sould, nor that basic tenets of woodworking (e.g., the "direction of the grain") make any sense at all when you are using different materials.

Rochus 6y ago
Maybe the comparison with a single tool is too simple, but actually OOP is just another way to organize code. We should not forget that the first C++ compiler just translated everything to plain C including virtual tables an such. So we can obviously write object-oriented programs using plain C. The integration in the language makes programming more comfortable. The level of OO support in a language varies: C on one end, and Smalltalk on the other where even loops and control structures are objects. Wirth identified the essence of OO in extensible types (which is the only OO mechanism available in original Oberon). Kay identified the essence of OO in sending messages to (active) objects. Quite different views under the same term, but both views represent aspects of solid software engineering. The people who flatly devaluate OO have simply not noticed that they also devaluate parts of their favorite ideology.
wvenable 6y ago
I like this analogy -- especially since like with woodworking it's not hard to incorporate another material/paradigm (steel, plastic, etc) into the project as necessary when you need more strength or flexibility. And like with programming paradigms, not everyone has experience in both woodworking, plastics, and steel production.
amdelamar 6y ago
That's a great metaphor for OOP. What is the full quote or reference from? This is all I could find: https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
- enriquto 6y ago
  Yes, that seems to be it. Pike's quote from that interview: (...) let me say that I'm not much of a fan of object-oriented design. I've seen some beautiful stuff done with OO, and I've even done some OO stuff myself, but it's just one way to approach a problem. For some problems, it's an ideal way; for others, it's not such a good fit. Here's an analogy. If you want to make some physical artifact, you might decide to build it purely in wood because you like the way the grain of the wood adds to the beauty of the object. In fact many of the most beautiful things in the world are made of wood. But wood is not ideal for everything. No amount of beauty of the grain can make wood conduct electricity, or support a skyscraper, or absorb huge amounts of energy without breaking. Sometimes you need metal or plastic or synthetic materials; more often you need a wide range of materials to build something of lasting value. Don't let the fact that you love wood blind you to the problems wood has as a material, or to the possibilities offered by other materials. The promoters of object-oriented design sometimes sound like master woodworkers waiting for the beauty of the physical block of wood to reveal itself before they begin to work. "Oh, look; if I turn the wood this way, the grain flows along the angle of the seat at just the right angle, see?" Great, nice chair. But will you notice the grain when you're sitting on it? And what about next time? Sometimes the thing that needs to be made is not hiding in any block of wood.
esperent 6y ago
Much as I love woodworking, I think that's a dismissive analogy, since the immediate assumption is that you can only build small things out of wood. You can't build skyscrapers or highways or particle accelerators out of wood, for those you need metal and concrete. A fairer analogy would be to say that OOP is a particular architectural style, and FP is another.
PaulDavisThe1st 6y ago
OOP is like Japanese woodworking: no screws, no nails, no glue. You can build beautiful things with it (though it requires great skill to do it correctly and accurately). You can mix Japanese woodworking with European woodworking by using screws, nails and glue whenever you feel like it. Its simpler than pure Japanese woodworking, not as pretty, quicker to construct, doesn't last as well. You can even forego Japanese woodworking entirely, but to do so is to throw away an entire culture's worth of knowledge about how to cut, shape and join wood, so likely not a great idea.

leafboi 6y ago

What if I told you that OOP only provides illusions of reuseable components and that most OOP components aren't really that reuseable. In order to build reuseable components you need components that compose well. Object composition does not allow for composition without specific glue code for each integration. For example: functions addOne and addTwo can compose to form addThree with a single general function composition operator, no glue code needed and no need for addOne or addTwo to be aware of each other. (addThree = addOne . addTwo) OneAdder and TwoAdder cannot compose without specific glue code or specific interface code to allow for DI. ThreeAdder = composeAdder(OneAdder, TwoAdder) would be implementation specific. Additionally ThreeAdder(TwoAdder, OneAdder) makes ThreeAdder aware of TwoAdder and OneAdder. These are not qualities of reuseability. The existence of a mutating object breaks reuseability. OOP does have it's use cases but the hate does comes from somewhere. One of the main downsides of OOP is the fact that current practices makes it one of the least reusable paradigms ever. DI and object composition are illusions. That being said it's not all that bad... not all business apps need the form of extreme reuseability that FP provides, so OOP is often good enough.

contravariant 6y ago
Don't end your class names with -er.
- leafboi 6y ago
  Naming is a superficial issue that is subjective as opposed to a structural problem that is pervasive. The point of the example wasn't to talk about naming. It was to talk about a fundamental structural problem with OOP.
  - PaulDavisThe1st 6y ago
    Clearly you are not familiar with the classic aphorism: "There are 2 hard problems in computer science: cache invalidation, and naming things" or its cousin: "There are 2 hard problems in computer science: cache invalidation, naming things and off-by-one errors".
6y ago

dnautics 6y ago

Every functional programming system I've worked in have been way more reusable than the OOP systems that I have worked in. It's just that the idioms for reusability are different, and even different between fps (julia uses multiple dispatch and elixir uses behaviours and protocols).

chongli 6y ago

I'm one of those people that dislike OOP. I would call it more of a Swiss army knife than a power drill. It's a complicated mashup of different tools, many of which are not very good. A lot of people don't seem to mind this though. I, personally, am a believer in minimalism. Features which experts tell beginners to avoid should be removed. That's very hard to do with programming languages that need to support legacy code though. So I always look for new programming languages that try to do things differently, with as few features as possible.

AnimalMuppet 6y ago
The problem is, if you remove the parts the experts tell beginners to avoid, then those parts are gone even when those beginners have become experts. Analogy: You talk to some master chefs. You tell them that the sharp knives are dangerous; they should get rid of them. They're going to tell you to get lost. The knives are valuable to them precisely because they are sharp. Sure, an amateur like me could seriously cut himself on one. So?
- chongli 6y ago
  Master chefs will tell you sharp knives are safer than dull ones because dull knives tend to slip instead of cutting. That’s been my experience too, as someone who loves to cook and keeps his knives sharp. I don’t think your analogy is appropriate though. My original analogy, the Swiss Army knife, conveys what I think is the core of the problem with OOP: it takes unrelated, powerful tools, and ties them together in a way that makes them unwieldy and more difficult to use. This problem is inherent to the object itself. It ties together unrelated concepts: polymorphism, data abstraction, mutable state, inheritance, and modules. Hence the Swiss Army knife analogy. Other languages (namely functional languages) give you all of these powerful tools but you get them separately, so they’re easier to control.
  - igouy 6y ago
    Master chefs have learned to keep their fingers away from the blade — sharp knives cut to the bone.

lmm 6y ago

Some tools are just bad. I've yet to find a case where OOP was actually better than not using OOP. (e.g. a library of reusable functions and datastructures is the best way to build a set of reusable components, in my experience).

dnautics 6y ago
I'm about as anti OOP as they come but I think this is uncharitable; There have been, historically, use cases where OOP was legitimately the best thing around. I think that it might be worth reconsidering on a few grounds: 1) performance bottlenecks are generally no longer CPU computation (network tends to dominate for many many things), and there is nonzero overhead to most functional operations. 2) coordination-free concurrency can in many cases often overcome computational bottlenecks, and non-OOP is far more effective for the code author in dealing with/grokking concurrency. 3) in the intervening time, functional patterns for some things (like UI) have been discovered which make fp a good fit for things that in the past were understandably the domain of OOP.