Slashdot Mirror
The Object Oriented Hype
bedel231
sent us a fairly lengthy and detailed article discussing the hype
surrounding Object Oriented Programming and tries to claim that a lot of things taken for granted are mythical. Personally, I've never been a huge fan of OOP, so I tend to agree on a lot of these points. Regardless of your stance on the issue, it's worth a read.
The article is vapid since it addresses a collection of OOP myths that don't cover the real benefits, and secondly comletely ignores the practical reality that for most people the OOP/procedural choice is C/C++ choice, and that C++ has many features (such as constructors/deconstructors) that while not necessary for OOP, are huge benefits.
Myth: OOP is a proven general-purpose technique
Myth: OOP models the real world better
Myth: OOP makes programming more visual
Myth: OOP makes programming easier and faster
Myth: OOP eliminates the complexity of "case" or "switch" statements
Myth: Inheritance increases reuse
Myth: Most things fit nicely into hierarchical taxonomies
Myth: Self-handling nouns are more important than self-handling verbs
Myth: Only OOP has automatic garbage collection
Myth: Components can only be built with OOP
Myth: Only OO databases can store large, multimedia data
Myth: OODBMS are overall faster than RDBMS
Myth: C is the best procedural can get
Myth: Implementation changes significantly more often than interfaces
Myth: Procedural/Relational ties field types and sizes to the code more
Myth: Procedural/Relational programs cannot "factor" as well
Classic OOP features such as inheritence may generally be over-hyped, but specific cases such as polymorphism are very useful (even if there are ways of doing the same thing in languages such as C that were not designed for OOP).
Some of the major benefit of OOP, and specifically C++'s objects, are:
o It is a clean module packaging mechanism that encourages cleaner interfaces between modules
o It encourages opaque data interfaces (method access vs public access) which results in less bugs
o It makes use of self-initialization/cleanup (constructors/deconstructirs) that avoid a whole slew of programmer errors.
o The self-containedness of objects does make code reuse simpler and less bug prone.
etc, etc.
The guy who wrote the article (and the esteemed Mr. Taco) appear not to have much hands on experience writing OO code.
This is the most stingingly correct point, in my opinion. In fact, in my experience, they change equally often at best. And in cases where code is actually meant to be reused - something which, by the way, some of my smartest friends have told me, after no small amount of experience over the years, never actually happens - its the interface that often proves more likely to need modification...
We're on the road to Tycho.
I work in a software company, and our product takes up no less than 300 MB of code. Even in the most well-organized non-OOP code, our software would be impossible to debug or even build, because we would need to go through hundreds of lines of code. In addition, reusability would be hurt, since even though the functions would be there, minor changes in the arguments might make the entire function worthless.
The author's example using People and Taxes is particularly striking. He suggests that an object oriented approach would create a person object and a tax object, set their attributes, and run the T.CalcTax method on Person P, while a procedural approach would just feed the relevant parameters to a function. I wonder if the author has ever actually filled out the 1040 Personal Income Tax Return Form. The easy version has 70 entries, and while some are calculations, others are references to other, much bigger, forms! Keeping track of all these variables without some structure to hold them all is just stupid. Object orientation is necessary when code hits a level of complexity where several people, or several hundred, are simultaneously working on a project. The "black box" approach allows for greater flexibility and optimization, since a code change will be transparent to the objects around it.
Another thing to consider, although I know CmdrTaco would berate me for even mentioning it, is the expansion of OOP provided by Java. The Interface in Java allows you to specify several functions, abstractly, that are required for a class to implement the Interface. The implementation of these functions is class-specific: for example, all clothes implement the Wearable interface, but you would not want underwear and shoes to have the same implementation of Wear(). However, in Java, you may specify a function to take a Wearable object, and not need to specify any further. This abstraction level is why OOP does, in fact, better model the real world.
In conclusion, the rantings of a PASCAL junkie should not constitute a Slashdot article. Anyone who has coded in procedural and OO languages should see the extreme idiocy of the article within milliseconds. On the other hand, Perl powers Slashdot, so I guess this is the place for the procedural approach to have its message heard. In fact, Slashdot totally vindicates the article: its non-OOP approach is fast, effective, efficient, and easy-to-understand. Highly scalable and expandable as well. I especially like Slash.pm (aka THE BEAST) and the my_conf{shit} variable. I'm sure the non-OOP approach will really take off once everyone switches over from C++/Java to Perl.
Classes: Communism - adamantly against. OOP: For, not merely for, but in favour of more classes than you could possibly imagine.
Inheretance: Communism - opposed to. Inhereted property regarded as a prop for the aristocracy. OOP: Treats the concept with a reverence not known even amongst the Kennedies and Rockafellas of this world. Encourages, aids, and supports.
Property: Communism - private property treated as an ambonination. OOP: Supports, allows objects to have whatever properties they want, and decide for themselves what is public and what is private.
Objects: Communism - usually on the side opposing the objectivation of anyone, women, minorities, etc. Even cynically, prefers to deal with people as an anonymous mass rather than discrete objects. OOP: Pro-objectification. Treats everything and everyone as objects.
I think it's pretty obvious that our OOP berater has no idea what sie's talking about. That said, most communists I know feel the need to talk in wordy jargon to demonstrate their superior intellects. With OOP programmers making sure they use everything from 'abstraction' to 'polymorphism' in every other sentence, I can see why the author might have been confused...
--
You are not alone. This is not normal. None of this is normal.
I think you need to look at the definition of an "Object Oriented" language. You'll see that to be OO a language must support certain things like inheritance, polymorphism, run time binding (dynamic binding) and many other fun things that you can't do in procedural languages. C doesn't support any of those.
Of course it "supports" them. It's just not as easy as it is in other languages. As has been pointed out before, creative use of function pointers in C can be used to implement polymorphism and "dynamic binding."
Think about it a minute. What does a C++ compiler do? It translates the (high-level) C++ code to (low-level) assembly code. Are you somehow suggesting that there is no way that the generated assembly code can implement inheritance and polymorphism because no assembly language "supports any of those?" If so, how is it that C++ programs are able to compile, link, and execute? The original C++ compiler, cfront, generated C code as output from the input C++ code. Surely the output C code was no less "object-oriented" than the C++ code it was generated from.
You can write object-oriented code in nearly any language. The difference is how much language-level support for OO is provided. Just because you can't write "virual void myFunc()" in C doesn't mean you can't generate the same behavior.
We're going down, in a spiral to the ground
... it's been around (and used successfully) for over fifteen years?
... or whatever buzzword they can apply to their product. Surprise.
As Jim Coplien has pointed out, OO (objected oriented programming / design / analysis) is older today than "structured" programming / design / analysis was when OO first burst upon the scene. (The structured movement first got some serious press in the mid to late 1960s; the classic book by Dahl, Dijkstra, and Hoare was published in 1972. OO started no later than Simula-67 and Smalltalk-72, and first gathered mainstream attention in the 1980 - 1982 timeframe. The first OOPSLA conference was in 1986.)
Yes, some snake-oil salesmen overhype OO
No, OO is not a panacea. It's not even always the right tool to apply to a particular design or programming problem. (Coplien's recent book, Multi-Paradigm Design for C++ , is a tough but worthwhile read that addresses this issue.)
You may dislike a particular language that supports OO (Smalltalk, C++, Java, even Perl) but find the paradigm worthwhile in some other language.
For comparison, compare with this message in Risks Digest: "The structured programming revolution is a real bad idea that has been significantly holding back progress for years.... Have there been any double blind studies which unambiguously show that the kind of programs that structured programming partisans enjoy are really more maintainable than some other kind of program? I've heard lots of testimonials, but no real evidence." Sound kind of familiar? (Heh.) --PSRC
Stupid job ads, weird spam, occasional insight at
Wow. I think /. has been seriously trolled this time.
Does OO make assumptions about human nature?
Actually it does. But it's a correct one.
One of the basic assumptions is that the human brain is built to think about the world in terms of things that have properties and behaviour. We can think in terms of procedures and execution flow as well, but we're not nearly as good at it.
The article is topped off with a gif image tagged "OOP Stinks!". That should give you a good insight into the level of discourse that follows.
Of course, the author absolves himself from all responsibility for having to present anything more than an emotion-filled diatribe by stating early on:
So... his article is based on debunking "OOP Myths", which he states are not "necessarily shared by all or even most OO proponents." He repeatedly fails to back up any of his points with citations or references (and at one point, actually states "Sorry, we accidentally lost the references.") Instead, he justifies his arguments by making blanket statements like "Many OO books and even some OO fans suggest that OO only shines under fairly ideal conditions." Which OO books? "Some" OO "fans"? (Remember the disclaimer - not neccesarily all or even most OO proponents...)
Finally, some of his commonly (or not-so-commonly - take a look at that disclaimer, again) believed OOP myths are outrageous to the point of being silly... OOP eliminated the need for case or switch statements? OOP makes programming more visual? Only OOP has automatic garbage collection? Components can only be built with OOP? Only Only OO databases can store large, multimedia data? Who, exactly, does believe these myths? PHBs? Certainly not anyone with a CS education or decent amount of programming experience.
The best thing I can say about this article is that I think the author has a few good points and compelling arguments that are, unfortunately, lost amid the noise and confusion of unsubstantiated facts. If you can read it through and keep from grimacing in pain as OOP is compared to communism and the lack of research in non-OOP languages is decried, you might be able to find an idea or two that will reward you for the effort.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
the quote on top of the object oriented langages chapter was something like:
"object: to feel distate for something"
I laughed my ass off (even if I do OO programming since 1991).,
Cheers,
--fred
1 reply beneath your current threshold.
Objects are great where they work, and where you have the time and experience to tune them to perfection. The Python libraries are full of beautifully crafted, wonderfully useful object definitions. But that investment is large, and in many cases, doesn't make sense for the purpose at hand. And there are problem domains for which objects simply aren't the natural description.
The OO people say that the wrong way to reuse code is the cut-paste-tweak method, because then you have two diverging copies floating around. In a perfect world everything might be in a source code repository and I could submit a change rather than spawn a private tweak. But change submissions mean bureaucracy, if I'm working with other people. If my tweak will never see public use, the overhead is an unnecessary diversion.
The cited geocities page makes noise about table-oriented programming. I remember hearing similar things in the past, stuff like "Put the intelligence in your data and keep your code simple". I would have liked to see a better description of TOP, perhaps a few pointers to tutorials. The guy's own descriptions are pretty useless for quickly grokking his point. Maybe he's only preaching to the database crowd, and I'm not supposed to get it.
WWJD for a Klondike Bar?
How far is "... a while back while working on an unnamed CPU project..."? If you are talking 5+ years, or even 3+ years, than you data is out of date as today's compilers are much more efficient about optimizing C++ code.
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
Personally, I've never been a huge fan of OOP, so I tend to agree on a lot of these points.
Taco,
Some of us remember what slashcode looked like before pudge and friends started cleaning it up.
Not only are you opposed to OOP, but you don't seem to be terrible wild about structured programming either. Nor do you give readibility and maintainability the time of day. Your relationship with elegant code is in the "distant admiration" category and you seem to consider sobriety an impediment to productivity.
Not that I disagree with you on any of these points, I just wanted to mention that we allready know about them.
--Shoeboy
In general, the criticism contained in the article is poorly founded. The author uses some nice charts, but has no citiations for them. For instance:
Accepted by whom? I've never heard that asserted by anyone in my academic or professional careers.Some of the things he calls out apply equally to procedural languages, such as:
When Pascal replaces C, how do I convert my C functions into Pascal functions? Eh?He makes some good points about measuring the effects of change (everybody should do that!) but I don't think this really strikes a death blow to OOP.
Neutron
I get my kicks above the
It's also true that you can do good object oriened design with a Turing Machine, implemented in the Game of Life, composed of a million midgets wearing reversible parkas, which is directed from above by an Elvis impersonator in a hot air ballon shaped like a guitar.
That isn't saying it's a good a idea.
--
Bush's assertion: there ought to be limits to freedom
I agree.
OO is just a handy way of structuring large systems for maintainability. It is extremely useful for what it does, but isn't magic.
People who dismiss OO out of hand are making the same mistake as zealots who insist that it must be used for everything by rejecting a useful tool.
Structured programming, functional programming, OO etc are all extremely useful given the right problem domain. The skill is being able to look at a problem and pick the correct tool for the job. Rejecting, or choosing, something automatically can be a very good way to shoot yourself in the foot.
It has been a long time since I last posted to Slashdot. I can normally restrain myself, but this is just pure and absolute BS.
Properly implemented, code re-use can pay off immediately. I have worked in shops where every time we added a client, we needed a new copy of the code. Even though most of the processing was the same for the new client, we had to start out with a copy of the code. Code re-use would have bought us hundreds of thousands of dollars very quickly. (This did not ocurr at my current employer)
Properly implemented abstraction and OO along with iterative design can save a large amount of money very quickly. The key is to prototype your interfaces for the application you have in mind. Once you have done that, think of a completely unrelated use of the interface and test that. If you can handle 2 or 3 different uses, you have a good interface to start with. Rinse and repeat for the rest of your system.
People may question you immediately, however the minute somebody decides to change the system message transport from http to JMS, you should be able to convince them of the value of proper abstraction and code reuse, just change the transport class and you are done. I did this in a system where we did all of the work necessary to change the transport in less than 30 minutes. The consultant that had been working on the same problem for 3 months was absolutely amazed at quickly I made the change.
OOP is not a cure all, however its use along with proper abstraction can lead to large savings from code-reuse in a short time.
Mike
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com
Mike Mangino
mmangino@acm.org
I'm a sometimes chip designer, sometimes programmer ... a while back while working on an unnamed CPU project I did some low level performance analysis on a number of well known programs (maybe even the browser you're using now) basicly we were taking very long instruction/data traces and then modelling them against various potential CPU pipeline/tlb/cache architectures - we were looking for things that would help guide us to a better architecture for our CPU.
I found that quite early on I could figure out which language something was coded in from the cooked numbers pretty easily - OO (ie C++) coded stuff always had a really sucky CPI (clocks per instruction - a measure of architectural efficiency that includes pipe breaks, stalls and cache misses) - I spent some time looking at this (since it seemed that C++ code would probably become more common in our CPU's lifetime) - basicly C++ code sucked because it took more icache hits (because the coding style encourages lots of subroutine calls which tend to spread over the cache more filling the I$ quickly) and it took more pipe breaks (also due to the subrotine calls and returns - it turned out that some code generators did stuff that broke CPU's return stack caches causing many more mispredicts) and finally virtual method dispatches (basicly load a pointer, save the pc on the stack and jump to the new pointer) tended to cause double pipe stalls that couldn't be predicted well at all even though these weren't done much they were a real killer (if you've one a bit of modern CPU architecture you learn that with long pipes you live or die on your branch predictor's hit rate - these were very bad news)
In short C++ and more genrally OO result in code and coding styles that tend to make code that makes modern CPU's run less efficiently.
Anyway - you often hear about 'efficiency of programmers' etc etc for OO - I thought I'd add a data point from the other end of the spectrum.
Herbie J.
"If an object is data with functions, then I've been doing object-oriented programming all my life"
Generally when people talk about "OOP" they're referring to three general things you'll find in an OOP language:
Sounds like you've done mostly encapsulation, maybe a bit of inheritance is natural too. Probably not polymorphism though.
The thing about OOP is, although it supports these concepts in the language, it doesn't automatically lead to good design, and that is the point that the author of the article this whole thread is about seems to have missed. You still have to think about your design very carefully to build good reusable components. In general it does make you think a little bit more carefully before you just start coding away, which isn't a bad thing. There is nothing you can do in C++ though that you can't do in C. C++ just lends itself more readily to expressing certain types of ideas within the language's native syntax, e.g. picture the "gtk+" toolkit without all the ugly hacky typecast macros and the hacky inheritance structure.
Presumably there are some OO zealots out there (I personally don't know any but the article author seems to think almost every C++ programmer is an OOP zealot) but in general I think most OOP programmers are more focused on solving real-world problems than on spreading hype. For every rabid OOP zealot, there's a rabid anti-OOP zealot. This guys just one of the rabid anti-OOP zealots. When you really do speak to most people in the business, they *dont* have big issues about programming paradigms. They just use the best tool for the job and are actually mature about it.
My experience in systems design is that OOP shows benefit when you know it, and with larger *REAL* systems. Networked apps, distributed apps, and yes, even large business apps. I've been involved in an IS project written completely in C, using good, structured programming techniques. At a different company, we were building a similar application, using C but applying a more data-centric approach, close to OOP but not there yet. It was much quicker to build, and easier to enhance. If I took a crack at the domain yet again with OOP and C++/Java, I know it could be improved yet again.
The issue though, is that if it's one guy, building a one-shot fire and forget app, don't bother. Code it however you want. If you have a significant project with multiple team members, OOP acts as a common framework and a basis for communication. It draws some borders and sets some guidelines and methods to give a common frame of reference. It's possible, but more difficult to do that with procedural code in *most* cases.
Obviously though, the proof, as the author says, is in the pudding. Millions upon millions of development dollars is OBVIOUSLY being wasted by the industry as it moves to use OOP methodologies and tools. Not just as dictated by PHBs, but also as dictated in start-ups by lead programmers.
Quote from a pundit who knows the industry better than most of us, Robert Cringely, from a slashdot interview no less:
Something else that has changed a lot is how software is written. OOP has paid off more than we even know, so there are a lot of chances to make businesses out of selling cogs that fit into other people's machines. Your driver question, for example, wouldn't have even made sense a decade ago.
Hmm. More than one company now. There's a benefit. Predefined interfaces and component technologies. Can you do that in procedural approaches, yes. Is it easier and more natural and efficient in OOP, yes.
And finally, as I don't want to get too long, let's take another /. post, a reply from John Carmack.
First of all, the fact that none of our deployed games used OOP does not mean that I don't think there are benefits to it. In the early days, there were portability, performance, and bloat problems with it, so we never chose to deploy with it. However, all of the tools for DOOM and Quake were developed in Obejctive-C on NEXTSTEP. Q3 also came fairly close to have a JVM instead of the QVM interpreter, but it didn't quite fit my needs. I'm still not a huge C++ fan, but anyone that will flat out deny the benefits of OOP for some specific classes of problems like UI programming and some game logic is bordering on being a luddite. I still don't think it is beneficial everywhere, but, if anything, I think we are behind the curve on making the transition.
Hmm. Use the best fitting tool. But even a die-hard success phenomenon like John Carmack seems to think OOP is good for things link UI AND game logic. Not everywhere. No argument from me.
Jeez, I think he essentially can be construed as having called the author of the original post a luddite.
I tend to agree.