7 ms·

Object Oriented Programming Oversold (2001)

40 points by blowski 11y ago

exDM69 11y ago
Random quote from the article: > I will eat a week's pay if OOP is still in vogue in 2015. So, is it time to make the OP eat a week's pay or not? I'd say no.
- troels 11y ago
  I'd say yes. Pony up.
- Udik 11y ago
  Most of the "OOP" code I've seen recently is made mainly of static functions organized in classes with little or no state, instantiated and injected by a DI container in the name of flexibility. So I'd say that, in some sense, it's much less in vogue than it was fifteen years ago.
- w0utert 11y ago
  I'd say yes. Even though I agree with many of the points the article makes, OOP is still very pervasive, and I'm pretty sure it's still by far the most used development paradigm for most types of software. OOP may not be ideal or perfect, but OOP languages can be used to shoehorn almost any kind of problem into, which is exactly what people are still doing today. Often times producing a terrible mess that hardly works, but that's besides the point for his challenge ;-) Anyway, he makes many valid points, like other articles about the disadvantages of OOP, but none of these every draws any convincing conclusions why OOP is 'bad' and why something else would be 'better'. In programming there is no paradigm that fits every application, OOP is just one of many ways to solve problems, and one that has proven that (if used pragmatically) works very well for a very broad range of problems.
  - exDM69 11y ago
    Yes, I'm going to have to agree with this. OOP is just one paradigm. But what has changed from the years this article was written is that OOP is not touted a panacea. Back when I learned to code, OOP was a synonym for "good". That's why I'm saying no. OOP is no longer the hyped as it once was.
  - deleted 11y ago
    [deleted]
svdree 11y ago
I like the "split ends" analogy. A lot of developers seem to worry too much about issues that aren't actual problems, other than that something is "not OO". An actual example of this I saw recently, was when I got into an argument with someone over the use of standalone functions in C++. Apparently, these are evil, and functions should always be part of a class. Of course, a class with only static functions is basically a namespace. No problem, apparently statics are also evil. So let's not make these functions static, even though they're not accessing any member data. But now, when we want to use these functions, we need to instantiate an object, which is a bit silly. No problem, we'll just make it a singleton. I shit you not, this actually happened.
- JustSomeNobody 11y ago
  Once, I was using a struct for some simple data. I added a very simple member function to sanely format the data. I thought I was going to be hung in the code review for not using a "proper" class.
- troels 11y ago
  Singleton? No no, those are ALSO evil. No, we need to use a dependency injection container to provide that object instance.
- troels 11y ago
  Funny anecdote: I was recently contracting at a company that was OOP gone amuck. Everything written in Java ca. 2001 style. Lot's of message wrapping and unwrapping. Lots of dependency injection fun and games. At some point, their lead developer tells me about some guy they had for a job interview a while back, and as the story goes they had him through a code review where he was berated for using a static helper class. Apparently his reply was something like "You're using static classes for view helpers? But that's insane!". The morale of the story as told, was that clearly he didn't know right from wrong and was passed over. I didn't know what to reply to that.
  - arethuza 11y ago
    "Java ca. 2001 style" also seemed to include using every feature of J2EE even if it wasn't remotely relevant. Crazy files of constants seemed to feature a lot as well: public final static string HTTP = "HTTP"; public final static string COLON = ":"; public final static string SLASH = "/"; and then the inevitable: string url = HTTP + COLON + SLASH + SLASH....; [I did think about posting it to the DailyWTF at the time but thought that might be bad form when you are the lone contractor trying to rescue the project.]
mitsoz 11y ago
The article is pretty bad.
- GalacticDomin8r 11y ago
  Remember, you can only say nice things on HN. Blind agreement is ok, blind disagreement isn't.
