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 problem is that people tend to only code methods which are needed for their particular use of the object in question. And why shouldn't they? It makes for leaner code. It also makes for horrible reusability, because later when you try to the use the same object for a different application, you generally have to get under the hood and rip away at the guts to refashion it for YOUR use. This of course completely sidesteps the whole point of encapsulation and data hiding in the first place.
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
Of course, you only gave two solid examples, admittedly from two of the best known and most respected men in the field, but still only two.
Even with a third, I'm sure Bryce wouldn't back down.
PJRC: Electronic Projects, 8051 Microcontroller Tools
one common misconception is that one can not do object oriented design in C, or any language that isn't approved by the OOP zealots...
one can create objects in C by...
Yes. But by doing that you're sacrificing the compiler support.
And IMHO it's the wroing parts of OOP that get the hype. Encapsulation and strong type checking rate higher for me than code re-use or some aspects of inheritance (though polymorphism is right up there).
One big thing about languages like C++ is that they give you a way to express your intent regarding encapsulation and data hiding to the compiler and related tools, which then check them for you. (I'd say "enforce", but C++ also has ways to express your intent to deliberately violate the normal boundaries.)
It's really instructive to look at the "things to check for in a walkthrough" section of Miller's book on software quality. There are four pages of essentially one-liners describing the easy errors to make in languages like Fortran or Cobol. And with C++ they're vitrually all impossible to generate without producing, at a minimum, a compiler warning.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I think, far and away, the best part of this article, is the part where he takes vague numbers from studies of large (2+ year before initial shipment) development efforts and tries to apply them to products that can go through 10 whole number versions and get abandoned by the roadside in 2 years. The slowdown he talks about in the beginning of an OO dev cycle is partially proportional to the length of the dev cycle overall - NOBODY spends 3 years developing objects for a 3 month project, no matter how fanatical their devotion to OO.
-=Best Viewed Using [INLINE]=-
...As if the world owes the concept of interface to OOP.
The concept of a wall socket is very old. It's so old, it's even present in UNIX. Look in your /dev/, and the interface that your devices are programmed to. The author of the web page is right; OOP is claiming a lot of inventions that are not it's own...
It's too bad. I wish more computer scientists look at computer science history, rather than the "Learn SQL, C++, and make a bunch of money" book shelf.
As someone who has done the exact same kind of programming that the author of the article talks about: small to medium software packages for business, mostly in-house, custom stuff to get the job done. I can sympathize.
However, I don't think his real issue is with OOP, but with general programming practice in that sector. None of the developers with whom I worked took the time to actually design anything. They jumped in with their first idea and hammered at it until it "worked." They didn't care if there was a "better" design or a better way to do something, they just wanted it to work and for the customer (i.e. some other division of the company) to be happy with the software. If it came back for bug fixes later, oh well, that's what keeps us employed.
The real problem is not with OOP itself, but with the kinds of OOP tools (often linked to some RAD package) that are heavily used in this area and with the fact that so few of the programmers have the time to actual do design or code review. The managers were constantly telling us to review each other's code and to design everything, but no one ever did, and what passed for a group code review was a joke. No one actually looked at code. The lead programmer, often the only programmer, for the project stood up and gave a "best case" (i.e. outright lie) description of how the code works. Later, when some poor schmuck (i.e. you) has to maintain that very same code (which you were not involved in designing or coding in the first place) you find out just what a mess the code really is. The software more often than not did not even begin to approach the design discussed at the "code review."
Nah, the problem isn't with OOP, 'cause I have personally seen massive improvements in my coding since I've started using an OOP style with thorough documentation and formal notation. The problem is that in the very sector the author is complaining about, the vast majority of programmers are mediocre, and the managers (who don't do the work, but pick the tools and "methodology") are even worse. The problem is with buzzword programming where you pick tools because they are compliant with all the latest buzzwords, not because they are right for the job at hand, nor because your programmers know how to use them, which the majority don't.
Some folks need to go back to school!
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
one common misconception is that one can not do object oriented design in C, or any language that isn't approved by the OOP zealots. this is just not true, while it may be more natural to write a good object oriented design in C++, Java or Smalltalk. it can also be done in C or BASIC.
one can create objects in C by creating a structure, then passing that structure to every method that performs on that structure. a common use could be something like this.
struct window_t win;
window_init(&win)
window_draw(&win);
window_destroy(&win);
it is also possible to perform polymorphism and inheritance with function pointers and other techniques.
-Jon
this is my sig.
> Pray tell, how does run-time instantiation have anything to do with either encapsulation or abstraction?
Simple. You can do abstraction in anything, even turing machines. Encapsulation is done in objects, otherwise you don't have encapsulation so much as namespaces. Not much encapsulation going on if you only have one capsule, neh?
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
I've always liked that saying (in various wordings):
"If you give someone a hammer, problems will all start to look like nails to him."
To really drive the point home, I like to add:
"...and what would he do if given a screw?"
There's also a response that I came up with once when a friend and I were talking about the coolness and power of some particularly cool and powerful Lisp-related thing (lest my previous post and/or my sig make me seem like just an old-fashioned C hacker):
"A sufficiently powerful hammer can turn any problem into a nail."
David Gould
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
I gave up and decided to write in Python. It's still kinda complicated, but at least that's just because the code is doing something complicated.
Need a Python, C++, Unix, Linux develop
Actually, it's worth noting that the original C++ implementation was a precompiler - it translated C++ to C. (I believe that this would be very difficult or impossible to do with today's C++.)
Can you do object-oriented stuff in C? Yes. It's often hideous, though. Motif was one such attempt. The horror...the horror....
The key attributes to a well-structured program (OO or not) are encapsulation and abstraction.
Can you get these in C? Yes! File scoping is the most underappreciated feature of C; it's often negelected because of poor revision control systems that end up encouraging a one function, one file paradigm. When you use it properly, though, you can put code and data members in a package with well-defined interfaces and the option of private data members. It rocks.
Can you screw things up by inappropriate use of OO strategies? Sure. Object-obfuscated designs with spaghetti inheritance are common, and are usually caused by becoming infatuated with inheritance and polymorphism at the expense of encapsulation and abstraction.
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
But it's not the global shift operator that's been overloaded, it's the shift operator associated with cout. Although it's not an oo feature as such, it is dependent on it. I.e. you're effectively doing cout.print("hello world").print(endl);
Rich
cout However, I wouldn't dream of claiming that the program is "object-oriented" simply because C++ is perceived to be an "object-oriented" language.
You know what? cout is an object oriented function! You can send it strings, characters, integers, and floating point variables without having to indicate to the complier what you are sending, as you do when using printf() in C. Try a better example. In fact, since C++ is a superset of C, I would submit that THIS is a truly non-OOPed C++ program:
int main() {
printf("%s\n","hello world!");
}
Now, THAT would compile with g++ and doesn't use anything OOP.
There is some truth in this, in the general case. When something is easy to use, you don't need to be a professional to use it. And when you're not a professional you will in general make a less-than-professional job of it, even if it looks OK to you --- you just don't have the background to judge good from bad.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
I wouldn't put down those who write in Perl that much as being anti-OOP. There are many, many of us who write and like OOP in Perl (it's especially useful to read Damian Conway's "Object Oriented Perl" to see the beauty of Perl's OOP.)
OOP in Perl, actually, is much more fun than other languages because of it's flexibility. For instance, Class::MethodMaker is capable of creating accessor methods for various types of data members of objects at compile-time; this is a beautiful thing. Perl's flexibility has a whole lot of other things that allow fantastic OOP, and "Object Oriented Perl" expounds on much of this.
You're soaking in it, and probably have been for years!
The chief objective of computer programming is too create useful things. Elegance is tremendously valuable but secondary. NO OTHER interactive message board has come close to Slashdot in terms of useability, readability and even whiz-bang features.
**>>BELCH
How small is a small business app?
Didn't the author say that this is a question that needs study?
We have both enterprise-scale and small-business scale versions, but neither would survive long as a procedural app.
And your still a software house building apps for other businesses. The software you produce is your product, so you expect to extend and improve upon it. You don't expect to throw it away at the end of the quarter/project/fiscal year. It wouldn't last long as a procedural app, but the authors point was that most of the software he has been commissioned to produce doesn't last long...period.
Moreover, the enterprise "niche" is the greater part of the software market.
Your point being...?
There's no reason to object-orient the shitty little linux apps that you use, since they are usually 1-2 wannabe code monkeys writing bad C++.
OK. A personal attack. So if someone disagrees with you then their applications are shitty and they are code monkeys. Or is it that when someone buys the hype and uses the it-applies-to-everything sledge hammer to build a picture frame and ends up with a mess, then they are wannabe carpenters. Oh, and by the way, Chevy's suck.
Any multi-employee project requires the kind of abstraction that only OOP provides.
So you're saying that there are no large projects except those using OOP techniques?
I read as much of the article as I could stomach before his baseless graphs and lack of data made me stop, but I saw enough to know an Epsilon Minus Semi-Moron trying to sound academic.
You couldn't stomach what he had to say because it challenged your close minded view of the world. The author didn't present data, because (as he repeatedly pointed out) there is no data to present. OOP is hyped as the next big thing, but no one has studied the parameters of when, why, and where it is successful in any meaningful way. He stessed at the start of the article that he was presenting his view of the world and where he was oriented in order to have that view. His article was a data point and asked questions. Scientist and academics don't just present data, they also gather, analyze and question data and assumptions. Assholes and idiots, on the other hand, resort to name calling and flaming when their ideas of their own superiority is called into question.
It was a pathetic article, and anyone with a college degree and a smidgen of programming experience would tell you the same thing. It certainly provided a lot of laughs in my office.
There are a lot of people with college degrees and lots of programming experience who would say that it is a quite well thought out article. Many with the same credentials would say that the article is mediocre flaimbait. Either way, if this is what produces laughs in your office, then you need counseling.
Overall, the author tried to point out that no language is appropriate for all projects and tried to set parameters where one language/style of programming would be better than others. Of course, some people who only know OOP, believe that OOP solves everything and get upset when someone suggest differently.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
How people like just get it instead of getting gone right. If you start your project does not matter which language you use or the programing method as long as you choose the right right for the job. At school people are always asking way I use c instead of c++ I simply say I do not need c++ right now therefore I do not use it.
But what evidence do you have that these concepts lead to good design
Holy cow, did you even read the part of my post you are quoting? I said it DOESNT lead to good design. Good design has nothing to do with the paradigm you're using. You must have been in a seperate universe or something when you read my post, you've missed the whole point.
I think you'd better have a look at this, pal.
http://www.angryflower.com/bobsqu.gif
Apostrophes are certainly NOT used for plaurals in any way, shape or form! I think I know who needs a slap in the face...
Orbix. Bwwhahahaha! We ditched that for TAO (a free open source, standards complient ORB). Even if Orbix were the fastest, the cost you pay in bugs, non-standard implementation and dreadful customer more than outweighs any benefits.
It's 2 years since I used it. Back then it felt like a bad port from UNIX to Win32. We couldn't have any COM DLLs talking to our CORBA services. Why? Orbix spawned some threads and provided no way of deleting them. This caused crashes when the COM DLL unloaded, or it caused a crash on exit as the process shut down. Unusable.
Looking through the sources of GNOME and GTK is quite a trip--it *seems* well-organized, and probably is. But the language idioms used are frightening--it's C, and legal C at that, but at what cost? No one offers training in this dialect--universities use object-friendly languages when teaching object-oriented design, and businesses use object-friendly languages when they need object-oriented design.
The clearest book on C++ I've read comes in near 1000 pages. If I want to contribute to most GNU projects, I have to generate the knowledge of their equally complicated pidgin OOP-C for myself by staring at reams of barely-commented source code. If written in C++, the code would be identically fast and have 25% the footprint, and probably fewer bugs too. But RMS says no, so they don't do it that way.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
A company named Thoroughbred has an Object-Oriented programming environment built around Basic called OpenWorkshop. The company I work for has a several million lines of code written in it.
Now, I'll be the first to admit, their idea of "objects" strains the definition a bit, but with a very loose interpretation of what OOP is, this fits the bill.
NO CARRIER
I would claim that any well-designed procedural app looks a hell of a lot like an OO app. Relational and object are technologies that can go together, they are not mutually exclusive concepts.
I see nothing inherant in OO that really improves maintenance in the business domain. Inheritance does not model business things well, and OO's version of HAS-A is messier than procedural IMO because you have to have an object reference attached to lots of stuff and find a class to stick every method into, even if it should be self-standing.
Inheritance != OO. Inheritance is a necessary property of an OO language, but that does not mean one should use inheritance every chance you get. Properly used inheritance is like a good spice--use it sparingly. A sign of a bad OO system is one with deep and/or complex inheritance hierarchies.
The advantage OO has is that it is a discipline that describes how you write well-designed components. Procedural is not analagous to OO, as it does not prescribe in any way how you properly design your code.
[quote] It is a clean module packaging mechanism that encourages cleaner interfaces between modules [end quote]
Modules are available in some procedural languages also. (Don't bring up state. It was already mentioned.)
I was specifically referring to the benefits of C++ over C, and in the real world many programmers don't even have the discipline to structure C into module definition (.h) and implementation (.c) files, or even to use #ifnedf/#define protected headers. I programmed in Modula-2 for many years, and it's a great language, but hardly an option for most projects today, and certainly lookigng rather dated in terms of features.
[quote] It encourages opaque data interfaces (method access vs public access) which results in less bugs [end quote]
Real-world business example?
How can you feel qualified to write an opinion piece on design technique (OOP) if you can't understand this without an example???
Let me spell it out for you:
If you make a C++ data structure member private, and *only* accessible via methods, then you remove the possibility of people using your class accessing or modifying the data structure in incorrect ways. One source of bugs made IMPOSSIBLE.
BTW, who said anything about business programming?
If anything, this tends to create set/get bloat--One of the silliest structures that is just crying out for some sort of cleaner factoring. Also, they can often be replaced by good data dictionaries.
Usually the data structures involved would be something more complicated than a variable that can be "set or get"!!!
With your comment on data dictionaries, you again seem to want to limit the discussion to business, and specifically database related, programming! Odd.
[quote] It makes use of self-initialization/cleanup (constructors/deconstructirs) that avoid a whole slew of programmer errors. [end quote]
I just got chewed out by readers who claimed that defending my garbage-collection myth was a strawman because nobody believed except a few dummies.
I'm talking about C++ constructors and destructors period. Who said anything about garbage collection??
In short, you are comparing C to C++. C is NOT the pennacle of procedural/relational programming.
Is this meant to be a practical discussion or not. In the real world there are very few widely used languages. Outside of the modern scripting languages like Perl/Python/etc, and leaving aside specialty anguages like VB, you've basically got C, C++, FORTRAN, COBOL, Java, and Ada if you work in the defense industry. Where's your pennacle [sic] of procedural languages? Ada?
[quote] The self-containedness of objects does make code reuse simpler and less bug prone. [not quote]
Specific example?
Huh? Are you challenging that statement???
Perhaps you think it's easier to resuse code when there's MORE to think about and get right, rather then LESS?
Again, these all sound great on paper, but when specifics are looked at by the non-indocrinated, the ugly grey of OO thinking starts to ooze out.
I'm neither talking about on paper, nor am OO "indoctrinated". I've been programming for over 20 years in languages including 6502/Z80/68000/16032/x86 assembler, BASIC, FORTRAN, COBOL, Algol-W, LISP, Pascal, Modula-2, C and C++. IMO C++ is simply the best general purpose language available today for utilizing the sound prgramming techniques I've learned over the years, and OO is to a large degree just a modern name for design techniques that have been around for years, but are now better supported.
Just because many people don't understand the definition does not mean that the definition is vague or watered-down.
Anything that is "not at the right spot when you need it" can be blamed on "lack of encapsulation".
I would more likely blame lack of coherent design. But lack of encapsulation can result from the programmer hacking his way around the encapsulation to solve the problem.
Note that many of the goals of OO can be achieved in ways that are not necessarily OOP.
Agreed.
--
"I have a good idea why it's hard to verify programs. They're usually wrong." --Manuel Blum, FOCS 94
Can you get these in C? Yes! File scoping is the most underappreciated feature of C
Pray tell, how do instantiate a file at runtime?
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
> To use a language (any language) you have to grok it
I don't know why, but I just can't stop chuckling after reading that
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Yeah, exactly.
So, maybe I exaggerated with the "massive improvements" bit, but I'll tell you that it's certainly more fun to code using some kind of plan/design. In my case, usually OO, and usually in C, C++ or Perl. Nothing better than reuseable objects if you ask me.
At my previous place of employment, there was an attempt made to do that very thing: build a reuseable framework of objects for the business software. There were problems galore with making this work because one of those drag and click types of commercial "programming" tools was chosen, where you create graphical objects on screen and then add code inside the objects, code that's tied to that graphical representation and to that object. In other words, the code was not factored at all, and if you needed a different widget, or even no widget, that implemented the same business rules in code, then you had to rewrite the functionality from scratch. Very poor planning, and just shows that the problems with OO are not really problems with OO but with OO that is misapplied by developers who don't really understand the paradigm.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Sparingly is not the same as not at all.
What is left? Encapsulation? That is a loaded issue because what aspect to "encapsulate" by is not cut and dry.
Encapsulation, polymorphism, and abstraction. And encapsulation is the big piece. In OO parlance, it means to capture the data behind a concept along with its behaviors--and not expose that behavior and data willy-nilly to the public.
So OO is all about component design?
Not entirely, but it is the most critical element. An OO language is simply a language that maps well to OO component designs.
But there is also OO analysis.
That does not sound like a majority OO fan stance to me.It is probably not what you hear from the inexperienced Java and C++ programmers who think they know OO because they are using an OO language. However, most OO experts will tell you the language and the technology only have a secondary importance to the OO-ness of a system. It is the design.
Besides, the making of components themselves are not what most custom application programmers do. Does that mean that OO is nearly useless for them?
What are you talking about? Custom does not imply not componentized. A custom application can be built from existing components. Similarly, just because you are writing something for the first time does not mean it is not a component.
Procedural tends to emphasize grouping (encapsulation) by actions, while OO tends to emphasize grouping by nouns. This is perhaps an over-generalization, but seems to hold true time after time.
This is a crude description that serves only to help someone who has no understanding at all of the difference between OO and procedural so they can get an initial grasp of the concept. OO is about modeling a system, not programming. It looks at the processes to be modeled, aka use cases. Note, OO starts with actions! The system then looks at the things involved in these actions and the ways in which they interact. Then classes are built to model the things and their interactions. OO is things and their actions, procedural is nothing more than actions. And that is why procedural applications are poor models of the processes they are supposed to be modeling.
RDBMS systems are certainly usefull, nobody said they weren't. However, OO databases do partition things more naturally, at the cost of performance. Often RDBMS systems are wrapped by a middle ware layer to hide the complexity and emulate OO behavior while retaining the performance and scalability associated with RDBMS systems.
Comparing OO Components to procedures is just plain silly. They are different concepts. Read Szyperski's book on components (and yes, non OO components do exist).
"The real world does not give a rats behind about fat-type trees. It will change any way it feels like."
The real world is also full of fools who make the same mistakes over and over because they think they are experts while in fact they are not.
"A graph-oriented approach like relational modeling and HAS-A relationships model this aspect of the real world better."
You should take a look at adaptive programming and aspect oriented programming. (use google to find the relevant material). Both approaches extend the OO paradigm to support what you want.
Jilles
No, you appear not to understand OO encapsulation at all. The aspects you speak of are nothing more than views of the object, and it has nothing to do with encapsulation.
OO encapsulation actually works very well in the real world. Consider, for example, the use of a Date object instead of a char array or even a long. With the Date object, you have one place to fix your Y2K problem if you made the mistake of storing the date internally in the Date object as a char array with the year in 2 digits. If you make the same mistake in the procedural world, you end up with a big ass bug that costs a hell of a lot of money to fix.
Look at something like the OO Visitor Pattern. That is the mess created by increasing the aspects by *one* dimension. Add another, and kapoof!
If you think it is a mess, then you do not understand the pattern. The Visitor Pattern helps eliminate the mess the same code would otherwise have in either OO or procedural realms. And, the Visitor Pattern is also overused in places where it is not appropriate.
Close enough. Languages should only support fairly common things, not blue-moon things. Otherwise, it ends up being and electronic packrat or offer arbitrary features for bored programmers to futz around with (and they *do*).
Ugh, it is not "close enough". It is nowhere near close enough. Most classes in an OO system will inherit from something else. Sparingly means that your inheritance trees are simple and shallow.
Yeah, everybody bashes everybody else's modeling techniques, even WITHIN the OO community. This is what happens when there are no metrics. Metrics are the cops of ideas.
First, this paragraph changes the argument. Your original point was that a lot of OO "fans" seem ignorant that OO is about design, not coding. Now you say that the problem is everyone is bashing everyone else's modeling techniques and there are no metrics. A different argument.
On the new argument, however, you are still wrong. There are formal processes, with the Unified Process being the most widely accepted process. And as with anything, there are expert OO modelers and there are wannabes. Expert OO modelers are getting the job done.
I hope you are not one of those who try to generitize everything.
Nothing I said suggested I do. So the rest of the paragraph that follows is meaningless since it is based on that assumption. However, your claim that you can never have true genericity is absurd as trying to make everything generic. What do you call the Date class in Java?
On use cases, This is not really OO, per se.
Uh, yes it is. It is the starting point of OO software engineering. Non-OO processes do not model things in this manner. They start with workflows and decision trees, which are very, very, very different from use cases and object interactions.
The rest of your post is on how you think your tables and procedures are the best models for a reporting system. First of all, your dismissal of OO for this problem shows a poor understanding of how the modeling should be done. ER data models are nothing more than collections of DATA and ways of relating the DATA. While the data is data about things in the real world, the table structure is only indirectly and poorly a representation of the thing being modeled. The result is that systems relying on the relational database as a model of the business processes end up being difficult to impossible to maintain over the long haul.
I'm not really that concerned with convincing anyone, in truth. If there are good tools available and you choose to make your own work harder by ignoring them, it's no sweat off my back. :)
However, here's a quick example where OO excels. I was in the game industry for many years. Virtually all games involve a bunch of "things" moving around on the screen, anything from spaceships and laser beams to puzzle pieces falling from the sky.
For years I struggled trying to reconcile the fact that all of these "things" are very similar in many fundamental ways. They all move around and bump into other things. They all need to be saved to disk and loaded again at savegame time. They may need to blow up or otherwise be destroyed when certain game events happen. And of course, they need to display themselves on the screen somehow. Yet they are all very different - the logic that controls, say, an homing missle is quite different from the logic that controls the player character, for example.
During this time I wrote hacks involving void points, casting, functions with huge "switch" statements at the top to try to figure out what something was, and other roundabout ways to handle all the similar functionality of these things in one place, yet still allow for all the special code that goes with each type of thing.
OO solved all of that nastiness for me. It pretty much works the same in the end, but it's much easier to code, and *vastly* more maintainable. I can now make a base class entity, and derive all my specific types of things from them. I have virtual functions for Move(), Collide(), AI(), Update(), Draw(), which have defaults, but I fill them in with special code for each type of thing, and I never have to duplicate my basic motion/collision/whatever code, nor are there any messy hacks to be able to put all these types of things into one giant list of entities, but still have each thing "know" what it is and how to behave.
It's more complicated than this, but that's the gist of it. Every game company I've worked at has used this scheme almost exactly (although the terminology may differ) because it works so well.
Who said anything about hierarchies? OO doesn't have to be hierarchical at all. Few OOLs require all objects to be derived from some base class. C++ certainly doesn't.
A Government Is a Body of People, Usually Notably Ungoverned
All the things you've mentioned are compiler isssues.
FunOne
FunOne
trying to do everything with inheritance is bad (every non-novice OO
programmer agrees), and secondly that you don't support for classes
and objects to get the benefits of object orientation (but you need
first-class functions and dynamic/existential/abstract types, obvious
to the LISP world for over twenty years).
Object orientation makes it easier to manage changing interfaces.
Support for object orientation makes it easier to achieve this in
programming practice. The author seems so upset about bad designs he
has encountered caused by an inflexible, deep inheretiance that he
seems blind to the fact that OO support can facilitate good design.
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 problem is, humans tend to think in terms of something acting on something else. With the data and methods mixed together, it feels like building a house by 'asking' the nails to hammer themselves rather than 'asking' the hammer to act on that nail.
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.
Properly implemented, code re-use can pay off immediately.
:)
I don't know very much about OO -- I learned about it at University (in Eiffel) but it never 'clicked' and I always found OO design to be something of a strain. I only mention this to demonstrate my bias
However, you seem to be implying that code re-use is something you only get from OO, and that just doesn't make sense to me. I really only code in C and Perl these days, and I reuse code all the time.
--
And I've seen at least one OOP project go down the tubes because the designers, among the smartest people I've ever met, treated data persistence as just another implementation detail--they had been seduced by the model of a computer that never fails and has unlimited memory.
But one of the most successful projects I've seen is one where an object-oriented framework provided a transportation and communications infrastructure on which table-oriented applications could be developed. OOP gave us just right level of hierarchical abstraction to make platform-specific issues irrelevant to higher layers; at those higher-layers, the mind-boggling flexibility of table-driven rule sets provided a potent way to model business processes without trying to put everything in exactly one box.
I do believe we are heading for a convergence of sorts. The tables in question are going to be XML, with Java (or pick another OO language) providing the framework in which (and with which) to parse it.
--
This is not my sandwich.
There are lots of paradigms around. You can go ahead and choose your favorite, but let's not make this an OOP versus Procedural battle.
Check out abstract, typed functional programming in a language like SML, O'Caml, or Haskell (I find it's much easier to write abstract modules in these languages than it is to do so in an OOP language). Check out logic programming in a language like Mercury or lambda-prolog. Don't forget the zillions of other genres and subgenres.
C'mon, slashdotters, it's your responsibility to ignore the marketing hype and use technology because it's superior. Do your shopping before you fall for something because everyone uses it (procedural) or because it's buzzword-compliant (OOP).
i totally disagreed with this article, but i respect the guy, why? because he is not just sprouting shit, he wrote lots of materials and preseneted them from his own humble point of view! learn, learn, learn! is there anyone in slashdot, who is willing to write half as that much to prove him wrong? nah, instead the best most of you can do is flame him with 4 line comments. OOP is not a HYPE, yes it has been overhyped, it is not the cure to all as well, it is here to stay.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
It tends to be a little too anti-oop though.
I use OOP and procedural programming because they each have benefits. It enables me to clearly envision the flow of code and make everything modular. It also enables me to manage multiple instances of the same type of object easier. However, it's possible to implement the same functionality in procedural form. And somebody familiar with coding everything as procedures can visualize the code just as easily. If you have used procedural all your life and are familiar with it, then you can perform the same tasks as somebody that is experienced in OOP.
Using procedures, you may have a separate source file for procs related to working with strings. You could also use OOP to declare a string object, and just put all the functions within the object. Note: The above is just an example, don't EVER waste time with string objects unless you are forced to.
It's really more of a personal preference than anything else. Synonymous with your wallpaper. In the end, all that really matters is whether or not the software performs its intended function.
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 just heard someone say that they found an old procedural program of theirs that used too many global variables and too many parameters. Rather than blame his bad programming or lack of knowledge about procedural/relational organization techniques, he blamed the paradigm and used it as a sorry excuse to proceed with OOP.
Ironic given his very long rant essentially pointed at bad OOP implementations rather than OOP as a paradigm!
Of course, I run Cetus Links so I may be biased...
--
Personally I think OOP is okay in some cases© Take for instance Tcl/Tk© Tk is probably the best GUI programming language that I have ever used© Unfortunately that is about all it is good for© Yes you can do more with it, but I think the GUI is is probably the best© Guess what it is done with objects as well© The button, the text the lable the entry, etc© Tk is also not to heavy as far as overhead either© Some may say that java is better, but I have actually tested a simple GUI text editor and the java editor was slower to start and slightyl slower than Tk© I have also used powerbuilder© Now there is a nice OOP language© To bad it is so slow and flakey©
I have also tried C/C++ and the problem they both have it memory management© And lets face it trying to figure out do I need to destroy or free this can be a real pain in the butt©
Personally I'd like to see a language that has syntax like perl, but is compiled and effecient like C© Maybe C with garbage collection© Instead of me having to malloc and free, I'd just declair char * item;, and then maybe item = "string"; Then when I am done with that string I'd forget about it© Sort of like Java, but a language that does not require you to do everything with objects like perl© More like a JavaScript / perl / C / Java cross© Powerscript ¥Powerbuilder is close, but is not a general programming language, it is a propritary language©
Oh and if you look at KDE and GNOME projects, both have major code reuse and one is OOP and the other is not ¥not really, and they are both awesome works of coding©
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
On the other hand a compiler could spend time optimizing this stuff more (maybe more inlining of those tiny calls at least).
The one thing that is a compiler issue in my posting is the poor use of the call/return paradigm (for example using a jsr to make a call, but not ret to get back means the architecture can't do a hidden [branch target predictor] stack cache to keep the pipe moving - many modern cpus, even x86s do this)
Structured programming a fad? OOP a fad? A rather long-lived fad then! Software developers have been using structured programming techniques and OO design for years, and will continue to do so.
Personally, I believe you should program using the style you're most comfortable and familiar with. If you're trying to fit a mold it will slow you down.
That's fine if you're working on a small project with maybe one developer. But if you had 30+ developers using their own techniques and styles on a large project (like the >1MLOC project I've been working on for the last 5 years) you'll end up with an unmaintainable mess. If everyone conforms to a standard methodology and style then at least you can maintain each other's code.
This is one of the differences between software ENGINEERING and code that's been congealed instead of designed. Software engineering should result in a robust and maintainable system. Letting every programmer go off and do their own thing as you advocate leads to the truth in the phrase "If builders built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization!" It sounds nice to let the programmer go off and just write in their own style using their own unique design techniques. But it's terribly naive and unrealistic in the real world.
Oolite: Elite-like game. For Mac, Linux and Windows
snip
And you know what? I've never understood OOP. I just don't "get it." Sure, I understand the theory, but when it comes to real work, I've never understood it.
It's like if everyone started calling the TV a "forbick". Doesn't make any sense does it? I mean, it's a TV. Why call it a forbick?
To use a language (any language) you have to grok it, and think in that language or - in the case of OO - in that kind of style. Your example of calling a TV a "forbick" is kind of right on - the French, for example, call cheese "fromage".
You'll never be a good Francophone if you have to think in English, then translate to French, and say it. You have to actually think in French. Same with computer languages. When I first learned C, I was thinking in BASIC and translating. It didn't really work very well. (BBC BASIC doesn't have pointers for one). It was not until I grokked C and started thinking in C that I got any good at the language. Although it seems natural to think in C then code in C++ because the languages are so similar, unfortunately it won't work out very well. You have to think "object oriented" instead of thinking in non-OO and translating. Once you get to that stage, you'll truly grok OO and its usefulness.
I'm currently learning Perl. I'm trying to start off thinking in Perl rather than thinking in C++ and translating. So far, it's working OK, but I'm still doing things the C way that would be better done the Perl way, so I guess I'm not truly thinking in Perl yet!
Oolite: Elite-like game. For Mac, Linux and Windows
I understand where you're coming from. Everybody's minds works differently. I found structural/procedural programming reasonably straigh forward. When I switched to OO, it felt orders of magnitude more natural, and I never want to switch back. Other paradigms were much harder for me. Functional programming, such as lisp or scheme where a real nightmare... eventually I learnt how do recursion in other languages from the experience. SQL has been the hardest challenge for me... I just don't think in sets like that! That caused me a lot personal grief and stress... I think I'm a reasonable C++ programmer, but when I had to do some stuff the database, I felt incompetent. Eventually I got my mind around that too, but I'm certainly no great SQL guru (and I doubt I ever will be).
Much of this article seems to be OOA, Out Of Ass. The author states many figures such as designing takes 3 times as long with no backup. There are some points but most of the apply to missused OOA&D.
Object reuse only coming after years. Well, I work for a company that is a big user of object technologies. We have our own data access, mapping, and server objects that are our bread and butter, we can go in and have an application up in little time because we don't have to write most of the functionality, just abstract the business logic.
Buy in. That is true, if not everyone buys in the programmers will be pulling their hair out, however this is true in the development contract of many methodology.
Not everything is abstractable/in a hiearchy, true but I find in most of the work I do, it is. There are cases where some of what needs to be done doesn't make pretty objects, but that is the exception
As x approaches total apathy I couldn't care less.
I've been programming for over 20 years now, and, unlike almost anyone here, I've been on mainframes, and PCs, and w/s.
'Bout 7 years ago, I took some coursework in OOPs and GUI (sounds like someone dropping an egg, to me), and what I saw then was this:
1) OOD looked real good...BUT the closer you got
to actual coding, the fuzzier it got (as
opposed, for example, to flow charts), and
2) what OOP appears to be doing is enforcing by
compliler all the good coding practices
that they've been trying to teach for
25 years (y'all use goto's in C,
frequently? how bout type checking?).
What I've seen since then is that it *may* be possible to write good, tight code in an OO language (though I found the person who worked on chips cmts, above, fascinating), the overwhelming majority of coders write *lousy*, bloated code - you want a clipping of Gojiro's (Godzilla, to those who don't know) toenail, and you get the big guy, himself, with a window frame around his toenail. Explain Lose98, or LoseMe, or M$ Office....
Reusability - isn't that where knowledgable management assigns the position of librarian to someone (*sigh*, probably the configuration manager), and they make sure that programmers use existing subroutines? Oh, right, sorry 'bout that oxymoron about "knowledgable managers".
Thank you, some of us would rather master our discipline (check the meaning in the dictionary that doesn't refer to whips), and write good, tight, fast code...that can be maintained by someone else, when we've moved on.
mark
Personally I write OOP only very rarely, but that's partly to do with the nature of my work which is more small program oriented than large system oriented. However, I do find OOP to be significantly useful in lots of occasions. One way that Objects are particularly useful is in extending programming languages. The old style of libraries is somewhat cumbersome and leads to unnecessarily bloated code that is more difficult to read (and to understand easily), whereas extension via object makes immenently more sense and keeps your code (which may or may not be Object Oriented) a lot tighter. Perl demonstrates this excellently since most Perl programs are not Object Oriented, but almost all the "extensions" to Perl that are being written (and being used) these days are Object Oriented.
And in some ways OOP is still playing catchup with older programming styles, it's a lot easier to change languages than it is to change to a whole new philosophy of programming and I think that has shown. OOP is not a fad, it's most definitely here to stay and in fact I think it will grow as more and more languages (other than C++ and Java) take on Object Oriented design and more and more programmers learn when and when not to use OOP.
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.
Ultimately, multi-paradigm languages that can absorb new techniques as they mature, like C++ and perl, will be the winners. I have yet to see a mono-paradigm language have sustained appeal over a five to seven year period.
Unfortunately, the thesis was quickly replaced with some teenage-esque rants that have been noted already.
What seems to have been overlooked is the advantage of OO: code maintainence. In entreprise environments, a great deal of time is spent on project maintenance. Anyone familiar with procedural programming can testify that scanning lines of undocumented and tightly written code can be a nightmare. The old ideals of syntatic efficiency at the expense of readability, while fun and good in the hacker world, don't fit into the corporate world.
OO attempts to solve this problem by introducing a methodology that makes it easier for programmers to make their code maintainable.
This is analogous to the manager that keeps all his notes in his head versus the manager that documents his job and his notes. Both can probably do a great job, but when they move on, which one do you want to replace? I'll take the latter.
All the arguments about procedural programming being faster and easier than OO are moot: it's the nature of the beast. But OO is definitely a great tool for facilitating ease of code maintainence and leveraging past effort.
I can't believe the guy that wrote that post has had any career of significant length.
I wonder how much C++ code is actually OO, though?
I've seen any number of C++ books which are effectively C books, using cout instead of printf, with an object orientation chapter tagged on as an afterthought.
I'll bet a lot of Windows programs use OO to work with the GUI (because MFC makes them) but have an underlying program structure that's procedural to the core.
I've no doubt that OO is heavily used, but you can't get comparisoms just by counting how many programs were built with a C++ compiler.
--
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.
Taco is a perl c0d3r; what do you expect. The relationship between perl c0d3rz and programmers is in the 'distant admiration' category.
Thing is, if you can't do design in procedural code, OO's not going to buy you anything. Projets that buy into the aforementioned hype will fail. A company throwing OO at a projet without investing in training of it programmers will see the project fail. There are some simple OO mistakes that you see new programmers or procedural programmers who've never done OO before. Deriving everything from everything else. Using inheritance for everything. Habits that it's hard to break them of because nobody realizes that they're bad habits.
Do a bit of research though, and you can find ways to be very productive using OO. If the designs are good, it does actually get easier. Buy "Design Patterns" and poke around in the various OO language netnews archives for little nuggets of wisdom and you will find your object designs improving immensely. Read about STL and use well designed toolkits like gtkmm and you'll start to realize benefits from using Object Oriented programming.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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
Seriously, did anyone read this before they posted it?
OOP is communistic?
No references? (Sorry, we lost them...)
A giant stinking POOP image header?
perhaps this should be under the humor category...
For a code example, suppose we have an application that calculates taxes for individuals. A common object oriented approach is to create a Person class and a Tax class...
Nope, I'd just add a calcTax function to the Person class I already had. Maybe this explains why my objects seem to have a lot of functions....
:-)
To take the Tax and People example you have given, you have overlooked the fact that an object oriented approach allows inheritance and lots of other stuff. For example, if there was more than one type of tax T on a person P, one could still call a generic function T.calcTax(P) for both InheritanceTax and IncomeTax classes which inherited from the basic Tax class.
Object Orientation is not an answer to Life, The Universe and Everything. And you often find that one persons idea of an object oriented approach to a problem is totally different from another persons idea. But having said that, I find that it is easier to work out what someone has done if they have used an object oriented approach than if they haven't. For one thing, most people implement all functions of each class in a single file named after a class, something you're never quite sure of with a parameter approach.
Object orientation simplifies maintainability, by encouraging people to write in a style which may be easily understood, something many other methodologies have singularly failed to address.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
OO does not bring benefits for all projects. OO does not always bring short term benefits. Where OO excels is maintainability and understandability, as well as distribution of labor for a medium or large scale project. A 15 hour project is nothing. Worst case if you need to expand or maintain that project, you waste another 15 hours. A large scale multiple year project, however, truly benefits from an OO approach.
If implemented with discipline and knowledge, an OO project is better maintained than a procedural one. However, I would take a disciplined procedural project over a messy OO project. The overall guiding point is rigorous software engineering, and OO provides some language level discipline, while procedural programming provides nothing at the language level. If a good process is followed, though, language level support is just convenient fluff.
Russell
The author is correct that OOP won't solve every problem. But he tosses the baby out with the bath-water! The author obviously hasn't read any of these great books/articles:
.pdf for this one)
What is Object-Oriented Programming? (Link to papers, since I can't find the
Multiparadigm Design and Implementation in C++
Design and Evolution of C++
Now I'm not saying C++ is the end-all and be-all, but every language was designed to solve a certain problem. Use the right tool for the right job! If C++ lets you solve your problems quickly and efficeintly, then use it. If not, then use what works.
You obviously have a situation that calls out for OO design and programming. Now explain how that means that absolutely everything to be programmed has to be programmed in an OO language.
What I got out of the article (which I thought was poorly done) was that the problem isn't OO itself, but that OO is being overly applied where it isn't needed, and even where it gets in the way.
now we need to go OSS in diesel cars
... 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
The key is as you say: properly implemented. Too much oop has been implemented by the sorts of folks who will term a database as "almost relational". It takes intelligence and rigor to make sure that the corners are not cut that will reduce your small amount of oop to a very large amount of smoking oops.
Wow. I think /. has been seriously trolled this time.
I agree that for some applications, making an object->relational mapping is just a giant pain in the flipper. For the kind of timelines project managers impose on web projects, and the terrible ever-changing specifications given, it's usually easier to fill up an Oracle table and worry about elegancy later. This guy is probably recovering from wounds from some sort of overanalyzing OO web consultancy, having been forced to wear UML diagrams as underwear.
Technology is rarely the problem -- the usual problem with projects and OO is that the zealots win, and centrists who want to use the most-suited technology for the specific application get ignored or called "hacks". The over-ambitious 3-tier agent-based project gets canned, and the "hacks" get called in to fix it using a less long-bearded method.
Agreed. Frankly, I nearly stopped reading him when he mixed up OOP with poor business practices.
Beyond that, he pointed a lot of problems with the way people design OO models that aren't necessarily a design flaw with OO. For instance, his argument about the dangers of 'IS-A'. From what I've read (Design Patterns), IS-A is pretty much regarded as less extensible than has-a. When you can use a has-a, use a has-a. If you want to use a is-a, think twice about if you really need to use one. But no, an OO language does not loose a lot of its benefits as compared to procedural when you use has-a. Modules do not have state. Objects do, which is frequently important.
I think the last straw for me regarding this article was the unclever section comparing OOP to Communism. Gee, a social movement failed, therefore a programing methodology will fail too.
--John
I don't think its a fad. Structured programming is still the model we use, even when using it within object-oriented programming.
r in ginheritance.html
The guy who wrote the article missed one of the most important aspects of OO, and that's _interface_ inheritance. Interface inheritance is _NOT_ subtyping, and is vastly more flexible and usable than subtyping, which seemed to be one of his big gripes. If you want to know more about interface inheritance, look at my page at
http://members.wri.com/johnnyb/comppapers/facto
I called them "feature factors" here.
Engineering and the Ultimate
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.
First let me admit that I didn't read the whole article. I skimmed it and I read the Table Oriented Programming article (which is linked to in this article and presumably written by the same person) about a year ago. I believe that this OOP criticism page was around at that point. Although it is hard to take this page seriously (the comparison with Communism just killed me), I think I'll comment on a few of his points.
If that's true then why did I get all that Y2K work back in '98 and '99 fixing 5 to 10 year old programs? I think here the author is refering to the data part of the object, not the logic. If so then this is a very good point, but its not an argument against OOP. Its an argument for "future-proofing" your system. Here I just think its funny that he lumps C in with Java and Pascal as a "strongly-typed language".I'd like to add that IMHO, OOP builds on procedural (structured) programming. It usually allows better abstraction than procedural programming, just like using C allows better abstraction than assembly language. In general, abstraction is neither good or bad. As systems get larger and more complex, however, its necessary.
To understand what's right and wrong, the lawyers work in shifts ...
Poor design and algorithms is a much greater cause of inefficency than the fit of C/C++ generated code to a processor's architecture.
Anyway, 99.99% of programs don't need anything approaching the full performace of a modern processor, and those that do (such as games, speech recognition, media encoding) are always going to have been heavily optimized anyway.
Like I said, I understand the theory.
If an object is data with functions, then I've been doing object-oriented programming all my life. Even with assembly. Sure, it might not have been in the code, but each bit of data I was working had a function associated with it.
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
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.
Abstraction is the most important and useful thing you can do as a programmer. It takes many forms, but no matter what paradigm you're working in, programming is all about abstraction. It's the simplest thing in the world: when you find two or more sections of code in your program that look very similar, you ask yourself, "what is the common ground here?". In doing so, you are engaged in abstraction.
OO is simply a way of exploiting this abstraction to maximum benefit. Because abstractions can pay off so well, you are encouraged to find them. As a programmer, you are not paid to be a typist, you are paid to think. Thought in general is part imagination and part abstraction. If you are not capable of finding such abstractions, it is not because OO is inadequate, it's because your skill is inadequate. So should you accept your incompetence, or try to better yourself? The author says you should just accept it and choose a paradigm more befitting your lowly intellect. I disagree with that.
Is OO oversold? Sure - people do expect to gain benefits magically just by using OO languages and tools. There is no substitute for talented people. And OO is not appropriate for every project. But there are a lot of examples of great things that are nonetheless oversold. Look at the Nasdaq for example.
I found the article to be pretty weak. He shows pretty graphs without citing references, and seems to be shaking a stick at OO more than anything else. Though he makes a few rational arguments, for the most part it's fairly obvious sophistry.
but I insist. What's the point o programing in Objects in a Lenguge that doesn't support them?
I think you must choise the Methodology AND the lenguage in response of a problem.
In the end all code became assembler. but I won't program a SO in Java, for instance. Or Object in VB, as I see somewhere.
I'm from Argentina: Tango, Asado, Mate, Gaucho, Maradona, YPF
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?
Yes, those dastardly Lenninists are at it again!
In their most fiendish and heart-chilling conspiracy ever they are targetting the free worlds most valuable intellectual resource! First they created a godless empire ranging across europe and asia. Then they sent their agents to infiltrate america. Then they tried to corrupt the youth of the free world with their underground beatniks and seducing the young into the sloth of hippydom with drugs and satanic music. Then they tricked us all by pretending to dismantle their empire, lulling us all into a false sense of security.
Don't be fooled by marxist plots! They are still hard at work, and they have infiltrated into the most valuable resource of the information age - they are corrupting our programmers!
They have put their best agents into key positions in the programming world, and unleashed the most mostrously conceived pinko commie plot since the flurodation of water!
Boris and Natash say: "Java and C++ vill destroy the evil capitalist pig-dogs".
B: "Gorsh Rocky, what can we do? Boris and Natasha are running amok!"
R: "I don't know Bullwinkle - but we must warn the honest IT managers of America to reject OOP"
B: "Hey Rocky, watch me pull Fortran out of my hat!"
R: "But that trick never works!"
B: "This time for sure. Presto!"
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie -Noel Godin
OO is a design technique and OO systems can be implemented in Assembler (like CICS/IDMS-DC) all the way to Smalltalk.
Brooks in "The Mythical Man-Month" talked about the difference between programs and systems back when they were building OS 360. The complaints talked about here aren't limited to OO.
However, every non-trivial implementation of any successful system can be shown to be OO in design and technical every failure can be shown to have violated OO principles (that's not counting management, direction marketing and every other reason for failure.)
Most systems tend to become unmanagable because the peoplle in the trenches doing the maintenance get "too busy" to maintain the documentation and rely on osmosis and oral tradition to pass on the system lore. Things get lost with ever departure until its necessary to start over again. ("Read the code" has NEVER worked for more than trivial stuff because the code only caries traces of its INTENT and clever programmers tend to obscure that through 'clever' hacks.)
Smalltalk, a best of breed, has several short comings but that doesn't mean it can't be made to work easily. You just have to remember the limitations of container-based implementations.
Java, C++, C#, CLOS, Simula, and Smalltalk ALL share in these deficiencies:
1)Contained object don't know that they are contained unless you explicitely make a reference to the container part of the object.
2)Object instantiation is made without regard to context.
3)Objects don't understand anything about participation in relationships.
4)Class membership tends to be hard to mutate.
When we have a language that can model the difference between the cuppola of the Piaza Duomo in Firenze and a common garden wall, then we'll have something to work with. Until then OO is the best design technique we've got.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
if you think you have a point, go checkout ruby and python. :-)
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
About 20 years ago Pascal was about as popular as C. But C won out because it didn't impose as many restrictions as Pascal ("look, I can cast a function pointer to int..."). And besides, Pascal was developed for teaching good programming practices, not for "real" projects like C. So, being lazy, people started using C, and Pascal faded out of use. Even Modula-2, the "Object Oriented Pascal" couldn't save it.
How many virus exploits would have been averted if Microsoft had chosen Pascal?
That might explain why I'm starting to understand it with Python. Python may be sufficiently different than anything else I've used that it makes me re-learn stuff.
On the other hand, Lisp is also very different, but to me, only syntactically. 90% of the code I've ever written uses dynamic data for everything. I never did #a = $b + $c, it was always add(b, c, a) type things. Which is suprisingly like (setq a (+ b c))
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
The whole reason I was doing the work I was was so that we could discover and address exactly these sorts of issues.
The problem with branching to an unknown offset is - well - it's unknown - and you often don't know what it is untill you've completed a data cache miss to get the address (that's a double pipe break in my mind) - the solution can be things like branch target caches (which make a guess at the target and start a speculative stream).
Remember you're stuck a primary architecture (x86) that are decades old - that were optimized for compact code (at the expense of registers because they were designed for a system with no icache and limited memory bandwidth) that force complex language constructs into overusing the cache/memory subsystem - of course you are going to get data/branch interactions
The other big problem in the architectures we see today is marketting - GHz is all - it's what Intel/AMD's marketting people know how to sell - it's a nice number that they can wave at their competition). It's driving their architects to longer and longer pipes to get the clock rates up ... and reducing the CPI into the bargin I'm sure it has a lot to do with why P4 is such a dog - I bet when their engineers are faced with the question "should we make virtual method calls run faster or shall we make it easier to up the clock speed" the clock speed wins every time - no one's saying lets make the pipes smaller (and clocks slower) so the actual programs will run faster
OOP (IMHO -- I'm crazy for the acronyms today), is just a fad. Like structured programming was before it.. Unfortunately a lot of these companies today fall into "trendy" programming methodologies. Personally, I believe you should program using the style you're most comfortable and familiar with. If you're trying to fit a mold it will slow you down..
The biggest problem with OOP is when people use it too much, and end up with like a million classes.
Example:
class HelloWorldClass {
HelloWorld() {
printf("Hello World!!\n");
}
};
I want my rights back. I was actually using them when our government stole them after 9/11.
C - a language which is one dreadul kluge after another... preprocessors, function prototypes... and yeah, your code runs fast, but you'll wear your wrists out trying to do robust, verifiable programming, the dreadful excuse "API"... At the end of the day, you're still feeding text files into the chute and turning the crank. The whole thing makes me feel like I'm in the 1880's.
And then we have C++. Which has all of C's faults, with some additional syntax kluges thrown in to do "object oriented" code... while keeping C's superior style, apparently. So now in addition to everything else, I have to #IFNDEF SOMESHIT #DEFINE SOMESHIT blah blah #ENDIF. Fantastic, guys. Just make sure you get all of your libraries specified on the command line in the right order... Let alone the fact that when you do RTTI or exception handling the compiler gives you the distinct impression it's doing you a favor. Oh, you want a virtual method? I thought you just wanted to seem object oriented, not actually be it.
Java was a wonderful change from all this, because it simplified and organized the source and sanitized the compilation process. Simply having array bounds checking and garbage collection (let alone the vastly superior and standardized API) made development take up to half the time it would take in C++... and I _HATE_ the VM. I could care less about it. I just find myself amused when people driving horse carts around the back woods get pissed off about the speed limit being 120mph. Our development systems are primitive! OOP or not is a drop in the bucket. The real misunderstood tradeoffs are elsewhere entirely.
We're on the road to Tycho.
Look, folks, object orientation is just one tool of many in the big box of software tools. Use it when appropriate, use something else when it isn't. This guy rants rants about OOP basically on three grounds, all of which are straw-man agruments:
The reality is that OOP is a good tool for solving a lot of common problems. It's also a lousy tool for solving a lot of other common problems. When OOP isn't the right tool, don't use it.
Just use the right tool to begin with. When it comes to programming paradigms, there are lots of tools in box:
Use the right tool for the job. You'll be glad you did. (And you won't have to put up a web site just to rant about your bad experiences with using a hammer to place dry-wall screws.)
Easy, automatic testing for Perl.
This is just my humbl opinion, but in my Software Architecture course, I've noticed that there is something more to all of this than jsut straight up "code reuse"... Architecture reuse is going to be far more important. Sure, we have those nice little design patterns that tell us how to achieve small tasks within our program, but with large-scale systems, recycling the _architecture_ is becoming more important. How do you think Microsoft made Office so rapidly? They used the same architecture, same components, jsut with a little bit of different function.
It's one thing to recycle a few hundred LOC every now and then, but it's a whole different ballgame when you can recycle the plans for a complete system. I feel (and I may be wrong) that this just isn't as easy under the procedural system.
--You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
Disclaimer: not all myths discussed are necessarily shared by all or even most OO proponents. They are based on "common notions" found in the business and programming world as I have observed them. I am making no claims as to the frequency of beliefs in the myths. My frequency of encounter may differ from yours. Discussing myths is not the same as "punching a straw-man", which some OO proponents claim I am doing by mentioning myths.
So... this is based on his experiences, without research? He has based this piece of writing on merely his viewpoint? Surely, if any technical critic wishes to be taken seriously, he should back his work up with proper figures and research, rather than "myths".
Communism also looked good in theory, but its base assumptions about human nature were flat wrong!
Okay... he's comparing OO with Communism? I don't see the connection. Does OO make assumptions about human nature?
This seems far too much like a rant, backed up with a few web pages... I would not take this seriously.
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
You are saying that every language/compiler that runs in a chip/VM is the same thing.
so functional, OO, Imperative programing are all the same. Guau!
No, I'm saying that code that is based on the concepts of inheritance and polymorphism in one language is still based on the concepts of inheritance and polymorphism if it is translated into another language.
We're going down, in a spiral to the ground
Many cases of virtual function calls can be completely optimized away at compile/link time. Read, for example, here.
Yeah yeah yeah, Yeah yeah yeah, Yeah yeah yeah I think I did it again, I made you believe we're more than just objects Oh baby, It might seem like some code OOPs!... I did it again, I played with your paradigm, got lost in the code....
The right tool for the right job. By building such a generic tool, you ruin it's effectiveness. and the article points out that the benifits of reusability only come after years.
But he makes a great point. You can't have all OOP and no procedural skills. and you see it time and time again. If all you know how to us is a hammer, pretty soon everything looks like a nail.
--
Gonzo Granzeau
Gonzo Granzeau
"Nothing the god of biomechanics wouldn't let you into heaven for.." -Roy Batty
"The Object Oriented Hype"
How can a paradigm that has been a foundation of successful application development for years be called hype? That's akin to calling procedural languages hype.
"Personally, I've never been a huge fan of OOP"
I'm not try to convert you, but have you done any serious OOP programming?
What some people don't understand is that knowing how to program in a OO language doesn't automatically mean a person knows how to do OO programming. If a person partitions an application into objects that don't make sense (e.g., an object that should really be multiple objects), then he isn't really isn't getting the advantages offered by OOP.
I've seen programmers try OO languages and say "it sucks". When I look at their code, I tell them their OOP sucks.
Now, I'll be honest. About four paragraphs into the article, I had to stop. I didn't understand it.
:)
I am *not* a OOP programmer. To be honest, I've never been able to understand it. The first programming language I learned was dBase(if you can call that a programming language), and I learned that when I was around 5 or 6.
After than, I learned assembly. 16-bit, 80286-style Intel assembly.
When I was around 16, I learned Borland Turbo Pascal. I've been using computers my entire life. I'm good. Not great, but good.
And you know what? I've never understood OOP. I just don't "get it." Sure, I understand the theory, but when it comes to real work, I've never understood it.
Now, that's not to say I've never used it. I've used it, and used it well. But I never knew why they had to call it "object-oriented". It always confused me. Whenever someone started talking about OOP, I'd have to leave the room. It didn't make any sense. It's like if everyone started calling the TV a "forbick". Doesn't make any sense does it? I mean, it's a TV. Why call it a forbick?
Anyways, I'm beginning to understand a bit more. I've been playing with Python, and I think I'm starting to grasp it.
Ah well, I'm tired and babbling
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
OOP is worth it. It is valid. It works.
It won't work for every project, of course. It only works for projects that can be modeled as objects. Thus, most systems programming is not suited to OOP languages. But most applications programming is. Even the C and Perl programmers know this, even if they won't admit it. GTK is OO, a hackish OO but OO none the less. Use the right tool for the right job. Procedural is good for some things, functional for others. And there are plenty of projects where OO is a natural fit.
Sure, OOP is over hyped. So what? Most things in life are. The article wasn't about the overhyping. It was a thinly veiled attack at OOP, nothing more.
A Government Is a Body of People, Usually Notably Ungoverned
Object Oriented Design is the great idea. It's best for larger projects, but even works on smaller ones, too. It's suitable for use regardless of what language the project will be coded in.
Object Oriented Programming is where start to get bad. An OO language is supposed to be able to readily translate a good OO design into code to compile and run. It does that fine. The problem lies in the fact that vast numbers of programmers don't understand or even attempt to do OO design, and just dive into a project programming it in an OO language, and assume that it will be correct. Afterall, it is Object Oriented so it must be right ... NOT!
Object Oriented Programming shares a problem with higher level languages. By making things easier to do, they make it possible for idiots to actually accomplish something which they would not have been able to do before. For some things that's fine. GUIs allow idiots to use computers. That's not all bad (we don't want to fill out their spreadsheets for them). But when things get into the realm where the person involved has to be smart enough to know about all the problems and situations, such as security, reliability, integrity, and performance, which need to be handled, then it's no time to be allowing someone who couldn't even program in a lesser language at all to be attempting this. Good programming tools should be about making it easier for good programmers to do their task correctly and quickly; not about handing the task off to someone who will just screw it up.
now we need to go OSS in diesel cars
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 fact, I think none of those things are what have made OOP successful. Inheritance and dynamic binding are marginally useful techniques that actually play a role in only a tiny part of most real programs, and there are excellent alternatives to them. (Of course, some methodologies, like the Eiffel/Meyer school of programming use something they call "inheritance" for expressing all sorts of concepts but the same concepts could be expressed just as easily using other constructs, so that doesn't make "inheritance" essential.)
What has made OOP successful is that it encourages its practitioners to build abstractions and to think about how software may evolve and be reused in the future. That would have been possible in reasonable, traditional, procedural languages, but the world needed a gimmick in order to have people listen, and that gimmick was OOP.
However, unlike many people who criticize OOP, I don't believe that "C is all you need" or something like that. I think better languages and better programming constructs are very important for building better software. It is just that the constructs central to OOP don't give you much more functionality than you would already have gotten from a decent type system and function pointers.
But support for runtime safety, garbage collection, reflection, genericity, aspects, and other features is important and allows you to build much more complex software systems much more easily. That's, at least, my experience from using a variety of languages, procedural, functional, dynamic, and object oriented over the last 20 years.
OO systems are not very good at ad-hoc queries
OO systems are in essence Xenophobic
A pitfall of OOP: When all you have is hammer, everything looks like an ... object. Somebody on java.lang.help recently wanted to program a chess program with GUI. They were going to have pieces, and squares on the board. Have each piece associated with a square. It was suggested to them that the board might be best left unsubdivided into squares. A piece could just have a position on the board which would allow it to move between squares for example.
Along the same lines programmers working with tables often try to treat each piece of data in their database as an object. In many instances it would be better to simply look as the entire database as an object and forget about the smaller objects.
One of the reasons that OO is helpful is because you do not need to worry about the format of the data in an object. If you want to use a database or a flat file it is all the same outside the object.
Using OOP it is much easier to adopt a new data format. There is no such thing as an OO way of storing data that perpetuates itself Xenophobically.
The way to do something ad-hoc in OO is to subclass. Usually when you subclass you are saying that you specifically want to deal with how the data is stored and you are willng to accept the consequences. If you data is in an SQL database, nothing prevents your from using the correct tool for the job and also using SQL queries. You just run the risk of making your data unusable to your object. But again a risk that your proceedural program would face as well.
To sum up:
best review of this "article" to date
Seriously, the way the guy goes on, you'd think OOP was the cause of all world hunger and disease.
In my 4 years of doing comp sci at University (which included learning both OO methodologies and a wide variety of others), I can't remember ever hearing a single one of his supposed "Myth"'s. Where did he get those? Perhaps I missed all the hype, but I sure as hell have never heard anybody claiming that OO was the panacia that he seems to think people claim it is.
OOP doesn't do or solve *anything* *for* you. It doesn't facilitate components/re-use - GOOD DESIGN facilitates reuse. It doesn't make programming easier and faster - GOOD DESIGN does. And garbage collection? Who the hell ever claimed that only OOP languages have garbage collection? Now thats garbage.
All OOP does is provide a few extra constructs that make certain types of things more convenient. It certainly doesn't automatically make your program design a good one. That's still up to the programmer. In fact, learning to make good OO designs takes more programming experience than learning to make good imperative designs. Some software designs really *do* fit better onto a hierarchical inheritance structure.
For goodness sake, OOP isn't trying to "compete" with your (insert your favourite paradigm here.) It's just language support for programs structured in a certain way. Choose whatever suits your needs, but for gods sake, its not a 'battle' of paradigms, they all serve different purposes. Grow up.
Actually, most GUI application programmers almost never see the code structure that makes up their screens. They simply click on a screen item, an event selection box comes up (Events like: on_click, on_exit, on_keyboard, etc.), and then a "code snippet" box comes up to edit the event code. Whether that event code is in a method or subroutine does not matter that much to the programmer. If you changed the generated code implementation from OOP to procedural and/or tables, the programmer may never even know the difference.
This is not a programer!
Friends don't help friends install M$ junk.
You can also do OO programming in assembler. In fact, any OO program does get translated into assembler code before being executed.
But what's the point?
You can do any fancy language construct manually in lower level languages. That doesn't mean it's a good idea. If you're gonna do OO programming it makes sense to use an OO language. Let your tools work for you.
Not that I don't get your point but surely the fact that your Now, if you want to stick printf in there, I'm with you all the way
Rich
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
In the hands of somebody that does not understand OO, an OO language can cause quite a lot of dammage. Good use of any tool requires knowledge and you don't gain knowledge by staring at a book for half an hour. This article is provocative, and rightly so. Proclaimers of OO have claimed a lot and OO turned out to fail to be a silver bullet. But guess what? There are no silver bullets.
The truth is that OO languages are an excellent tool for structuring large, complex systems. Simply applying inheritence everywhere you can of course does not work. Using an OO language requires you think differently about how you structure your programs. Some people get this, some never will.
Of course OO has its limitations and there are many research initiatives to work around those limitations or provide alternatives. Falling back to procedural programming is really no option for anything but the most simple stuff. The article points out that you don't need an OO language to do things like components among others. That is true, but it is so much more convenient with a language that supports the concepts you are working with.
Another disturbing statement: "OOP eliminates the complexity of "case" or "switch" statements".
Read Martin Fowlers book on refactoring, it describes how to convert a switch statement into an inheritance based solution (the state pattern). Bottom line, if you understand OO, you know you don't need switch statements. And if you worry about performance, read Fowler's chapter on this topic and you'll see it is not an issue.
Jilles
The same argument as with uptopias, socialist or
otherwise: many detractors haven't really implemented
a full OOP project cycle through maintenance and
re-use with a decent OOP (C++ sucks).
Slashdot poster: "Well, we've been trolled by the best son"
Slashdot moderator: "But dad, you we're the best"
Slashdot poster: (with a stern look) "We've been *trolled* by the *best*
(adapted from Simpsons, can't find the exact quote)
It's 10 PM. Do you know if you're un-American?
Please - someone show me an example of this - and not in VB.
Show me an OOP'ed "Hello World" BASIC program, using a circa 1980 or so version of BASIC...
Can this really be done (and would it be at all readable)?
Worldcom - Generation Duh!
Reason is the Path to God - Anon
I really want to take that guy and slap him about the face, while explaining that "GUI's" means "GUI is" or "belonging to the [single] GUI". It is not the plural of "GUI". Fool!
Does my bum look big in this?
Your posting shows why it is best to use conventional procedural programming for low level I/O and performance sensitive applications - an extremely interesting read.
In short, keep the code small, minimise calls and locate all associated parts of the code together as much as possible. It is possible for the compiler to help but when you link together lots of classes from different files (code segments) it is impossible to do it efficiently.
I spend a lot of my time writing 'Low Level' code, keeping the cache hits up and the pipeline full can make a massive difference to the program performance.
If you want to look at it that way, I suppose assembly language is "object oriented". It's important to distinguish between language features to support a concept, and the existence of idioms to do the same. The more complex the idioms, the more desirable it becomes to use a language that provides the functionality in the semantics of the language. That's why not many people write OO code in assembly.
Surely the output C code was no less "object-oriented" than the C++ code it was generated from.
I bet you wouldn't even want to write it or maintain it though.
Obviously, I have not made use of any object-oriented facilities,
Not that I don't get your point but surely the fact that your << operator is not shifting bits left indicates that you've used *some* object orientated feature.
Now, if you want to stick printf in there, I'm with you all the way
Rich
You know, the only people I've ever seen claim that OOP is so marvelous and is such a panacea, are rabid people like this, who compare it to communism. Really, who is this guy arguing to? Managers? What is he trying to prove? Who really believes OOP==GUI? Or that an OOP product is necessarily better than anything else? I might have believed that someone believed this maybe 15 years ago...but not now.
He's right - OOP is more of an organizational philosophy. In fact you can apply OOP concepts to languages that don't inherently support OOP. And (surprise!) you can apply procedural concepts to OOP languages (duh). OOP is merely a convenient way of thinking about things. Of course it has its flaws, not the least of which is the restrictions of inheritence (is-a/has-a) and the overhead of thinking out and abstracting the problem. But people who use OOP languages without thinking through their problems because they think it's magically going to solve it deserve to get burned (and I guess that's who this article is directed at). But it's just one way, among others, to go about modeling and solving your problem.
Next issue: "Expose: High Level Languages - They're Not All They're Cracked Up To Be! (plus, they're communist)"
It's 10 PM. Do you know if you're un-American?
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.
The athor actually makes a few good arguments, but it takes some effort to get past laughable comparisons like OOP and Communism. Oh well, I don't mind being a Java programmer, comrade.
-- Solaris Central - http://w
C# is the first MicroSoft development product I've
found interesting. (I've been programming five
years longer than MS has been in existance.)
(MS was originally a development products
house before it got into OS and Apps in the 1980s.)
There are languages that are theoretically nicer
like SmallTalk and Eiffel, but not as widespread
or efficient. There are languages very kludgy
such as C++ or a little bit kludgy like Java.
C# larns the best from the C family and is likely
to widespread and efficient.
I really think that the most important OOP benefits of OOP in order are:
1)Information Hiding
and
2) Polymorphism
For instance, were I work, we have standardized on certain method names. Want an object to populate itself from the database? Call it's GetData method. Want it to save itself? Call PutData. We've also standardized that each object tells IT'S children to populate/save THEMSELVES. Want to save your whole data tree? Tell the root node "PutData", and your whole tree will walk itself and save.
No object has to know how to save it's children, it just says to the child "Save Yourself".
We get programmers up to speed on new projects QUICKLY, because the know the basic methods of all our classes.
Can you do this in a procedural language? Of course you can, but it's easier in an OOPL.
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
I think that most of the criticisms that have been aimed at object oriented programming are in fact aimed at particular programming languages and implementations. Object oriented programming has nothing to do with any particular idea of "classes" or "inheritance" or with any particular programming language. I can write object-oriented code in assembly language -- and have done so. There are things that are much nicer when language support exists -- inheritance is not easy to do in "C", for example, while in Python it's as natural as breathing -- but that doesn't make them impossible, merely more difficult.
Finally: I recently was project lead on a large project written mostly in Python. I can attest that an object oriented paradigm saved us a ton of programming time and coding time. Encapsulating generic database table access into a 'dbaccess' class, then subclassing our various tables using that class, for example, saved us a ton of programming time. There are some of our classes that consist of nothing more than the import of 'dbaccess' and the subclassing of 'dbaccess' in a class whose only (non-dbaccess) members are the data type descriptor strings for that table. Being able to say "d=Destination(destid); tape=d.FindFirstTape() ; if t.is_recycled() ... " is not just the natural result of object oriented programming -- it also allowed my team to write a major application in an amazingly small amount of time.
My basic conclusion: Object oriented programming is not a buzzword or a programming language. It is simply how you build big programs -- no matter what language you're building them in.
-E
Send mail here if you want to reach me.
If you want to look at it that way, I suppose assembly language is "object oriented".
There really is no such thing as an "object-oriented language", if your definition is "a language you can write object-oriented code with." As an adjective in that context, "object-oriented" is really only meaningful when it's applied to code. For example, I claim that the following program is legal C++ code:
#include <iostream>
int main( void ) {
cout << "Hello, world!" << endl;
return 0;
}
However, I wouldn't dream of claiming that the program is "object-oriented" simply because C++ is perceived to be an "object-oriented" language. Obviously, I have not made use of any object-oriented facilities, so there is no way that I can make this claim. However, when I write a GTK+ program in C, and I call gtk_widget_set_usize() with arbitrary widget types, including some that I have created myself by inheriting built-in widget types, I can (correctly) claim that I am writing OO code, even though C is not perceived to be an "object-oriented" language.
The useful working definition for "object-oriented language" must remain what it always has been, namely, "a language that supplies direct, language-level support for OO concepts." That does not mean that you're required to write OO code in that language, nor does it mean that you cannot write OO code in other languages that do not meet that definition.
We're going down, in a spiral to the ground
This article can be applied to any kind of programming paradigm. Basically, the author concludes that OOP isn't any good because some developers and managers aren't applying it correctly. Well, that's the case for procedural programming, declaritive, functional, etc. Yes, OOP will not solve the problem of rushed projects, poor management, or stupid programmers; neither will any other programming style though.
Programmers just need to be familiar with multiple programming practices and languages. Programmers need to know when just hammering out some _properly_ planned procedural code will fit the case better than some _properly_ planned OO code. There is no magic bullet and because of this, I think it's a bit pointless to say that one programming style is leaps and bounds better or worse than another.
I really wish the author had the confidence in the claims to actually site some hard facts and not some made up claims. Most of the article just seems like old rehashed FUD from the dawn of the OOP movement. The author mentions all of these failed business apps and blaims OOP for their problems. I guess IBM, Oracle, NASA, and some of the other big software shops are a bunch of idiots for doing any OOP. But of course this guy must be an expert on software design practices and that's why he has a Bell Labs URL.
Welcome!
I am the author of that page.
Rather than do a summary dismisal, how
about specifics. Better yet, meet
the "biz app" challenge listed there.
IOW, put your code where your mouth is.
Nobody has found any objective proof
or metrics which show OO better in
the stated niche.
Less lines of code? NOPE!
Less change points? NOPE!
Better "grouping" NOPE!
(Often it trades one perfectly valid
grouping for another perfectly valid
grouping. IOW, zero sum benies.)
If it is 50 percent better, then proof
would be easy. If it is 10 percent better,
then personal differences are more
significant than averages.
Anybody want to race to the finish?
Table-ized A.I.
tee hee hee
I think the usefulness - or lack thereof - of OOP depends a lot on one's personal learning/working style. Sort of like some people are perfectly fine with abstract mathematics, while others need to relate math to the physical world in order to understand what's going on. Personally, I find it helpful to create objects that possess properties and accessors to get at them. It not only makes what I'm creating more 'real', but it divides the application into nice self-contained chunks that can be dealth with separately.
"If I have seen further than other men, it is by stepping on their glasses." - Michael Swaine
--
--
You sure got a purty mouth...
it's still gonna suck if you use OOP.
OOP has it's place, like everything else. Tools should be used when the best fit - ever try to drive a nail with a wrench? Anyone selling a one tool that does it all..well...I think I just answered that..
On the other hand, saying OOP has no value is just narrow minded.
The Game Guy
"a chunk of code that performs some task?" We got those -- them's a relatively unknown C contruct, called a -- dagnabbit, what's it called ... oh, yeah -- function. Yeah, you can make an object out of just about everything, if you feel like it ... but that doesn't make it the best way to go. I absolutely cannot see how simply surrounding functions with an object-oriented architecture is helpful. That's what I was trying to point out.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
I am not a huge OOP fan, but I firmly do not believe it is hype, yes, it has been OVER HYPED, but when you take the hype out, it is still worth it. OOP is not the solution to everything.
I was weaned on C and assembly. I learned to write structure code, C and assembly fits fine perfectly, I can sit down and hack C freely without thinking of the problem ahead. Doing so with OOP approach is next to impossible, OOP makes you work, I hate it most of the time, and that is the reason why most people hate OOP, if you have the hacker mentality, you will hate OOP approach.
But, even with the hacker mentaility, OOP can still be good, anyone here who has done GUI programing with C, C++, Python or Java knows that language that totally dominates is the languages with support for OOP not C. If you have done programming with CORBA, you will appreciate OOP just as well. Look at Orbix for example, the fastest CORBA ORB that I know, the dirtiest to hack for, look at other ORBs supporting C++, not the fastest in terms of execution speed, but much much painless to code for.
Some people might want to argue about speed, but in this age we live, it is no longer about the speed of execution, but of development, at least in my case.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
If you take OOP as a "silver bullet" solution for your development problems, than yes, you have fooled yourself. What a lot of people missed out about OOP is the fact that OOP does nothing but "unifies" common programming practices and provides a common "language" and communication gateway for developers to use when they are working on their projects.
Without OOP, we could all be talking about MVC (Model/View/Controller), call-backs, iterates, etc. in a completely different language and yet not understand each other which result into communication breakdown.
For those who are not familiar with OOP my suggestion is to read the "Design Patterns" book. The book doesn't talk about anything new or revolutionary. On the contrary, all the stuff in the book (and most other OOP books) are things that were covered over 30+ years ago. All what the book does is "unifies" those practices so that the next time when two developers are working on a call-back design, they don't just give it their own invented "cool" name or "cool" implementation.
Folks, OOP is no different than what you would find when you talk to an electrician (or any other well establish engineering field). In those fields there are "standard" language, process, and practices that get carried out and communicated. It is time for the software filed to standardize too.
Finally, regarding the payback of using OOP that the article pointes out -- there are countless research and study that show that on medium to large projects, OOP is the way to go.
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
One thing that bothered me was his tax example program. He states that:
We are assuming that Tax may handle other entities besides people, so we are making it a separate class instead of a method of Person.
Now, I am not an OOP programmer by any means. But wouldn't you do some form of inheritance of the base class Tax, forming a class Person_Tax (which might have specifics to people, but inherits other Tax items), then create an object method in Person based on this class?
I know my terminology may be screwed up, but I know that you don't need a whole seperate class in this example - you are just ordering and reusing components through inheritance. The power from this comes when you change, say, the Tax class - everything trickles down, and updates all other uses of the class and objects created from the class - so you don't have to change things in a billion different areas in your code, like you may have to in a procedural language (now, with good design and attention, you would black box a procedure with arguments you could pass in telling it what to do, like Function CalcTax(type, unit, var1, var2) - so that tax = CalcTax('Person', 'John Doe', var1, var2) is different from tax = CalcTax('Corp', 'JD, Inc.', var1, var2) - and this could be extended for various types, and modified if needed, affecting all areas that called this routine to calculate tax - however, this has to be the only routine used to calculate tax)...
Worldcom - Generation Duh!
Reason is the Path to God - Anon
http://pub1.ezboard.com/fobjectorienteddevelopment languagewars
Trust me. you WANT to read through that.
Trust me.
You'll be rehashing the same things over and over - read that first, and then decide if it is a "fair challenge" (minor note - most of the people there have been "discussing" this for 2-4 years with him).
Addison
OOP is always what comes after an OO Design. ;)...non OO Design Techniques actually gave shorter design times, but when the design team was gone (working in the next project) coders have to start to work out ugly hacks in order to make the system work like the customer wanted.
Yes, OO Design is far superior than other Design techniques, but sometimes is also harder. Why? Because you have to give your designers the WHOLE PICTURE since the BEGGINING OF THE PROJECT.
The Designer comes to play a key role here.
In my poor experience (counted in years, not decades
Whit OO Design, you can present your customer a nice graphical interpretation of the system behavior BEFORE EVEN IMPLEMENTING A LINE OF CODE. And yes, my mom can understand those UML diagrams...it's easy.
At the implementation level, OOP and NON-OOP are good in their own category. But wait! A programming languaje is as good as the programmer using it.
I've seen nasty things using OOP and real good things using plain old C.
So, to this point, we can see that OOP is very design dependant.
The rehusability grail is very design dependient. I can make a "CAR" class, or I can make a "VEHICLE" class. That's up to the designer. But when the same group of programmers/designers/software engineers have to write a "BUS" class, because the "CAR" is quite different...well, REUSABILITY my ass. Stop everything and start over again. (up to some level, the CAR experience will be usefull, but not transparently and automagically reusable).
So, I won't blame OOP, I tend to blame OO Designers. And yes, I think that most commercial projects (small to medium) don't get benefits in using the OO combo.
OO Techniques (Design and Coding) could be a big benefit to the OpenSource Community.
I remember www.theClassRoom.org, nice idea.
Collect classes from opensource projects and present them to the Community for reusing.
Have you ever seen a image bank? Well, I think of many good uses for a class bank.
Search, read license, copy, paste, use, extend, submit to the community. The real Open Source spirit.
I happen mostly to agree with the thesis of this article, that OOP has been applied indiscriminately as a programmer's panacea. The head of development at my previous job was a tremendous proponent of OOP, and he urged us all to read DESIGN PATTERNS and write up detailed class hierarchies. If there were any savings in effort and reduction in complexity, I didn't see them; instead, I saw a proliferation of classes and a disposition to spend more time drawing up nice-looking diagrams than in grappling with real problems.
But I don't care for some of the rhetorical tricks this article uses. Graphs without units or cited source, e.g. the "productivity comparison" which laughably charts "results" versus "time" for OOP technique and the highly specific category of "other". The bandying-about of general claims, with the excuse, "Sorry, we lost the references." The scarcity of citation throughout the document (and _no_, a URL link to another website does not count as another citation; I'm talking about citation from _real_ sources with good credentials.) Belabored, if not ludicrous, analogies (OOP and communism??) And of course, the obligatory venom towards academia.
One day, I hope, "computer science" will not be an oxymoron. But mostly I see stuff like this article--intelligent to a degree, propounding arguments which merit some consideration, but in the end, just as much a "religious" document as the OOP texts the author disparages.
hyacinthus.
But, that does kind of relate to the domain where OO is maybe best: GUI programming. This is a point acknowledged in the article, so I won't try to use it as a counterargument. Overall, that page does a pretty good job of claiming that OOP is overhyped, and not perfect for every situation. The author's not saying it sux0rs.
However, I think there is one important domain that was missed: database interaction. The author makes the point that a lot of seemingly OOP-related problems, like employee types, etc, are maintained by accountants in database relations, and not by coders in their programs. BUT, there are some great frameworks for interacting with database rows & relations as Objects! Here I'm mostly thinking of Apple's EnterpriseObjects, but please enlighten me about your favorite one.
In my experience, using code-level Objects to access database rows instead of raw SQL can be a helluva timesaver in many situations. And, to free engineers from controlling the data schema, EO even comes with a data modelor that can automatically generate Obj-C or Java classes to manipulate your database data.
IMHO, than rocks. I've written server scripts with raw SQL statements, and trust me, this is much easier. Even if we don't reuse it for 30 years. The main problem I see is that EnterpriseObjects in particular has like 6 billion layers of abstraction, so the performance is never quite what you'd like. It seems like there'd be some kind of compromise, though.
Maybe we need a way to mark a top-level post as "flame-bait" now.
Herbie J.
The author doesn't describe in depth what I consider one of the greatest advantages of object oriented programming -- polymorphism. Polymorphism is great because it allows you to invoke different methods for the same operation based on the derived class.
That makes more sense with a real example. I'm working on a set of classes that has a Stream abstraction. Derived classes must provide ways to do raw reads and writes, close the stream, and a few other things. (Preferably, they also provide some way to open the stream -- but that's not a virtual function.) The stream class itself provides buffered IO and some convenience functions for writing stuff in network order, a nice gets function, etc.
That allows me to have the same easy IO operations on top of many different kinds of streams:
Each one of these provides the same basic abilities -- reading/writing, seeking/telling (where applicable), closing, etc...but they do it in different ways. I need abstract read/write code so I can put shared higher-level code on top of it. Otherwise, I'd have to reimplement the higher-level code for each one. That would suck.
This doesn't even necessarily need an object-oriented language, just an OO concept. OpenSSL, for example, has a set of C functions that do a lot of the same things I'm talking about. It does it by providing a struct with function pointers...basically, a virtual function table. It's definitely not as pretty (I wish they would have just done it right and used C++) but it does work.
This is just one advantage of object-oriented programming, but I think it's a very significant one. Worthwhile by itself.
I have to think that some of the moderators around here are on crack (as in why is my parent post either flamebait or a troll?). I posted very early on, with a succint summation of what a load of crap this article was-- all of my hunches were proven true as I read the comments. The guy who wrote the article apparently frequently complains about this stuff on Usenet. He is apparently widely considered a flake for it. In his article, which I read before posting, and suspect the moderators did not do before moderating me down, he comes across as someone who has lost project bids to people who were more buzzword compliant than he is. And rightfully so since he appears to want to code in Fortran and something he calls "table oriented programming". His article completely overlooks functional and logical design as alternate paradigms, additionally he has added no real world examples (his charts are completely fictitious since as he says, "no studies have been done") to back up his claims either way.
In fact he does compare OOP to communism. And rather poorly since his complaints about communism all seem to be derived from problems he has with American democratic capitalism and it's overwhelming bureaucracy. The article is lame. Slashdot putting flamebait like this on the front page is semi-lame. It did engender one of the better discussions Slashdot has had in my recent memory, which makes it forgivable in my book.
I do not have a signature
I can't think of anything more procedural than an actual tape backup, but even there many things can be easily abstracted out as objects -- not just the high level stuff like "drive" and "tape", but also lower-level procedural items such as changing tapes.
-E
Send mail here if you want to reach me.
OO isn't fun for boys because it requires too much foreplay. 99% of 'em just wanna charge of to the clitoris and hack hack hack.
The way I sees it, OO philosophy splits effort 80/20: 80% on planning, documenting, philosohpy, interface, roadmap (compatbility fwd/bckwd)etc. --20% is actually writing code.
Granted one could argue that any good coding effort requires the above, however on projects I've work (C/x86-asm), 30% is spent deciding what to do, and 70% of the time is spent designing and coding simultaneously. Which can work, b/c procedural coding is immediately gratifying, whereas intelligent OO requires much more foreplay, er, planning.
---
https://www.accountkiller.com/removal-requested
I fought it for many years, and finally gave in. Now I wonder how I ever got by without it.
There are applications - small ones - for which OOP is not appropriate. Code which generates web pages, for example, is generately best written in a procedural language. The vast majority of applications, however, are easier to extend and maintain (although not necessarily write, at least until you've been doing it for quite a while) if written with OO.
And of course, you don't need an OO language to use OO. The Linux kernel is very OO, and it's written in C.
FWIW, the examples given in this article are terrible. Not only are they not very relevant, but they are badly written. If someone I was working with wrote OO code like that, I'd seriously question their ability as a programmer.
What you say is quite true and I could not agree more. I have seen a great many things butchered because of the mindset that is used. To make programs work properly with oop and/or databases work properly with relational methods imply thinking of things as the object with a set of qualities, attributes, & etc. first, and then only after that, deciding what they mean. Thinking is a different paradigm than coding (sorry to say) and is not easily taught.
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.
In my view, the advantage of writing things in an object-oriented manner is not that you can change the implementation without changing the interface. The advantage is that if you ever do have to add things to the interface (e.g., if you find that your nice foobar class needs a new blurbfoo attribute) it's easy to find all the functions you need to touch in order to add that new blurbfoo attribute -- because they're all there as part of that class (if you've done your job right).
Send mail here if you want to reach me.
>BTW, where are your 3 examples?
>Where is one?
>What, no proof?
>Ah, poor widdle kid.
Why don't you dig up some of those references you accidentally lost?
PJRC: Electronic Projects, 8051 Microcontroller Tools
Most OO horror stories come from a lack of discipline. No matter what programming language you use, if you do not have a solid OO design, you have failed to do proper OO programming. It does not matter what programming language you are using.
The result of proper OO development--and unlike the author of the article, I have seen successful OO projects--is a system that is easier for people who had nothing to do with the original to come in a evolve the system. And that is worth a lot to companies.
"C++ makes good programmers better, and bad programmers obvious."