5 ms·

Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! All things are an instantiation of a class!

by delinka 10y ago

Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! All things are an instantiation of a class! All things must derive from a root class! etc."? OOP is a tool. And generally a useful one. Every new programming paradigm at its inception was going to Save The World and make programming A Better Place. Turns out, every one if these paradigms is a tool with uses at various times. So OOP might only be useful in a limited number of cases. I find it comfortable for categorizing functions: "Here's all the stuff you can do with a String" or "All windows behave like this..." And if your language is dynamic enough, you can add functionality to all Strings, not just your String subclass. I don't typically find OOP useful for processing many records of data. Perhaps I might compose an object from a record of data so that a user might edit their profile in a GUI, but batch processing doesn't usually lend itself to OOP. But that's my experience and opinion; I bet someone has a good use case for using OOP while dealing with copious amounts of data. Back to the topic at hand: Was OOP a failure? No more than lathes are failures. Not every handyman needs a lathe; not every programmer needs OOP. But when you do need it, it's a useful tool.

gpderetta 10y ago
Exactly. "Everything is an object" was an extremism (today's extremism is the crusade against 'mutable state'), but otherwise OoO has been useful. For example it has seen great success in GUIs.
- marktangotango 10y ago
  If you're creating final immutable everything in Java using effective Java chapter 1 immutable objects, sorry but you have the wrong language for the job. Even with Java 8 Optional and Lombok annotations, it opens a can of worms. What is optional and what are sensible defaults for non optional value? These are often non trivial questions in legacy code bases.
  - eveningcoffee 10y ago
    And yet Clojure immutable datatypes were written in Java.
- fpoling 10y ago
  I can definitely state that OOP allows to implement GUI. But "great success" I can see only for vendors selling OOP tools for GUI development. Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. Or consider QT. My colleagues with a lot of QT experience use QML to create GUI. They avoid any C++ GUI code unless it is really a must.
  - watwut 10y ago
    React itself does much less then what component oriented oop frameworks used to do. Achieving same functionality with react is more work. They were not on the Web tho, so the comparison is a bit weird.
    - zzzzzzzza 10y ago
      "achieving same functionality is more work" this is part of the advantage of react (and fp in general over oo). you don't need to incorporate an entire object to use a single extra function. The increased modularity also allows you to spread the maintenance burden of the project over a much larger community.
  - coldtea 10y ago
    >Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. That's because there are no decent OO based web UIs, because the web development experience and stack is a total mess to begin with.
    - Pxtl 10y ago
      The web UI objects, with their collection of global namespaces for IDs, Classes, JavaScript functions, etc., are aggressively resistant to compontentization. You can see the disastrous implications of this feature with the ID mangling needed for Asp.net webforms, and the utterly miserable workflow that creates.
    - 10y ago
- deleted 10y ago
  [deleted]
thehardsphere 10y ago
> Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! All things are an instantiation of a class! All things must derive from a root class! etc."? Because there are many low skill, poorly-informed people who write code still believe these things. In particular that "OOP" is automatically equivalent to "better quality code." It’s a sort of cargo cultism that is present in a few places.
- aaron-lebo 10y ago
  Indeed, but what is more disappointing are the high-skilled, well-informed people who believe these things. In particular that "functional" is automatically equivalent to "better quality code". It's dogma either way. There is no single true religion just advantages and disadvantages
- shadowmint 10y ago
  The irony is that it probably does mean better quality code for most people. Quality in practical outcomes for building projects, that is, not code asthetics. The problem is that 'functional code' means 'spagetti code' for many 'low skill' people, and 'write once maintain never' perl style code for many other 'smart' people. Both are rubbish, terrible low quality useless code outcomes. OOP doesn't fix everything, but its a great lowest common demoninator for code that does the job. Its not exciting. It has stateful bugs. ...but anyone can do it and it gets the job done at scale; orders of magnitude better than any other coding paradigm I'm aware of. You want a hard problem to solve? Go figure out a way to make functional programming scale the same way, you'll start a revolution. ...but in my experience, its the frustrated 'smart' folk who want to write their maintain-never code who push FP as a replacement for OOP.
  - Buttons840 10y ago
    > The problem is that 'functional code' means 'spagetti code' for many 'low skill' people I don't see how that is the case. Even in the most poorly written function you have code that's working mostly on it's arguments (and maybe some global or something, since it is poorly written) and then returns a value. How is this function connected to the surrounding code? We know the answer, it's called in a single expression and given arguments. You have a single isolated call for a single run of the function. In OOP you have to both instantiate a class and then call it's methods. By simple line count it is twice as complicated to call as a function, and it is twice as coupled to the code that calls it. When I look into the internals of functional code I often find myself in a single isolated function and the functions tend to be on the short side. When I look into the internals of OOP code I often find myself in a large method that is part of a class in an inheritance hierarchy and the method uses a bunch of globals (err, I mean "object variables") and I have to read several other methods to understand what's happening, because the method I'm interested in depends on the state left over from other method calls. In short, objects are a lot more powerful than functions, and thus "low skill" developers have a lot more rope to make spaghetti with.
naasking 10y ago
> So OOP might only be useful in a limited number of cases. I find it comfortable for categorizing functions: "Here's all the stuff you can do with a String" or "All windows behave like this..." That's a module. This scope creep is part of the problem with OOP, as it slowly encompasses features that are orthogonal to their main purpose. OOP is mainly about procedural abstraction: any type implementing a protocol (set of methods) should be indistinguishable from any other type that implements that same protocol. This enables the open extension that characterizes OOP. So amending your statement to make it truly about objects, "here's all the stuff you can do with String-like values".
- eveningcoffee 10y ago
  One of the core principles of the OOP is encapsulation - your object does not appear in inconsistent state to the outside world. So in sense of the OOP, object methods are all the functions that can have access to the internal state. Naturally you can do the same in FP with modules, but honestly, how different it is from OOP then (considering that you can use some form of polymorphism)? For me OOP and FP stand for abstract concepts, not as specific languages.
  - naasking 10y ago
    > One of the core principles of the OOP is encapsulation - your object does not appear in inconsistent state to the outside world. This is not a defining feature of OOP, because it's a characteristic of abstract data types which predate OO. William Cook managed to distill the essence quite clearly I think [1]. [1] http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
charles-salvia 10y ago
People sometimes think that OOP means "OOP or Nothing!" probably because of the popularity of languages that enforce such a mentality (i.e. basically because Java).
erikpukinskis 10y ago
> Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! Well, that's what the OP in OOP means. It means you are oriented towards objects, and away from everything else. What's the difference between writing a test and doing TDD? In TDD the tests are the center of your universe. Plus there's the fact that "Everything is an Object" was a very common slogan for OOP. Of course you can write non-objects in your object oriented code... An object is made of non-objects! But OOP means when you are asking architecture questions you sort out your names and your methods first, and functions fill in the gaps. Compare to (old school) JavaScript where everything is a function to start, and you add prototypes and methods only when you really need them. (RIP JavaScript, long live OOP/ES6)
- pjmlp 10y ago
  Old school JavaScript was already OOP, given that prototype inheritance comes from Self, which was OOP.
jt2190 10y ago
> OOP is a tool. And generally a useful one. OOP is also a tool that others have used to build things that many of us use all the time (I'm looking at you DOM API and CSS) so it's difficult to truly escape from OOP. You may never like it, but learning it will deepen your understanding of many other tools.
ljw1001 10y ago
Because straw men make the best targets

by delinka 10y ago

gpderetta 10y ago

Exactly. "Everything is an object" was an extremism (today's extremism is the crusade against 'mutable state'), but otherwise OoO has been useful. For example it has seen great success in GUIs.

marktangotango 10y ago
If you're creating final immutable everything in Java using effective Java chapter 1 immutable objects, sorry but you have the wrong language for the job. Even with Java 8 Optional and Lombok annotations, it opens a can of worms. What is optional and what are sensible defaults for non optional value? These are often non trivial questions in legacy code bases.
- eveningcoffee 10y ago
  And yet Clojure immutable datatypes were written in Java.
fpoling 10y ago
I can definitely state that OOP allows to implement GUI. But "great success" I can see only for vendors selling OOP tools for GUI development. Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. Or consider QT. My colleagues with a lot of QT experience use QML to create GUI. They avoid any C++ GUI code unless it is really a must.
- watwut 10y ago
  React itself does much less then what component oriented oop frameworks used to do. Achieving same functionality with react is more work. They were not on the Web tho, so the comparison is a bit weird.
  - zzzzzzzza 10y ago
    "achieving same functionality is more work" this is part of the advantage of react (and fp in general over oo). you don't need to incorporate an entire object to use a single extra function. The increased modularity also allows you to spread the maintenance burden of the project over a much larger community.
- coldtea 10y ago
  >Consider web frameworks. Given a choice I select React and similar functional frameworks than OOP based ones. They are just more productive and scale better. That's because there are no decent OO based web UIs, because the web development experience and stack is a total mess to begin with.
  - Pxtl 10y ago
    The web UI objects, with their collection of global namespaces for IDs, Classes, JavaScript functions, etc., are aggressively resistant to compontentization. You can see the disastrous implications of this feature with the ID mangling needed for Asp.net webforms, and the utterly miserable workflow that creates.
  - 10y ago
deleted 10y ago
[deleted]

thehardsphere 10y ago

> Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! All things are an instantiation of a class! All things must derive from a root class! etc."? Because there are many low skill, poorly-informed people who write code still believe these things. In particular that "OOP" is automatically equivalent to "better quality code." It’s a sort of cargo cultism that is present in a few places.

aaron-lebo 10y ago
Indeed, but what is more disappointing are the high-skilled, well-informed people who believe these things. In particular that "functional" is automatically equivalent to "better quality code". It's dogma either way. There is no single true religion just advantages and disadvantages
shadowmint 10y ago
The irony is that it probably does mean better quality code for most people. Quality in practical outcomes for building projects, that is, not code asthetics. The problem is that 'functional code' means 'spagetti code' for many 'low skill' people, and 'write once maintain never' perl style code for many other 'smart' people. Both are rubbish, terrible low quality useless code outcomes. OOP doesn't fix everything, but its a great lowest common demoninator for code that does the job. Its not exciting. It has stateful bugs. ...but anyone can do it and it gets the job done at scale; orders of magnitude better than any other coding paradigm I'm aware of. You want a hard problem to solve? Go figure out a way to make functional programming scale the same way, you'll start a revolution. ...but in my experience, its the frustrated 'smart' folk who want to write their maintain-never code who push FP as a replacement for OOP.
- Buttons840 10y ago
  > The problem is that 'functional code' means 'spagetti code' for many 'low skill' people I don't see how that is the case. Even in the most poorly written function you have code that's working mostly on it's arguments (and maybe some global or something, since it is poorly written) and then returns a value. How is this function connected to the surrounding code? We know the answer, it's called in a single expression and given arguments. You have a single isolated call for a single run of the function. In OOP you have to both instantiate a class and then call it's methods. By simple line count it is twice as complicated to call as a function, and it is twice as coupled to the code that calls it. When I look into the internals of functional code I often find myself in a single isolated function and the functions tend to be on the short side. When I look into the internals of OOP code I often find myself in a large method that is part of a class in an inheritance hierarchy and the method uses a bunch of globals (err, I mean "object variables") and I have to read several other methods to understand what's happening, because the method I'm interested in depends on the state left over from other method calls. In short, objects are a lot more powerful than functions, and thus "low skill" developers have a lot more rope to make spaghetti with.

naasking 10y ago

> So OOP might only be useful in a limited number of cases. I find it comfortable for categorizing functions: "Here's all the stuff you can do with a String" or "All windows behave like this..." That's a module. This scope creep is part of the problem with OOP, as it slowly encompasses features that are orthogonal to their main purpose. OOP is mainly about procedural abstraction: any type implementing a protocol (set of methods) should be indistinguishable from any other type that implements that same protocol. This enables the open extension that characterizes OOP. So amending your statement to make it truly about objects, "here's all the stuff you can do with String-like values".

eveningcoffee 10y ago
One of the core principles of the OOP is encapsulation - your object does not appear in inconsistent state to the outside world. So in sense of the OOP, object methods are all the functions that can have access to the internal state. Naturally you can do the same in FP with modules, but honestly, how different it is from OOP then (considering that you can use some form of polymorphism)? For me OOP and FP stand for abstract concepts, not as specific languages.
- naasking 10y ago
  > One of the core principles of the OOP is encapsulation - your object does not appear in inconsistent state to the outside world. This is not a defining feature of OOP, because it's a characteristic of abstract data types which predate OO. William Cook managed to distill the essence quite clearly I think [1]. [1] http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

charles-salvia 10y ago

People sometimes think that OOP means "OOP or Nothing!" probably because of the popularity of languages that enforce such a mentality (i.e. basically because Java).

erikpukinskis 10y ago

> Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! Well, that's what the OP in OOP means. It means you are oriented towards objects, and away from everything else. What's the difference between writing a test and doing TDD? In TDD the tests are the center of your universe. Plus there's the fact that "Everything is an Object" was a very common slogan for OOP. Of course you can write non-objects in your object oriented code... An object is made of non-objects! But OOP means when you are asking architecture questions you sort out your names and your methods first, and functions fill in the gaps. Compare to (old school) JavaScript where everything is a function to start, and you add prototypes and methods only when you really need them. (RIP JavaScript, long live OOP/ES6)

pjmlp 10y ago
Old school JavaScript was already OOP, given that prototype inheritance comes from Self, which was OOP.

jt2190 10y ago

> OOP is a tool. And generally a useful one. OOP is also a tool that others have used to build things that many of us use all the time (I'm looking at you DOM API and CSS) so it's difficult to truly escape from OOP. You may never like it, but learning it will deepen your understanding of many other tools.

ljw1001 10y ago

Because straw men make the best targets