shabbyrobe 11y ago
The section on "Cult Oriented Programming" is also still very relevant today. You could substitute "Smalltalk" for "React" and it still mostly makes sense. > ...a programmer's personal preference is more important to getting results than the language or paradigm itself. In other-words, if a programmer can work with the tools and languages that he or she most prefers, then productivity and quality may be much higher than from passing down edicts based on a blanket choice of tool, language, or paradigm. This backs up a lot of what I've seen over the years and I consider it wasteful in the extreme. Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)." Yeah, but this thing works just fine as it is. Your job is to improve it without making it worse for the next person, not Reactify it until you've exhausted somebody else's supply of money on a hunt for unicorns.
- sgt101 11y ago
  I'd codify this further with the view that subsituting one set of technical debt with another that fits with local trends and personal opinions is bad. The reasons to program in a particular fashion are as weak as "look how elegant that code is" appealing to the asthetic of the text and layout rather than any actual metric of clarity, reusability, interpribility or whatever. Goto considered evil is folk law when it comes down to it, I think it's almost universally believed but the fact that I don't immediately think of a crystal clear quantitative result to underpin the view that jumps in code are bad is telling. I think that some of what is going on here is economics though, coding in the new way gives a good line of patter for the next gig, and we all need to think about the next gig.
  - JustSomeNobody 11y ago
    Funny how GOTO is bad, but "break"ing out of a FOR loop is acceptable. The break is a very specific case of a GOTO.
    - mc808 11y ago
krylon 11y ago
I like OOP, basically. But as with all things in life, if one takes it too far, it quickly stops being fun. To think that a) all problems can and should be solved via OOP and that b) it is superior to other techniques (as if it was a competition or a fight) is foolish. To think that some program, that is designed in an object-oriented way, is inherently better than some other program that isn't, is - to a degree - like saying some athlete is better than another one because one wears yellow shoes and the other wears green shoes.
hacker_9 11y ago
How is this article front page HN news?? The GUI Link People think of gui elements as seperate objects (scrollbar, list, tree, textbox etc), so why is it a bad thing that the software also reasons about them as objects? Author just seems to want to hate OOP but offers no alternative: "There is more proof to the existence of UFO's than to OOP being the best way to do GUI's or any other programming topic." ??? Bait-and-Switch Author says here that training examples lure people into this idea of a perfect world that can be modeled easily with separate objects, but in real life projects this is not the case. But how is this any different from any language / paradigm we have today? Angular is often berated for example for being easy to get going with, but a PITA once the project becomes too big. It's a good thing examples introduce you to the strengths of the language, and then later you try to to fit the problem to those strengths. Land of Confusion "It has almost become like Particle Physics, in which only a small elite group appears to understand it properly, and everybody else needs years of meditation and practice." This is silly. Everything has a learning curve, but once you understand that everything exists inside an object you are good to go. The rest is just design patterns that are proven to make your life easier! Not Table-Friendly "OOP often does not map well to relational databases" Entity Framework for C# is used by businesses all over and shows this is possible, and easy to do. There are many other solutions to this as well. Melding Can Be Hazardous "How many times do different programming languages and systems have to share data? Very often in the real world. Thus, it is usually safer to keep large data pools separate from methods" What?? This makes no sense. If you need to share your data structures, then serialize your data to a text format and document it, for the next program to read. You could even provide an API. IDE support Well I've stopped reading by this point, but the author doesn't mention any advantages gained in the IDE. Specifically by using objects, the computer has more understanding of what I am doing, and can provide me: contextual autocomplete of members, and contextual documentation. Both invaluable for quickly getting up to speed with a new API, and making programming fun.
- fsloth 11y ago
  "This is silly. Everything has a learning curve, but once you understand that everything exists inside an object you are good to go. The rest is just design patterns that are proven to make your life easier!" Maybe it's just me but this is my main gripe with OO. I sometimes need to write involved data processing tasks and it's much simpler if I first think in graphs or through a relational model. The objects are light and either a way to encapsulate state (as in parser), a simple structure (as in a vector xyz) or a container. Complex data lives in relationships between the data - as opposed to 'encapsulating into an object' - this keeps the system small, easy to understand and modify. Sure, objects are a nice way to offer an interface to something but I've found the statement 'objects all the way down' usually means poor design. This gripe is of course mainly pedagogical - students (like I was, once) are exposed to a subotimal abstraction of software composition when objects are introduced as the way to design and implement software. Sure, they are nice in some places, I don't deny that.
