'If Everyone Hates Object-Oriented Programming, Why Is It Still So Widely Spread?' (stackoverflow.blog) 386
Object-oriented programming "has been wildly successful. But was the success just a coincidence?" asks Stack Overflow's blog:
Asking why so many widely-used languages are OOP might be mixing up cause and effect. Richard Feldman argues in his talk that it might just be coincidence. C++ was developed in the early 1980s by Bjarne Stroustrup, initially as a set of extensions to the C programming language. Building on C , C++ added object orientation but Feldman argues it became popular for the overall upgrade from C including type-safety and added support for automatic resource management, generic programming, and exception handling, among other features.
Then Java wanted to appeal to C++ programmers and doubled down on the OOP part. Ultimately, Sun Microsystems wanted to repeat the C++ trick by aiming for greatest familiarity for developers adopting Java. Millions of developers quickly moved to Java due to its exclusive integration in web browsers at the time. Seen this way, OOP seems to just be hitching a ride, rather than driving the success.
While acknowledging OOP cornerstones like encapsulation, inheritance, polymorphism, the article still takes a skeptical stance. "Seems like in 2020, there is not so much that OOP can do that other programming paradigms cannot, and a good programmer will use strategies from multiple paradigms together in the battle against complexity."
Then Java wanted to appeal to C++ programmers and doubled down on the OOP part. Ultimately, Sun Microsystems wanted to repeat the C++ trick by aiming for greatest familiarity for developers adopting Java. Millions of developers quickly moved to Java due to its exclusive integration in web browsers at the time. Seen this way, OOP seems to just be hitching a ride, rather than driving the success.
While acknowledging OOP cornerstones like encapsulation, inheritance, polymorphism, the article still takes a skeptical stance. "Seems like in 2020, there is not so much that OOP can do that other programming paradigms cannot, and a good programmer will use strategies from multiple paradigms together in the battle against complexity."
Who hates OOP? (Score:5, Insightful)
Seriously. Apart from self-righteous know-it-all contrarians, who hates OOP?
Re: Who hates OOP? (Score:5, Insightful)
I've definitely never met any programmers that I'd consider competent who hate OOP.
It is the most elegant, useful paradigm I know of for organised logical development, and as a bonus lends itself to code reuse.
Re: Who hates OOP? (Score:5, Insightful)
Object oriented design is one perspective on the world. But it's not always the best way to solve a problem.
If you break down a total solution you can do that in different perspectives. Either follow the object oriented structure totally or look at it from the perspective of information flows. Two different information flows may then seem like they are in need of the same object, so you just link in that object in those two information flows, which makes these information flows interdependent, even if they shouldn't be.
Interdependent information flows can be a minor issue on non critical systems, but when you start to look at mission critical systems it can lead to a headache. Like when you work with ISO 26262, then you are starting to get interesting domino effects. Assume that you have pressure sensors for brake and pressure sensors for fuel pressure. Then in the object model you decide to use the same object "pressure sensor" for both. However then there's an update for the sensor logic due to emissions regulations where the sensor object is changed, that would then impact the brake system and suddenly you end up in a situation where you need to do a re-certification of the brake system and get it approved.
I think that you might get the point here that object model isn't always the best way to go when you want to avoid cross-dependencies. A hybrid solution is often preferable even if it might look like you have code duplication.
Re: Who hates OOP? (Score:5, Interesting)
Object oriented design is one perspective on the world. But it's not always the best way to solve a problem.
If you break down a total solution you can do that in different perspectives. Either follow the object oriented structure totally or look at it from the perspective of information flows. Two different information flows may then seem like they are in need of the same object, so you just link in that object in those two information flows, which makes these information flows interdependent, even if they shouldn't be.
Interdependent information flows can be a minor issue on non critical systems, but when you start to look at mission critical systems it can lead to a headache. Like when you work with ISO 26262, then you are starting to get interesting domino effects. Assume that you have pressure sensors for brake and pressure sensors for fuel pressure. Then in the object model you decide to use the same object "pressure sensor" for both. However then there's an update for the sensor logic due to emissions regulations where the sensor object is changed, that would then impact the brake system and suddenly you end up in a situation where you need to do a re-certification of the brake system and get it approved.
I think that you might get the point here that object model isn't always the best way to go when you want to avoid cross-dependencies. A hybrid solution is often preferable even if it might look like you have code duplication.
What you are basically saying is that if you have, say a network client object, or something else that you are re-using, one fix for one problem in that object might cause bugs in multiple independent software products because because the code is re-used in all of them. On the other hand if you don't use OOP and don't share code, it doesn't just look like you have code duplication, you will have code duplication and that brings its own hellscape of development problems. The way to solve this is with automated unit testing which brings us to the problem that most developers don't like writing test cases and managers definitely don't like quality assurance in general, especially on 'mature products'. They like drawing the magic cost cutting sword from the sacred magical stone in the courtyard of Castle Profit, swinging it over their head while shouting 'By the Power profit, I have the power' which is how you get the Boeing 737 MAX.
Re: (Score:3, Informative)
Object oriented design is one perspective on the world. But it's not always the best way to solve a problem.
If you break down a total solution you can do that in different perspectives. Either follow the object oriented structure totally or look at it from the perspective of information flows. Two different information flows may then seem like they are in need of the same object, so you just link in that object in those two information flows, which makes these information flows interdependent, even if they shouldn't be.
Interdependent information flows can be a minor issue on non critical systems, but when you start to look at mission critical systems it can lead to a headache. Like when you work with ISO 26262, then you are starting to get interesting domino effects. Assume that you have pressure sensors for brake and pressure sensors for fuel pressure. Then in the object model you decide to use the same object "pressure sensor" for both. However then there's an update for the sensor logic due to emissions regulations where the sensor object is changed, that would then impact the brake system and suddenly you end up in a situation where you need to do a re-certification of the brake system and get it approved.
I think that you might get the point here that object model isn't always the best way to go when you want to avoid cross-dependencies. A hybrid solution is often preferable even if it might look like you have code duplication.
What you are basically saying is that if you have, say a network client object, or something else that you are re-using, one fix for one problem in that object might cause bugs in multiple independent software products because because the code is re-used in all of them. On the other hand if you don't use OOP and don't share code, it doesn't just look like you have code duplication, you will have code duplication and that brings its own hellscape of development problems. The way to solve this is with automated unit testing which brings us to the problem that most developers don't like writing test cases and managers definitely don't like quality assurance in general, especially on 'mature products'. They like drawing the magic cost cutting sword from the sacred magical stone in the courtyard of Castle Profit, swinging it over their head while shouting 'By the Power profit, I have the power' which is how you get the Boeing 737 MAX.
You would still need to re-certify the system... Automated testing will not change that.
Who wants to laugh at OOP? (Score:3)
Somewhat disappointed by the lack of humor in the large discussion, but the best I can do is the obligatory joke:
How do you shoot yourself in the foot using C++?
You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical care is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying "that's me, over there."
https://www-users.cs.york.ac.u... [york.ac.uk]
http://www.toodarkpark.org/com... [toodarkpark.org]
Re: Who hates OOP? (Score:5, Insightful)
That bears repeating. The software on the 737MAX performed exactly as designed. The problem is in the design itself.
Re: (Score:3)
The software in the 737 MAX was faulty be design, especially relying on one sensor only and not retraining the pilot. It most certainly had unit tests, that covered every thinkable software error.
...except the thinkable and rather bloody obvious software error that occurs when you cut the single sensor feed or make it go haywire in some other way known to have happened before such as incorrect AOA sensor input being transmitted to the flight control computers. Then you observe the effect that has on the aircraft's software and systems and check whether or not incorrect AOA sensor input causes the aircraft to fly into the ground. Contrary to what Boeing managers used to believe, even 'mature products
Re: (Score:3, Informative)
Code re-use does not require OOP.
Re: Who hates OOP? (Score:4, Insightful)
Re: Who hates OOP? (Score:4, Interesting)
Here's my development path:
6 years old -- started programming (BASIC)
8 years old -- LOGO
10 years old -- Turbo Pascal, Assembly
12 years old -- C
14 years old -- C++ -- at this point, OOP was mainly what I was doing
18 years old -- College (HMC), SML-NJ, REX, and heaps more of C++ -- as you say, OOP was highly built up, at college, too
21 years old -- Python, Objective-C, E-Lisp, JavaScript, SQL; detailed study of GoF, Design Patterns, etc.,.
I consider this my "learning the basics" period.
By the time I was 30, I was studying Alan Kay, Douglas Engelbart, and Chuck Moore. I began studying Forth, APL, REBOL, and various other notational systems for programming. I was able to program things I had never been able to program before, and with a freedom I had never had before, by studying things in terms of complete strategic systems, rather than as assemblages of objects. I had seen superior power gains from the study of notation, rather than the dogmatic assertions (and empty promises) of OOP.
Now I am in my 40s. When I write programs, I start by thinking of the complete system, and what notations can render that system functional. I take more inspiration from the design of embedded systems rather than object oriented programming examples. I spend more time listening to Bret Victor, or reading papers by dead people (or people soon to be dead,) than university coursework. If Rob Pike has something to say, I'll listen. But if someone's younger than 30, why bother.
Re: Who hates OOP? (Score:5, Insightful)
Re: Who hates OOP? (Score:2)
Re: Who hates OOP? (Score:5, Insightful)
If you seriously think the win32 API is good in any way, you should not be working in software development.
Re: (Score:3)
Fortunately popularity is not any kind of requirement for an API. Personally I only code with the supergoodthatnoonehasheardof API. You probably have used some of my software like the correctly named Shitnoonegivesabout. I mean only dealing with "good" APIs is how you become a popular software god like me.
Re: Who hates OOP? (Score:4, Interesting)
I'd argue that the Windows GUI API *is* object oriented. How else would you describe window classes, WndProc's, message passing, GDI objects, etc? Windows just does it with C rather than an OO programming language. Win32 is just Win16 on steroids, and Win16 was designed in the early 1980's. IMHO, the Windows GUI API design (USER and GDI) has held up remarkably well after 35+ years.
P.S. I'm choosing my words carefully. Windows has many moving parts, of which the GUI API is just one piece. Some of the other parts turned out to be Really Bad Ideas, but that doesn't detract from the GUI API design.
Re: (Score:3)
win32 is mostly an OO framework writing in a procedural language. Those HANDLEs that are ubiquitous are the object pointers, the function calls that take them as an argument are the methods. This was a very common style of C programming and essentially what the first versions of C++ were (when it was just a preprocessor).
Re: (Score:2)
Assume that you have pressure sensors for brake and pressure sensors for fuel pressure. Then in the object model you decide to use the same object "pressure sensor" for both. However then there's an update for the sensor logic due to emissions regulations where the sensor object is changed, that would then impact the brake system and suddenly you end up in a situation where you need to do a re-certification of the brake system and get it approved.
You do have to keep track of what's downstream logically, but you have to do that no matter what model you use. It doesn't matter whether you get that data from an object or not.
Re: (Score:3)
What I'm saying is that if you have separate code base for brake system and for fuel system then you will only have to re-validate and re-certify the functionality area that changed. And what I did write was if I with the "perfect" OO model then if I change the pressure sensor code I need to re-certify both the brake and fuel system. With separate pressure sensor code it's only one system that has to be re-certified.
The reality is that every vehicle on the road is built that way - with many computers networ
Re: (Score:3)
That has nothing to do with OO.
Your brake will run "PreasureSensor.cpp - revision 3.1.4" and your fuel system will run "PreasureSensor.cpp - resision 1.1", like it does since 30 years.
(* facepalm *)
Re: (Score:3)
I have spent 9 years in truck development, so I'm entirely speaking from experience there, the number of possible option combinations on heavy trucks are so great that you can only see them as open ended systems and only test select combinations.
Re: (Score:3)
Let me introduce you to the concept of bean counters trying to save money by cutting down on testing.
Re: Who hates OOP? (Score:5, Insightful)
When I see the SOLID principles I also see that they are open for a lot of interpretation even if those that swear by them don't think so.
But the worst part of the SOLID principle is the statement "depend upon abstractions, [not] concretions.". As soon as you make an abstraction instead of a concretion you will open up for a can of worms of interpretation. E.g. if you use "Energy" instead of "Fuel" or even more specific "Diesel Fuel" then you have suddenly created a fog in the system because the term "Energy" is interpreted in different ways depending on who's actually reading it. Abstractions introduced by an architect works passable as long as the architect is in place, but as soon as the architect leaves for another assignment things goes properly down the drain because a new architect have a completely different view and the developers are also misinterpreting the intent of both architects.
I have been there and seen all that crap, and it's something you see in large organizations spread out over multiple sites worldwide.
So call a spade a spade and an axe an axe and people in general will understand the design much better.
Overall I see that Object Oriented Design done wrong is one of the worst things that you can do in a project. And that happens when the architects don't understand what the product really is but are getting lost in the forest of abstractions.
Re: (Score:3)
It has real risks. For example, the idea that the "lower levels" are irrelevant to performance or security can lead to stunning inefficiencies and dangerous exposure that a typical "object oriented" programmer won't even consider.
Re: (Score:2)
There are various opinions about this from competent people https://www.youtube.com/watch?... [youtube.com]
Re:Who hates OOP? (Score:4, Insightful)
Re:Who hates OOP? (Score:5, Interesting)
Guido Van Rossum? Who invented Python? Why is Python fully OOP then?
Please provide a reference for this statement.
Re: (Score:2)
Re: Who hates OOP? (Score:3, Insightful)
Re: Who hates OOP? (Score:5, Interesting)
No, it is not OO (objet oriented).
It is OB (object based).
If you keep mixing that up you will have problems passing a written test in an university.
Re: Who hates OOP? (Score:4, Interesting)
"Method access modifier" is not a prerequisite for calling it OOP.
OOP is the defined storage and manipulation of state at the smallest possible level - a single resource, for instance, and preferably. Nothing more, nothing less. Everything - encapsulation, inheritance, access methods etc is just a consequence of that in the (sometimes misguided) attempt to use the paradigm to its full potential.
Alternativr methods are, for example, functional systems where you strive to have no state at all. Or data-centric methods, where you have one big (vector-like) data blob and lots of modifier methods (e.g. shaders). Or procedural/imperative, where you essentially center on telling the computer what to do instead of what to do it to (think: shell script) In the latter case you still haven't solved the problem of your data model, though, and you still might end upnwith a solid OOP design for fairly large projects; that, or it's spaghetti time.
Re: (Score:2)
Re: (Score:3)
I am not hacking my own program, why do I need object to be protected from other code
For a small/short-term project, you don't.
Once you've worked on a long-term project that keeps changing or growing larger over time, you'll find out why -- the overall complexity of your program is proportional to the number of direct interactions between components, and as the number of components in your program grows, the complexity of a program where any component has direct access to any other component will grow with by a factor of N^2 (where N is the number of components in the program).
Needless to
Re:Who hates OOP? (Score:4, Informative)
Linus is anti C++, not anti OOP. There are many cases in the kernel where a pointer to a struct is passed around explicitly in almost exactly the way C++ would pass around a this pointer. There are places where exception handling exists (implemented in C with a bit of ASM). The OOP is explicit and layer cakes are avoided, but it is object oriented.
Python is very much object oriented. It is done in a different way than C++ does it, and due to duck typing, it is in many ways far more versatile. It is solidly within the class of object oriented. So I would say count Guido as pro-OO but not necessarily a C++ fan (Given that the most popular Python is implemented in C).
Re: (Score:2, Insightful)
Game engine programmers - and not your garden variety indie artsy types, either.
But to generalize - basically anyone for whom indirection and cache misses can be considered a problem.
Re:Who hates OOP? (Score:5, Insightful)
Linus for one. A lot of embedded people don't like it either. It's just not suited to that kind of work.
For a start most of the nice features are unusable. You can't rely on it for memory management and in embedded you want to avoid any kind of dynamic allocation at all. You can make use of some of the organizational features which can be nice, but particularly with C++ you also lose a lot of useful functionality because it's been deprecated in the same of safety. Even forcing some things to be errors like not being completely explicit about your type punning in C++ causes a massive amount code cruft that actually makes it less readable.
Re: (Score:2)
Linus for one. A lot of embedded people don't like it either. It's just not suited to that kind of work.
(My emphasis)
Different idioms are good for different types of work. You do not use the same hammer everywhere. Just because one sort of hammer is not best for one type of problem does not mean that it is no good everywhere -- come on, we are brighter than that!
Re: (Score:3, Insightful)
Re:Who hates OOP? (Score:5, Informative)
Re: (Score:3, Interesting)
Re: (Score:2)
Apart from self-righteous know-it-all contrarians, who hates OOP?
Hating OOP is popular in the Javascript community, largely because classes are poorly designed in Javascript. They prefer functional programming because functions have an ok design in Javascript.
One of the biggest problems they run into is where to put state.
Re: (Score:2)
Perhaps "hate" is too strong a word.
However I have known many developers, generally people who started their careers in the 90s, who also have a cult-like devotion to OOP, i.e., to them it is the only way to skin the cat. And I've seen them twist themselves into knots and over-engineer the hell out of things just to justify that belief.
That being said, I think in general one of the pitfalls of many experienced developers is that when they learn a new technology stack, they immediately set about trying to b
Re:Who hates OOP? (Score:4, Insightful)
These aren't hard rules, but it's important to say that OOP is best served judiciously. A heuristic might be that if a reader is confused as to where the implementation for a given invocation is defined, you've gone too far down OOP.
Re: (Score:3)
Seriously. Apart from self-righteous know-it-all contrarians, who hates OOP?
I am a self-righteous know-it-all contrarian and even *I* like OOP as a tool!
Re: (Score:2)
Seriously. Apart from self-righteous know-it-all contrarians, who hates OOP?
Java and C++ programmers.
Re: (Score:2)
Re:Who hates OOP? (Score:5, Interesting)
A lot of smart people talk about the flaws of OOP: https://www.yegor256.com/2016/... [yegor256.com]
This article does a really good job of breaking down all the broken promises of OOP: https://medium.com/@cscalfani/... [medium.com]
It's a shame a lot of the open source community isn't familiar with what's going on in the Swift world. Protocol oriented programming is a huge game changer. But as with every tool, I think you still have to pick the best tool for the job. You'll never find the "one tool to rule them all".
Re: Who hates OOP? (Score:3)
It depends on how OOP you're talking about. I personally hate large OOP frameworks that turn every operation into 10 inter-related classes instead of just using a function. So, if by OOP you mean "make everything an object", then yeah, plenty of people hate OOP.
use every language feature in a single application (Score:3)
Seriously. Apart from self-righteous know-it-all contrarians, who hates OOP?
Those who feel it is their personal challenge to use every language feature in a single application. C++ drives these people to great anger.
OOP is fine (Score:5, Insightful)
OOP is fine. I just don't like C++
Re:OOP is fine (Score:5, Interesting)
Opposite. I find needless extraction into objects "because you're supposed to" to be bad, but I love the aspects of C++ unrelated to "objectifying" your own code. I love STL, I love templates (though not iterative template-fu mazes), I love auto, I love range loops, all that sort of stuff. Don't get me wrong, I have no objection at all to objectifying parts of my code that logically should be objects, the sorts of things that normally would be structs in C. But I find the notion that a lot of people take, that everything should be an object, to be as crazy as if someone were to tell a C programmer all of their local and global variables should only exist inside structs.
Old C++ was painful. Modern C++ has a steep learning curve, and that turns a lot of people off, but it combines great abstraction power with great low-level control, which matters a lot to me in many apps (for apps where I don't care about that sort of stuff, I just use Python). I never touch pure C unless I have to. It feels like you have to spend most of your time reinventing the wheel, writing tons of code that's a simple one-liner in C++, and it's far too vulnerable to a lot of simple types of memory management or overflow mistakes for no good reason whatsoever.
Re: (Score:2)
Opposite. I find needless extraction into objects "because you're supposed to"
Yes. People who blindly make rules like "because you're supposed to" make everyone's life miserable. Ignoring the use of inheritance in C++ as a kind of aggregation-with-namespace[*]-flattening (which isn't really OO in any meaningful manner), OO is fine if it's used appropriately. Shoehorning everything into a single rooted class hierarchy with all virtual methods is sensless brutality.
It sounds like you've seen plenty of that.
Re: (Score:3)
There's no reason to use C++ unless somehow you are forced to.
Re: (Score:2)
I - obviously - don't have the time to respond to, or even read over - a ~100 page rant. Just skimming over it, I see a broad mix of A) things I, as a developer, could care less about (like things pertaining to compiler writers or how binaries are structures), B) things that they want to do to slow down or remove useful features from the language (um, NO), C) things that are obsolete, and D) things that are outright wrong. Just to pick a random one:
Re: (Score:2)
Doesn't seem appropriate for performance-limited tasks [debian.net] (unless you have an issue with their test programs? Seems pretty universal, though) .
Again, if it's not performance-limited, I use Python :) But when there's computation or memory limits, you need a language that lets you really drill down in performance-critical sections (while still giving you high-level abstractions for the rest).
Re: (Score:2)
OOP is fine. I just don't like Java.
Why does the name of a class have to match the name of the file it is implemented in? Why can't I declare more than one public class in a single file, if that works best for my project? For performance, why can't I cast an array of bytes to a 64 bit integer to perform math on it, then access those individual bytes afterwards again without shifting or masking them?
Java introduces a plethora of limitations that have nothing to do with the heart of OOP at all. However, OOP
Re: (Score:3)
This is actually only true if the class is public. Basically, the restriction exists because it makes the compiler's job easier.
See above.
You can, however, have as many nested classes as you want within another one, and your nested classes can be named anything you like.
Abstraction and polymorphism (Score:2)
That's what makes programming object oriented (so I was taught, and it turned out correct in my experience). The language is absolutely secondary, what matters is that you understand and implement these concepts. Inheritance is also secondary - it is just one possible route of many to provide polymorphism.
The problem with Java is that it provides significantly less options for polymorphism. And that is really strange for an interpreted language.
Re: (Score:2, Informative)
Java hasn't been interpreted in any meaningful sense in 20 years.
Re: (Score:2)
So there is no such thing as a JVM? Hm, how strange.
Objective C also uses an interpreter to provide the object-oriented features, and it does a much better job than Java.
Re: (Score:2)
I hate the libraries not OOP. (Score:2)
Re: (Score:2)
And inheriting some things automatically adds a huge amount to the program's footprint.
No, it does not. Seriously, are you that silly? Good luck as a programmer, erm. coder.
If you had not inherited it, you had it in the class you are using and had to program it your own.
And a decent C++ linker strips anything - that he can figure that it is not used - anyway.
Code foot print is in 99.9999% of all use cases no problem at all.
"Cornerstones of OOP"? (Score:3)
OOP cornerstones like encapsulation, inheritance, polymorphism
I don't see how any of these have ever been "cornerstones" of OOP, except perhaps for specific kinds of polymorphism. Encapsulation was already present in modular languages, inheritance is not necessary for OOP, and some forms of polymorphism are entirely unrelated to OOP.
Re: (Score:3)
Just because the ideas were already present doesn't mean they are not the cornerstones of that philosophy. OOP wasn't a new idea, it is a label applied to a combination of techniques already in use at the time.
Re: (Score:2)
I don't see how any of these have ever been "cornerstones" of OOP,
Because that is how Academics - damn them - define OOP.
Encapsulation was already present in modular languages
Name more than 2 or 3? Ooops? And which one of them is in our days still in use?
inheritance is not necessary for OOP
Yes it is. Otherwise you are programming Object Based. It is one of the definitions of OOP that the language is only called OO if it supports inheritance.
Ofc. you could argue that pure OO languages like Self, do not nee
Not exclusive. (Score:3)
acknowledging OOP cornerstones like encapsulation, inheritance, polymorphism
They are also cornerstones of a lot of other styles that aren't OO, and according to Alan Kay, what is taken to be OO is not the kind of OO he championed. Erlang is much closer to Alan Kay's OO, for example. https://news.ycombinator.com/i... [ycombinator.com]
It's c++ people hate (Score:5, Interesting)
C++ has always been way too useful not to be the go-to language for serious programmers. Yet it's really an awful language built out of a million afterthoughts because it had to be constructed while the car was moving. Anachronisms like separate header files, and how constants and default args are initialized are just horrors. People then try to retro-justify this by saying separating interfaces into header files is an important disciplined way to structure programs. It's not. It just had to be that way given it was all syntactic sugar on top of C and also had to follow strong typing.
Much cleaner object orientation lives in many languages. (Even Perl, yes Perl, has more sensible objects than C++. ). It's why people like python and Java. Sadly it didn't have to be that way. Objective-C was also a syntactic sugar over C that had a much cleaner object interface. Not a great one but certainly better because it really got at the heart of what an object really is. It's about data hiding and thinking of objects as agents you communicate with not just bins for organizing your code. As a result Objective-C went with late binding (like java) and also did not require an object to actually run the method you called. Instead calling a method was actually called, initially, passing a message to an object. The object got the message and then could decide what it wanted to do with it. That was the basic mental model. Now in practice, for efficiency the compiler would bind the message passage to a method call so in the end it amounted to be the same thing. But in theory an object could, in late binding, intercept the message and on it's own re-interpret what the object should do with it. So this really was an object and it was really hiding the data not simply making it hard to reach.
But the main reason people program with objects is much simpler!
Simply put there is no modern language that is not object oriented. So all languages that are not object oriented suck even more than C++ because they are archaic.
Well that used to be true. Recently some functional language like Julia, are fully modern major general languages that don't have objects. When you try to learn them your head sort of explodes trying to un-think objects. Once you manage that brain twist Julia is a awesome language. It's surprisingly different not just yet-another language. Very modern even though it has some lineage to old languages like fortran lurking in it's bowels.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Sadly it didn't have to be that way. Objective-C was also a syntactic sugar over C that had a much cleaner object interface. Not a great one but certainly better because it really got at the heart of what an object really is. It's about data hiding and thinking of objects as agents you communicate with not just bins for organizing your code.
I agree with this (and you ought to mention Smalltalk in there) but somehow people didn't like Objective-C.
OOP is fine (Score:5, Insightful)
OOP is fine, quite useful for many things. As with every useful thing, it can become bad quickly if you either don't know how to use it or try to use it excessively "just because". E.g. sometimes at work there is a task that can be done in a, say, longish function. But a younger developer with a "must do everything OOP" mentality might make it into 5 objects spanning several files, making a 1-hour task into a 1+ work day thing that ends up being quite annoying to maintain.
On the other hand I find C++ bad itself, and definitely not because OOP. Note that several subsets of C++ are fine, the badness is when you consider the entire thing.
Re: (Score:2)
You get something similar with the thou shalt not use goto mentality. Dijkstra was talking in an era when it was not uncommon to see programs where 1 in 3-10 statements was a goto; this made the code hard to understand. Block structuring was new and helped greatly with clarity. I find that I use a goto every thousand lines or so - I do so because it simplifies the code, ie makes it clearer/cleaner.
Clear, understandable code is what we should strive for, not following an edict that many do not understand.
"Total absolutes are always wrong." (Explanation i (Score:3, Insightful)
It is false that everybody hates OOP.
Hence the entirety of statements following after it, is invalid.
It is merely fashionable for, frankly, snobbery reasons, to hate it.
I suggest to not go with the trends of the mentally insecure and immature who need such memes to pump up their ego.
The thing with OOP was, that it was such a nice idea, that it got turned into a silver bullet and a cult by not that wise people. And then into a cargo cult / religion by following generations. Allowing it to stray from the ideas it originated from.
So of course, once somebody pointed at all that and laughed... and succeded with it for the above reasons... everybody who needed some ego boost jumped on that "bandwagon to the dogpile". (A social device that is so popular, it could be considered a disease of our times.)
This is merely the first counter-wave. And you are the beginning of the first counter-counter-wave. /them/ (weaker) too. ... Until it stabilitzes somewhere in a sane middle ground, where OOP is certainly a useful tool, and often very nice, and class-based OOP too, but not a silver bullet, and there are other nice concepts too, and you can insipre yourself by thinking of all the gradually varied permutations of mergers of all those concepts, and beyond the rim of that box of boxes.
You will experience another, second, weaker counter-wave against you, once people have formed behind you. Leading you to counter
I would love to cut this entire thing short, and end up there right as everybody reads this. But basic inertia makes this unlikely without an expenditure of so much energy that it's equivalent to an explosion.
So there we are. :) :)
Play the rituals. Enjoy the ride. Trust in the outcome. You can feel calm now.
Re: (Score:2)
It is false that everybody hates OOP.
True. Some do hate it, some do not (for whatever reasons). This causes problems with those simple minded people who think that questions like this should have a TRUE/FALSE answer - when there are many shades of grey in between. "it depends on ..." things.
This is also the blight of a lot of contemporary politics*, people want to think that Mr X is good and Ms Y is bad, or that policy A is bad. They do not like to dig down, think and understand that some of what Ms Y says is correct and some of what Mr X says
Who is mixing up cause and effect? (Score:3)
Feldman argues it became popular for the overall upgrade from C
Yes, that might very well have been why C++ became popular. But programmers could have cheerily continued to do the procedural programming in C++ like they were used to in C, perhaps using an object here or there as a "super struct" or taking advantage of new features like templates. In fact that's how I saw a fair few programmers use C++ at first. And if OOP really was that terrible, they would have continued using C++ like that. Instead, OOP became popular despite the wonky implementation in C++, not because of it. Programmers started using OOP because they saw its usefulness for a great many cases.
Re: (Score:2)
I don't hate it :P (Score:2)
I love it!
Bring back line numbers and goto statements (Score:2)
Re: (Score:2)
Re: (Score:2)
Nothing wrong with an occasional goto - as long as you do not have so many that it makes the code hard to understand. A goto can be a good way of dealing with an error (eg: goto end of function: close file, return error). See my comment a few above this one.
Re: (Score:2)
Re: (Score:2)
Re:A lot of the view is elitism (Score:4, Insightful)
Trollish article (Score:2)
Re: (Score:2)
It wasn't shoved down everyone's throat,
It kind of was, if you wanted to program for most computers in the 90s, you used C++. (or Visual Basic).
Re: (Score:2)
i'd say the reason is not technical, (Score:2)
but socioeconomical. the oop paradigm has some strong points, as has any other, but it is quite unique in how it encourages classification in a broad sense, an approach that is much preferred in enterprise organization as it provides a (mostly imaginary but still appealing) degree of control over diversity. sort of bureaucratic mindset.
regarding the technical aspect, the hype for oop was pretty strong back in the day, and equally strong is the ongoing demonization, yet oop still thrives. both are equally b
Meh (Score:2)
For me it was the Javadocs (Score:5, Interesting)
OOP is much easier to document than functional languages, and that was huge for a newbie like me. Scheme? At the time I had no idea what was going on under the hood, and its standard library was a complete mystery to me. Scheme is great for illustrating advanced CS topics like recursion and macros, but it is not that great for teaching a new programmer how to build something.
Java and OOP were almost like legos for me. You only learn the downside of OOP through experience. When you have no experience, it seems like the most obvious and intuitive way to go.
Only approach taught in '90 and later (Score:5, Insightful)
I think the answer to the question comes from teaching a generation of programmers/software engineers that OOP was the *only* way to code. The philosophy was that using non-OOP was "previous generation", was inefficient (ie dumped too much low level work that could be handled more efficiently by the system) and was the reason why there are mounds of bad code in existing applications.
Unfortunately, the all OOP approach meant that understanding a lot of basics (ie pointers, array handling and memory management) was never properly taught resulting in programmers falling back to OOP in situations where they know it's not the appropriate choice but not having the knowledge base to provide the best approach to solving the problem.
I'm not saying that OOP is wrong, for the vast majority of today's applications, it is a more than acceptable, but there is a sizable fraction where only having OOP in your toolbox results in more work, bloat, overhead than is necessary which is why people curse it.
OOP is like democracy (Score:2)
Object-Oriented Programming is like Democracy: everyone hates on it, books are written about how awful it is, but it is the best system and everybody who can use it chooses to do so.
To each his/her own (Score:2)
It's the FRAMEWORKS people hate today, not OOP (Score:4, Interesting)
I used to hate OOP and now use is quite often. OOP does have the power to simplify coding through abstraction.
An ORM like SqlAlchemy is a good example of OOP that simplifies coding, where your database objects magically become objects in your code.
However, today OOP is not as big of a problem.
Frameworks .. picking a framework, learning the framework, dealing with poor documentation and bugs, then learning a new framework that does the exact same thing when another programmer decides to abandon the current framework.
Or, you could just write your own framework and join the fray, maybe fork and existing framework. :)
Re: (Score:3)
I don't hate OOP but I recognize that is is not at all what it was original sold to be.
Frameworks are definitely my biggest nemysis today because they always constrain what you can do and how you solve problems. However, conventional OOP was also a bad idea in and of itself. Exactly zero of it's claims came true, in practice. It's now much harder to write and maintain software than it used to be...
I see JavaScript and Rust as saviors. JavaScript's prototype OO model is far more efficient. Rust avoid co
Not really earth-shattering (Score:2)
OOP cornerstones like encapsulation, inheritance, polymorphism
All of which was possible in plain old C anyway. You just had to know what you were doing. C++ added mostly syntax and gave new roles to assignment, adding a layer of abstraction. Good for code legibility. Not so good for those who learn languages by rote without actually thinking about what the computer is actually doing in a given subroutine/function/method.
Ally Oop! (Score:3)
I've been a "strictly C" programmer for forever, cutting my teeth at Bell Labs.
My boss there was "Ken and Denny's" admin when they were working up in their hideaway.
She was the brightest, quickest programmer I have ever met, and man, she had some stories.
Much of Vols. 1, 2A, and 2B were written off of her drafts.
I had first heard of C++ at an intro talk that Stroustrup himself gave at the Labs in Holmdel.
Although I loved its clever name, I've never enjoyed the C++ effort-to-results ratio.
Same with Java. To me, It is opaque, ugly, and just plain repellant.
Java has always felt like it ended up with layer upon layer to have it meet its promise.
But today, writing in Swift provides the most pure fun I have had in my entire career.
(Granted, Apple needs to fully document all their APIs for once please.)
When I have to go back to C, it feels like working with a hammer and chisel.
A very precise chisel, but the chip, chip, chip now feels like it eats up so much time.
Simula? Smalltalk? Objective C? (Score:3)
This blog doesn't seem to understand the history of OOP very well. It existed long before C++. Simula (1962), Smalltalk (1972), Objective C (1984) all came before C++ (1985). And as we know, Objective C was used by NeXT and later Apple. That also hugely contributed to the popularity of OOP.
Nobody hates OOP. (Score:3, Insightful)
Seriously. Nobody hates OOP. Absolutely no one.
There is a move from OOP as the one-size-fits-all solution towards more functional programming in scenarios where that makes sense, since that became somewhat mainstream 10-15 years ago. Functional programming aside, the solid advantages of OOP are very well known: Information hiding, implementation flexibility, lose coupling / high cohesion and so forth are all fundamental attributes and principles of programming made possible and implemented by OOP. Nobody in their right mind will dismiss OOP. It is not the golden hammer anymore, but it really never was. Perhaps for a few years in the late 90ies / early 2000nds when the Java crew was nutting in their pants with XML config orgies and massive libraries.
OOP is still alive and kicking and very well accepted and it always will be for the fundamental principles it represents and implements.