ORM is the Vietnam of Computer Science, because OOP is the Vietnam of Computer Science: A 25-year failed experiment in boosting productivity of masses of mediocre programmers using this one true silver bullet.
OOP is the most popular paradigm because it works the best for the greatest number of people and projects. It's natural to break large systems into component parts recursively, and to let components have their own state.
What alternative did you have in mind? Functional programming?
It's a novice mistake to think the solution that wins out is the one with the most technical merit. Virtually nothing is truly meritocratic.
> It's natural to break large systems into component parts recursively, and to let components have their own state.
That's just modularity. Nearly every language has it, and OOP is merely one way to achieve it.
2. Where you do want them, like at coarser service boundaries, virtually all general purpose languages have modules of some sort.
2. If a module has state, is it not named with a noun, is not an object even if we try calling it an entity, an actor, or anything else?
But we're talking about OOP, which is characterized by specific logical properties surrounding modelling, encapsulation and extension, not about colloquial terms like "objects" that are referred to by nouns.
Conflating colloquial language with the programming language is one of many reasons why OOP seems seductive but is often misleading.
Also see Actor model or "out of the tarpit". Also Barbara Liskov "Programming with Abstract Data Type". Encapsulating state instead of behaviours is a mistake.
Grand parent is talking specifically about encapsulating state and not just behaviors.
Our Objects of today come straight from Simula.
Edit : and yes, there is a reason i said behaviour and not state. Objects are bad at encapsulating state, because you do not encapsulate state like that.
[1] And I could have tested this hypothesis by doing more background reading of the history, but I haven't.
Not sure it was the easiest way (see IMGUI), but I agree with you that some early UI frameworks took that approach and it was probably so much better than what came before it, that OOP is still riding that wave of enthusiasm.
The biggest lie OOP ever told was that breaking things into smaller components is specific to OOP
When you have a algorithm that goes Red-Hot, use Data-Orientated-Programming.
When you have lots of annonymous objects repeatetly passing through recombined pipelines, with minimal work, try a functional approach.
Try to see OOP not as the final stage of a masterpiece, rather as the launch-pad - and a first working version.
Also- what is the best approach, highly depends upon the goals of the project. Speed at all cost? Safety trumps all? Rapid development? Scale-ability?
PS: Regarding Object-Relational Databases- i found the true nest of snakes to be that for each object basically a small hand crafted version of git is needed to resolve the changes, once several applications start using the same DB. Not only that, but changes made, that relate to the changed data, needs to propagate- and can not do so only by simple trigger, but often by program-logic.
Sloppy work can lead to data fragments being part of two separate objects. What if two programs use one of two classes, but one resides within the other? Who has the right of update?
In addition ORM can hold duplicates of a Datum, and very soon, the urge will appear to replace every datafragment in your saved object with a pointer (key) to one, and only one instance of the real-world data piece.
TL,DR; This is one of the cases, where the pain comes not instantly, but after a while - and then never leaves. Get somebody who witnessed something like that blow up in another company to help you avoiding the worst.
A succinct definition of OOP would be nice to combat the misinformation you're complaining about.
The description of OOP provided in the Wikipedia article on programming paradigms [1] matches my current understanding of OOP.
> object-oriented which groups code together with the state the code modifies,
Maybe that's a little too succinct, because I think it's also worth noting how [2]
> In OOP, computer programs are designed by making them out of objects that interact with one another.
I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either.
I guess this might demonstrate the inertia of the so-called misinformation, but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed.
[1] https://en.m.wikipedia.org/wiki/Programming_paradigm
[2] https://en.m.wikipedia.org/wiki/Object-oriented_programming
The point I was making is that this is not an idea invented by, or reserved for, OOP.
If there's anything somewhat unique to OOP approach (both Smalltalk-like and Java-like), it's constructing the program as a graph of objects communicating with each other (be it via methods or messages).
> but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed.
Here's the thing: the majority of popular software engineering books were written during the OOP fad. They like to mix up OOP-specific things with universal techniques, making the latter look like a feature (or invention) of the former. A good cure for that is to grab something from pre-OOP era. Consider e.g. reading SICP (or watching SICP lectures) - it's the first book that made me realize just how much concepts popularly associated with OOP are paradigm-independent ways of structuring programs.
TL;DR: OOP did not invent abstraction, it only appropriated it.
We can make the same mistake of assuming a single monitor in Java or C, but both languages can also easily support multiple monitors ;)
I'm not sure where you got "the majority disagree with your definition of the term" when I didn't even attempt to define the term until this reply! Or why you key on the word "orthogonal" which is in the parent of my comment, and certainly is imprecise: A better description would be, OOP holds no exclusive claim to these ideas. We don't all despise OOP, but rather the false notion that it is a "silver bullet." I quite like well done OOP with expressive types.
I'd be irritated by you linking to Wikipedia articles for "Programming paradigm" and OOP except they're mobile links, which means you're getting all in a hissy on the go, and that's sorta cute.
A hissy is a good description of my last comment lol. I was getting pretty annoyed at people claiming that my understanding of OOP is wrong. I don't think OOP should be this incomprehensible thing.
I now understand that you just meant that not all encapsulation is OOP. I certainly agree there. Cheers.
My favorite question. Have a look at the sidebar in this link [1] for starters (by 'alternative' you didn't mean you expect me to advocate complete abolishment of OOP did you?). I'd say being familiar with at least 5-10 diverse paradigms from that list works wonders.
Polymorphism, sure! Composition, sure! Information Hiding[1], sure! Modularity, sure! Implementation inheritance, ooh, sounds interesting[2].
The only problem with that sales pitch is that you don't actually have to combine all of them into a single concept ("OOP"). They are pretty much all orthogonal.
[1] That's was actually called Abstraction before "OOP" was invented as "a thing" in the mainstream. Well, it still is, but it's just that it applies beyond "public/private/package" scope (and the like). For example, O'Caml has "modules" which give you abstraction at what would be equivalent to Java's package scope. Amazing, I know. /s
[2] To be fair, I was absolutely entranced by the promise of implementation interitance[3]: What can I say, I was young and naive, and knew only Turbo Pascal and Delphi. With considerably more experience I consider it a fundamental mistake to include such a construct in your language.
[3] As was the rest of the industry, at least I had the excuse of inexperience. Such mistakes we've (collectively) made! :)
I'm not a big fan of Java or C++, but they have been used to write tons of code running software that's complex and in wide use.
Maybe a functional, non-mutable approach is better, but until it has a similar widespread use and enough time for people to complain about it and suggest new superior paradigms, I'm not sold on the truth of these claims.
It sounds more like preference and opinion than fact. Also, I can't help but wonder if it's the C++/Java model of OOP that's more than issue than OOP itself. Would the same complaints be made of Smalltalk? Personally, I prefer the OOP of Ruby than that of Java, and don't really see a problem with using it.
If other languages were used, perhaps they would not need to be so complex and resource-consuming, but this is also why any "actual facts" which you're looking for are difficult to find: you'd need to essentially do the same project multiple times in different languages and perform a very highly controlled comparison, and there are numerous other confounding factors. Failures or successes alike can easily be spun into blaming the languages.
IMHO there is no one perfect paradigm for everything, and the only failure is in promoting one as panacea or trying to view all of programming in the same way. I think trying to classify languages or code as strictly OOP, procedural, functional, etc. and shunning "hybrids" or even basic common-sense pragmatism for dogmatic purity has had the greatest negative effect on productivity.
That's it. Rigid ideology is the real problem. In software engineering and other areas too, eg politics.
NO. Functional people claim that, but never had a proof, since there aren't that many people using it to build large systems. Thus this myth lives on. :)
Note that it has never been "proved" that OOP is more productive than anything else either.
Well, let's unpack this a bit. No Silver Bullet – Essence and Accident in Software Engineering[1] was written in 1986 by Turing Award winner and author of The Mythical Man Month Fred Brooks.
His thesis was that there was no single technology or technique which by itself promises even one order of magnitude of improvement within a decade.
However, he did write this of OOP:
"Object-oriented programming. Many students of the art hold out more hope for object oriented programming than for any of the other technical fads of the day. I am among them" [2]
In addition to OOP, the biggy he identified was reuse, mostly in COTS.
"A disciplined, consistent effort to develop, propagate, and exploit these innovations should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road."
20 years after the original essay, there was a retrospective at OOPSLA. Here is what Brooks had to say[3]:
"Of the candidates enumerated in 'NSB', object-oriented programming has made the biggest change, and it is a real attack on the inherent complexity itself. The most promising attack continues to be re-use, and re-use of COTS programs in particular. "
And of course he is absolutely right. OOP has delivered massive increases in productivity, we are successfully tackling problems of far bigger complexity than we did back then. Just as a small example, the WWW was invented by a single person in a couple of months in his spare time! On NeXTStep a highly OO platform. Replicating that with lesser tech took a team a year, and they had to leave out editing, which was in the original.
And of course we reuse OO libraries/frameworks all the time, and really don't take notice of this anymore. Write an application on iOS or Android, and you are reusing vast amounts of OO code.
So the idea that OO is a failed "silver bullet" is nothing short of ridiculous. It has succeeded, and in succeeding has pushed us against new frontiers of our ignorance.
[1] https://en.wikipedia.org/wiki/No_Silver_Bullet
Right on. So many passionate arguments amongst developers could be cut off at the pass if people simply accepted that in computing the answer is always...
It depends.
OOP is a useful and powerful abstraction for logical, artifical situations, like modelling a mobile platform.
Its a completely crap solution for modelling real world, gray situations like "employee ISA person".
Unfortunately, "employee is a person" is the first example that many people think to trot out to explain OOP, since it is easily understood by the recipient.
That's a really bad argument. We reuse vast amounts of non-OO code too(libpng, libjpeg, libwhatever). We don't reuse code because it's written in a paradigm, but because we need it. Since OO spread like a virus (some argue it was for the better, I argue it was for the worse) and is now the most popular paradigm, it makes sense it will have produced lots of frameworks, but it doesn't mean OOP was needed to write and use them.
Of course, things like libpng and libjpeg are for fairly small and more importantly well-contained functionality, so simpler reuse mechanisms are sufficient.
Anyway, you are entitled to your opinion, however at odds it is with reality.
Here is how I can read the last few decades - software started becoming more and more popular, and in the beginning of the 90s people jumped on the OO hype/bandwagon (and haven't let go ever since). Now, OOP done wrong was worse than procedural done wrong, but since the hype and koolaid were so strong, and the fast-growing market really needed the software, programmers have just plowed through, DESPITE OOP. Classic Starcraft story, jump to "Game engine architecture" - http://www.codeofhonor.com/blog/tough-times-on-the-road-to-s... . My point being, you can release software even when you get held back by OOP.
Another thing that you failed to do is comprehend my message. Of course we have a lot of OO frameworks, since OOP is the most popular programming paradigm. If functional were the most popular then you would have a lot of FP frameworks. You're using argumentum ad populum, basically.
Without controlled experiments we cannot "establish" causation. However, citing things that work with OOP certainly disproves that OOP doesn't work. You can then fall back to the weaker position of "OOP doesn't matter", but it certainly does work.
Anyway, I certainly did a LOT more to make my case than you did, because all you did was make ever wilder claim, even claiming hypotheticals as absolute truth with ZERO backup whatsoever.
I gave the example of the WWW App. Written on NeXTStep/Objective-C, which is the closest the Smalltalk-like OOP and frameworks you could get at the time. One guy, a couple of months in his spare time. Editing included (largely because he was reusing an existing class library). 5KLOC. From scratch. Inventing.
NCSA Mosaic was created on top of non OO X-Windows and later Windows and Mac. 5 people, a year, 100KLOC, just copying something that already existed. No editing. So arguably lesser functionality, 20x the code, 10x or more the development effort.
So if your point is that OO doesn't work, you have utterly and completely failed to make that point. In fact, you just list projects that succeeded with OOP and then claim without any evidence whatsoever that they succeeded "despite" OOP.
A: "Rockets don't work".
B: "Here are some rockets launching satellites into space"
A: "But you don't understand, these satellite launched despite the rockets"
B: <stepping away slowly> "OK, whatever makes you happy."
Oh, and here are productivity numbers:
http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm
And you are reversing cause and effect. How do you think OOP became popular? Because it allowed us to tackle larger projects more easily.
Try to back off the religion a little and look at actual evidence.
Does that mean OOP is the be-all and end-all of Software Development? Nope. At least I think not and I certainly hope not. Because it is deeply flawed, just like all of our current paradigms are deeply flawed (and IMHO FP is flawed even more, but that's another discussion). However, it was a lot less flawed than what preceded it, and therefore allowed us to get a lot more done. Or maybe not even less flawed, but had more useful points that compensated.
Exactly my point.
> However, citing things that work with OOP certainly disproves that OOP doesn't work.
Spaghetti code works too, you can make anything work. Question is if it works better.
> all you did was make ever wilder claim
I mean, do I really need to repeat what people have been saying for decades? http://harmful.cat-v.org/software/OO_programming/
> I gave the example of the WWW App.
And I gave you the example of Starcraft, where the use of OOP actually slowed them down. And it had ever so slightly more than 5KLOC, so it's probably a better way to illustrate OOP's pitfalls.
> NCSA Mosaic ... just copying something that already existed.
Not familiar with Mosaic's history, but what you appear to be describing is porting an OO codebase to a non-OO codebase, which is not an easy feat. I know some OO codebases that are so tangled in various layers of inheritance and composition that it is only natural to be a lot of effort involved. And generally, porting isn't always a clear-cut affair; for example, straight ports from PCs to consoles are rarely straight, unless you're using a generic engine that will do that for you.
> So if your point is that OO doesn't work, you have utterly and completely failed to make that point.
No, my point was your argument by popularity is flawed, and you don't seem to have graped it. Read my original comment.
> In fact, you just list projects that succeeded with OOP
Even the author of that piece describes "the horror of the class hierarchy" and how OOP gave them a hard time. You can travel between cities with the handbreak on, but that doesn't mean you should.
> "But you don't understand, these satellite launched despite the rockets"
This analogy is so flawed I'm not going to even bother dissecting it, that's just lazy on your part.
> here are productivity numbers:
From where I gather we should all be using Haskell or something.
> And you are reversing cause and effect. How do you think OOP became popular?
C++, Java, marketing, marketing, marketing.
> Try to back off the religion a little and look at actual evidence.
Quite so. Show me evidence that OOP is better than other programming paradigms.
Huh? Why should I? I was responding to someone who claimed that OO had "failed".
It hasn't, and for non-failure, existence is quite sufficient (and no, this is not the "proof by popularity" you keep talking about for no particular reason I can surmise). Fact is that we have been able to successfully tackle much larger projects (and finish them with less code) than previous paradigms.
In addition, the very person who wrote about "No Silver Bullets" predicted that OOP (which was new at the time) was one of closest things to a SB that he sees, and 20 years later confirmed that estimation. He took a little harder look than you did.
>> productivity numbers: http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm
> From where I gather we should all be using Haskell or something.
You should improve your reading skills. Haskell language level is 8.5, Objective-C is 12.0, Smalltalk is 15.0. Higher is better.
Once again, I wouldn't claim that OO is "best", though right now it is probably one of the least bad we have. However, the evidence is overwhelming that it hasn't "failed". (And no, single projects failing doesn't mean OO failed. And you are probably going to have more failed OO projects than other paradigms, simply because there are more OO projects).
> [NCSA Mosaic] Not familiar with Mosaic's history
Then how about you don't make specious claims about it??
There are plenty of highly useful techniques and tools, including OOP, but you have to do the work, you have to apply the techniques skillfully and conscientiously. You have to know when you're just adding complexity with your design and when you're managing it well.