nanoojaboo 11y ago
How does an article like this end up here now. Was someone browsing the way back machine?
pcunite 11y ago
I paraphrased one of his statements under the "Split Ends" heading: Advertisers take a small or imagined problem and magnify them to the point of irrational paranoia. Well said. And that is what is happening today in many forms. I'm under the impression that hiring managers (kids in their 30's) are totally irrational about skillsets because others don't know exactly what they think they should. There is paranoia about making a wrong hire to such a degree that they will most likely make the wrong hire! What you stare at, you steer for - Bob Goodnough
kabdib 11y ago
I like to tell people about the UCO or "Unencapsulated Composite Operation". It tends to win arguments over "global functions are evil". Say you have two classes, A and B. You have an operation that uses both of them. You can declare A::func(B) or B::func(A) but this couples the classes together. Yuckko. So you just make a global function, func(A, B). The function gets its job done using public methods, and the classes remain unaware of each other. That's the foot in the door. Then you whip multidispatch and CLOS on 'em and watch their eyes get real wide :-)
- arethuza 11y ago
  Move onto :before :round and :after methods - then finish with the joys of writing your own custom dispatch code. Leave a copy of AMOP as a going away present.
- lackbeard 11y ago
  Isn't coupling both A and B to the global func(A, B) just as bad as coupling B to A in A::func(B) or A to B B::func(A)? The thing you're trying to avoid with coupling is that when the dependency changes you might have to change the thing that depends on it, right? Isn't global func going to change with the same likelihood as A::func or B::func? I'm not sure if this is a relevant or not, (but since it relates to your post,) I do often find myself wishing I had multiple dispatch and/or some way to extend interfaces to existing types when programming in a language without those features.
  - kabdib 11y ago
    Not the same; you can use A independent of B, they are not coupled and you don't even need them both in the product. You're free to change the global func independent of the classes.
petke 11y ago
Thankfully the pendulum has swung back since the 90s. Stepanov, the inventor of STL (The C++ Standard Template Library) was the pioneer in avoidance of OO. It was truly revolutionary, and had such a huge influence on library design that today most modern C++ libraries are designed the same way. "STL is not object oriented. I think that object orientedness is [...] a hoax. I have yet to see an interesting piece of code that comes from these OO people. [...] I find OOP technically unsound. [...] I find OOP philosophically unsound. " http://www.stlport.org/resources/StepanovUSA.html http://www.stlport.org/resources/StepanovUSA.html

40 points by blowski 11y ago

Random quote from the article: > I will eat a week's pay if OOP is still in vogue in 2015. So, is it time to make the OP eat a week's pay or not? I'd say no.

troels 11y ago
I'd say yes. Pony up.
Udik 11y ago
Most of the "OOP" code I've seen recently is made mainly of static functions organized in classes with little or no state, instantiated and injected by a DI container in the name of flexibility. So I'd say that, in some sense, it's much less in vogue than it was fifteen years ago.
w0utert 11y ago
I'd say yes. Even though I agree with many of the points the article makes, OOP is still very pervasive, and I'm pretty sure it's still by far the most used development paradigm for most types of software. OOP may not be ideal or perfect, but OOP languages can be used to shoehorn almost any kind of problem into, which is exactly what people are still doing today. Often times producing a terrible mess that hardly works, but that's besides the point for his challenge ;-) Anyway, he makes many valid points, like other articles about the disadvantages of OOP, but none of these every draws any convincing conclusions why OOP is 'bad' and why something else would be 'better'. In programming there is no paradigm that fits every application, OOP is just one of many ways to solve problems, and one that has proven that (if used pragmatically) works very well for a very broad range of problems.
- exDM69 11y ago
  Yes, I'm going to have to agree with this. OOP is just one paradigm. But what has changed from the years this article was written is that OOP is not touted a panacea. Back when I learned to code, OOP was a synonym for "good". That's why I'm saying no. OOP is no longer the hyped as it once was.
- deleted 11y ago
  [deleted]

svdree 11y ago

I like the "split ends" analogy. A lot of developers seem to worry too much about issues that aren't actual problems, other than that something is "not OO". An actual example of this I saw recently, was when I got into an argument with someone over the use of standalone functions in C++. Apparently, these are evil, and functions should always be part of a class. Of course, a class with only static functions is basically a namespace. No problem, apparently statics are also evil. So let's not make these functions static, even though they're not accessing any member data. But now, when we want to use these functions, we need to instantiate an object, which is a bit silly. No problem, we'll just make it a singleton. I shit you not, this actually happened.

JustSomeNobody 11y ago
Once, I was using a struct for some simple data. I added a very simple member function to sanely format the data. I thought I was going to be hung in the code review for not using a "proper" class.
troels 11y ago
Singleton? No no, those are ALSO evil. No, we need to use a dependency injection container to provide that object instance.
troels 11y ago
Funny anecdote: I was recently contracting at a company that was OOP gone amuck. Everything written in Java ca. 2001 style. Lot's of message wrapping and unwrapping. Lots of dependency injection fun and games. At some point, their lead developer tells me about some guy they had for a job interview a while back, and as the story goes they had him through a code review where he was berated for using a static helper class. Apparently his reply was something like "You're using static classes for view helpers? But that's insane!". The morale of the story as told, was that clearly he didn't know right from wrong and was passed over. I didn't know what to reply to that.
- arethuza 11y ago
  "Java ca. 2001 style" also seemed to include using every feature of J2EE even if it wasn't remotely relevant. Crazy files of constants seemed to feature a lot as well: public final static string HTTP = "HTTP"; public final static string COLON = ":"; public final static string SLASH = "/"; and then the inevitable: string url = HTTP + COLON + SLASH + SLASH....; [I did think about posting it to the DailyWTF at the time but thought that might be bad form when you are the lone contractor trying to rescue the project.]

mitsoz 11y ago

The article is pretty bad.

GalacticDomin8r 11y ago
Remember, you can only say nice things on HN. Blind agreement is ok, blind disagreement isn't.

shabbyrobe 11y ago

The section on "Cult Oriented Programming" is also still very relevant today. You could substitute "Smalltalk" for "React" and it still mostly makes sense. > ...a programmer's personal preference is more important to getting results than the language or paradigm itself. In other-words, if a programmer can work with the tools and languages that he or she most prefers, then productivity and quality may be much higher than from passing down edicts based on a blanket choice of tool, language, or paradigm. This backs up a lot of what I've seen over the years and I consider it wasteful in the extreme. Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)." Yeah, but this thing works just fine as it is. Your job is to improve it without making it worse for the next person, not Reactify it until you've exhausted somebody else's supply of money on a hunt for unicorns.

sgt101 11y ago
I'd codify this further with the view that subsituting one set of technical debt with another that fits with local trends and personal opinions is bad. The reasons to program in a particular fashion are as weak as "look how elegant that code is" appealing to the asthetic of the text and layout rather than any actual metric of clarity, reusability, interpribility or whatever. Goto considered evil is folk law when it comes down to it, I think it's almost universally believed but the fact that I don't immediately think of a crystal clear quantitative result to underpin the view that jumps in code are bad is telling. I think that some of what is going on here is economics though, coding in the new way gives a good line of patter for the next gig, and we all need to think about the next gig.
- JustSomeNobody 11y ago
  Funny how GOTO is bad, but "break"ing out of a FOR loop is acceptable. The break is a very specific case of a GOTO.
  - mc808 11y ago

krylon 11y ago

I like OOP, basically. But as with all things in life, if one takes it too far, it quickly stops being fun. To think that a) all problems can and should be solved via OOP and that b) it is superior to other techniques (as if it was a competition or a fight) is foolish. To think that some program, that is designed in an object-oriented way, is inherently better than some other program that isn't, is - to a degree - like saying some athlete is better than another one because one wears yellow shoes and the other wears green shoes.

hacker_9 11y ago

How is this article front page HN news?? The GUI Link People think of gui elements as seperate objects (scrollbar, list, tree, textbox etc), so why is it a bad thing that the software also reasons about them as objects? Author just seems to want to hate OOP but offers no alternative: "There is more proof to the existence of UFO's than to OOP being the best way to do GUI's or any other programming topic." ??? Bait-and-Switch Author says here that training examples lure people into this idea of a perfect world that can be modeled easily with separate objects, but in real life projects this is not the case. But how is this any different from any language / paradigm we have today? Angular is often berated for example for being easy to get going with, but a PITA once the project becomes too big. It's a good thing examples introduce you to the strengths of the language, and then later you try to to fit the problem to those strengths. Land of Confusion "It has almost become like Particle Physics, in which only a small elite group appears to understand it properly, and everybody else needs years of meditation and practice." This is silly. Everything has a learning curve, but once you understand that everything exists inside an object you are good to go. The rest is just design patterns that are proven to make your life easier! Not Table-Friendly "OOP often does not map well to relational databases" Entity Framework for C# is used by businesses all over and shows this is possible, and easy to do. There are many other solutions to this as well. Melding Can Be Hazardous "How many times do different programming languages and systems have to share data? Very often in the real world. Thus, it is usually safer to keep large data pools separate from methods" What?? This makes no sense. If you need to share your data structures, then serialize your data to a text format and document it, for the next program to read. You could even provide an API. IDE support Well I've stopped reading by this point, but the author doesn't mention any advantages gained in the IDE. Specifically by using objects, the computer has more understanding of what I am doing, and can provide me: contextual autocomplete of members, and contextual documentation. Both invaluable for quickly getting up to speed with a new API, and making programming fun.

fsloth 11y ago
"This is silly. Everything has a learning curve, but once you understand that everything exists inside an object you are good to go. The rest is just design patterns that are proven to make your life easier!" Maybe it's just me but this is my main gripe with OO. I sometimes need to write involved data processing tasks and it's much simpler if I first think in graphs or through a relational model. The objects are light and either a way to encapsulate state (as in parser), a simple structure (as in a vector xyz) or a container. Complex data lives in relationships between the data - as opposed to 'encapsulating into an object' - this keeps the system small, easy to understand and modify. Sure, objects are a nice way to offer an interface to something but I've found the statement 'objects all the way down' usually means poor design. This gripe is of course mainly pedagogical - students (like I was, once) are exposed to a subotimal abstraction of software composition when objects are introduced as the way to design and implement software. Sure, they are nice in some places, I don't deny that.

nanoojaboo 11y ago

How does an article like this end up here now. Was someone browsing the way back machine?

pcunite 11y ago

I paraphrased one of his statements under the "Split Ends" heading: Advertisers take a small or imagined problem and magnify them to the point of irrational paranoia. Well said. And that is what is happening today in many forms. I'm under the impression that hiring managers (kids in their 30's) are totally irrational about skillsets because others don't know exactly what they think they should. There is paranoia about making a wrong hire to such a degree that they will most likely make the wrong hire! What you stare at, you steer for - Bob Goodnough

kabdib 11y ago

I like to tell people about the UCO or "Unencapsulated Composite Operation". It tends to win arguments over "global functions are evil". Say you have two classes, A and B. You have an operation that uses both of them. You can declare A::func(B) or B::func(A) but this couples the classes together. Yuckko. So you just make a global function, func(A, B). The function gets its job done using public methods, and the classes remain unaware of each other. That's the foot in the door. Then you whip multidispatch and CLOS on 'em and watch their eyes get real wide :-)

arethuza 11y ago
Move onto :before :round and :after methods - then finish with the joys of writing your own custom dispatch code. Leave a copy of AMOP as a going away present.
lackbeard 11y ago
Isn't coupling both A and B to the global func(A, B) just as bad as coupling B to A in A::func(B) or A to B B::func(A)? The thing you're trying to avoid with coupling is that when the dependency changes you might have to change the thing that depends on it, right? Isn't global func going to change with the same likelihood as A::func or B::func? I'm not sure if this is a relevant or not, (but since it relates to your post,) I do often find myself wishing I had multiple dispatch and/or some way to extend interfaces to existing types when programming in a language without those features.
- kabdib 11y ago
  Not the same; you can use A independent of B, they are not coupled and you don't even need them both in the product. You're free to change the global func independent of the classes.

petke 11y ago

Thankfully the pendulum has swung back since the 90s. Stepanov, the inventor of STL (The C++ Standard Template Library) was the pioneer in avoidance of OO. It was truly revolutionary, and had such a huge influence on library design that today most modern C++ libraries are designed the same way. "STL is not object oriented. I think that object orientedness is [...] a hoax. I have yet to see an interesting piece of code that comes from these OO people. [...] I find OOP technically unsound. [...] I find OOP philosophically unsound. " http://www.stlport.org/resources/StepanovUSA.html http://www.stlport.org/resources/StepanovUSA.html