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.
"OO gives people something else to complain about"
---- Sigs are bad for your health ----
Give a hand, not a hand-out.
I did not really say that if you read it more carefully (and follow the links). Basically, I assigned a "sin level" to the kinds of things passed around. Of course, the sin-level may be subjective.
Table-ized A.I.
Although I agree with you, your counter argument is specious: You're probably referring to the person (or one of them, since it's written in "The C++ Language" too) who said that all the examples of code in K&R are valid C++. That does not mean that they're OO, just that well-written C code is also valid C++ code.
Nah, you've been poisoned by popular languages. Lisp is an object oriented language that does not make this requirement or this sytax. From what I understand, Dylan is an even more potent language. The most popular OO languages are not a very good example of OO theory. Not even those noisy small talkers.
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
I disagree, but maybe I just have a weird brain. :) When I sit down to code, I think about what I have to start with, what I want the result to be, and how I am going to get there. In other words, I think about things in terms of procedures and execution flow. I don't think about objects or properties or any of the other stuff OO is noted for.
Don't get me wrong, I *can* write OO code if I have to, but I have to think a lot harder. I know this was one of the intentions: OOP makes you plan out things before you start. But I don't naturally think that way. Maybe it's because I started with BASIC on my C64 and moved to C; I dunno. If I had started with C++ maybe I would agreee with you. :)
Will somebody save me from the hell that is maintaining an self-taught c programmer's perl code?
Does omitting all white space, save indentation, really speed it up that much?
Is enforced scope really too much to ask?
and wtf is $m, $m2, and $mt2?
---
---
Silence is consent.
Note that I was and remain a proponent of OOD, but I treat it neither as a silver bullet nor a strawman. The author's tone and approach does little to lend credibility to his argument.
Incidentally, Pitfalls of Object-Oriented Development is out of print. I have the rights back and am working on a revised edition, which I am posting on-line (http://thinkwyde.org/pitfalls/) as I go along. Feedback is welcome; significant contributions will be attributed. ..bruce..
Bruce F. Webster (brucefwebster.com)
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
What, is Slashdot not getting enough page views or something, CmdrTaco?
I'd love to moderate this story -1, Flamebait. What next: "Microsoft were good all along"?
Shit, I got told I was configuration manager for a project thats been going on for three month today, teach me to know more CVS than anyone else on the project has owned up to. (Damn that auditor, why did we mention configuration management in our proposal when we meant source control)
Special Relativity: The person in the other queue thinks yours is moving faster.
He was not trying to add another myth.
I, myself, would also dispute your claim (that "custom software lasts three years on average"). There are boatloads of systems in the telecomm industry that last decades.
My
[quote] Face it, dude, you are a troll. You're just after attention, and you've got it. We've all seen this behavior before. [end quote]
I will admit that I enjoy the attention. However, enjoying attention and being wrong are not necessarily related. I am having my cake and eating it tOO.
OO's hype-to-proof ratio is almost infinity. I picked the easy stance.
Now, get to work and prove OO is better or be forever sentenced to seeing a troll-who-is-right pop up over and over to rub it in.
Table-ized A.I.
This just struck me as someone someone probably whipped up to show their managers a reason why not to go OO. OO is great for a lot of things but it is definately no silver bullet. I find that mediocre programmers tend to be anti-OO because, well, it hurts to think about those long words like polymorphism and inheritance.
except that he presents it from a completely closed point of view. he misses the point that there are many useful ways to represent data and function in programming languages ... all of which are useful somewhere, sometime. oo is one useful paradigm with many tools with which it can implemented. procedural, functional, event-based, locical, are other useful paradigms (there are more, and many combinations). the key is to see the possibilities in all of them. close your mind, stop the learning ... open your mind, learn more, there are infinite possibilities!
mx
Oolite: Elite-like game. For Mac, Linux and Windows
Bryce's Xbase Fan Club page at http://www.geocities.com/tablizer/xbasefan.htm gets to the core of his mentality. He states "Many allege that I like XBase simply out of familiarity and habit." Well..., duh! Later in this article he blames OOP for the demise of Xbase. I once programmed in Clipper, a compiler that offered the most sophisticated extension of the xbase "language". What Bryce doesn't tell you is that from the early nineties on there was a very excellent Clipper library called Class(y) that allowed you to code in OBJECT ORIENTED XBASE. It offered such nice features as multiple inheritance and delegation. Though it goes against all of Bryce's tortuous logic, OO xbase actually enabled me to reuse components and increase my productivity! It also helped me prepare to move to c++, objective c (OpenStep) and Java when the xbase market fell flat in '94. The most annoying thing about Bryce is that he's never bothered to learn in depth any of the things he criticizes. Rather than putting his energy into the investigation of new languages and paradigms, he wastes his time and ours with this weak and paranoid rant that blames a Communist OO conspiracy for the fruits of his own laziness. He should grieve the death of xbase and move on.
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]=-
Developing generic libraries is a much slower process than developing application specific code to do the deed.
This might be true if you're developing one thing, and then quitting. But taking to the time to generalize, and put functionality that you might user in other products into libs is clearly advantageous. It might take more time but it pays off if you have other projects to worry about.
You are right though, that it's all about the discipline. For me, I just find it easier to be a disciplined developer in OO languages.
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
You did see the word "average" I hope. News: exceptions happen.
Table-ized A.I.
I'm quite sure you don't remember your paper getting a point by point dissection from people like Tom Christiansen, Randall Schwartz, Tad McClellan, and Uri (God Love Him). Of course, those are folks who generaly Know What They Are Talking About.
You, on the other hand, are someone who Doesn't Know What They Are Talking About, as you continue to prove over and over again. You should go back to the accounting department, where you can impress all your payroll clerk friends with your *vast* techincal knowledge.
The rest of us are just laughing at you. Again.
--
--
You sure got a purty mouth...
Which "way-more damning" criticisms are you talking about?
Also, relating apostrophe usage to general intelligence is a
little bit of a stretch. Why are some people so distracted
by such things? You remind me of my wife: you find "messes"
that nobody would otherwise notice.
I guess everybody is pedantic in different ways.
Table-ized A.I.
Modify this post up to 99- ROTFL level humorous. When I read it, I spat coffee out all over my girlfriend, (or at least the space where my girlfriend would be if there wasn't an SGI monitor there).
PS I only said that because my grand-pappy was in the room - just give me a keyboard with a one and a zero and I'll do it myself! That's the way real men write crappy code!
...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.
Myth: Implementation changes significantly more often than interfaces
Regardless wether you design/program using OO paradigms or other paradigms, its ALWAYS a challenge to design/define stable interfaces.
This is not only a question of programming experiance but also of domain experiance and further more of anticipating future uses of the work you are currently doing.
If you make a domain analysis and a robustness analyis and even a product line analysis (all those terms stem from modern ooa/d) then you have chances to find stable interfaces for your certain business needs.
And this is a ART for its own like program performance hacking is, or like memory allocation/ deallocation hacking is.
If you are only a VB and "how to get it from the DB to the WEB" maniac you will never get stable interfaces.
E.G. look at linux or any other unix kernels, most kernel calls are FIX since countless years.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Good post. I have to disagree with one thing:
"Specific is good, generic is bad. Building generic stuff takes longer and makes for unreadable code - don't do it unless you need it."
Really??? I think that generic programming is the missing key to effective code reuse. If I find myself sorting things over and over again, shouldn't I abstract that out into a generic sort algorithm, instead of having similar (but not identical) code littered all over the place? The latter would be a maintenence nightmare. If there's a bug in you're approach to sorting, you have to change it everywhere. It violates the OnceAndOnlyOnce rule.
Admittedly, coming up with something generic right up front is hard, and shouldn't be attempted. But refactoring similar code into generic functions or classes is a good thing.
Generic programming is orthogonal to OO programming. In OO, you try to capture business (and other) entities as objects -- Customer, Order, Item, etc. Generic programming lets you capture the abstractions that tend to occur at right angles to your business classes. For example, sorting customers, sorting orders, sorting items -- why not capture sorting as its own abtraction, rather than reimplementing CustomersList.sort(), OrdersList.sort(), ItemsList.sort(), etc? Wouldn't having one generic sort function that can do 'sort(CustomersList)', 'sort(OrdersList)', etc., be better? Aside from the code sharing issue, it's just cleaner to have one 'sort' abtraction.
Oh, and polymorphism over types is actually an instance of generic programming -- many different types have the same interface, so you can write a another method that takes the base type, and it operates on all the sub-types. It's generic.
Stephen Molitor steve_molitor@yahoo.com
But combined with a good table (RDBMS) system, procedural is a wonderful tool. Partitioning by "tasks" is much more natural and less artificial than OO approaches, which often get skizophrenic because of the simplistic dispatching and single associations encouraged between nouns and verbs. IOW, it does not scale in association complexity.
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.
OO Components are not at the top of my hit-list, but still, procedural approaches are often just as simple, if not more so because they don't need the extra syntactical baggage of OOP.
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).
Often things that have such textbook convertability fall apart in the real world. The real world does not give a rats behind about fat-type trees. It will change any way it feels like.
A graph-oriented approach like relational modeling and HAS-A relationships model this aspect of the real world better.
BTW, case statements are probably one of the most heavily debated sub-topics I encounter on usenet.
Table-ized A.I.
The above example is also an example of polymorhism, and doesn't need a language such as C++ that explicity supports it. In C the Draw() member would just be a function pointer.
;-)
Uh, I guess you didn't read the above comment all the way at the bottom of my post!
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.
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Loony as a toon! Everyone knows that OOP is Capitalism, not Communism! Objects frequently rip each other off, stealing behaviors and data (calling it "inheritance", just like Napsterites "sharing" other people's songs). This is a classic Capitalist growth model. Capitalizing on another's work is such a predatory practice that even the Guiding Lights Of The Free World felt compelled to create the US Patent Office to allow inventors some period of time when others were not allowed to steal their hard-earned ideas from them.
COBOL, on the other hand, is Communism. Ever try to write anything in that language? The declarative sections are longer than War and Peace and read worse than Marx and Hegel, and it actually does accept "ADD A TO B GIVING C."! Hell, the books even encouraged it some years back!
How do you think Microsoft made Office so rapidly?
I'll bite, they bought bits, stole^W borrowed bits, chucked resources at it and released it before it was ready (and it been around for circa 10 years anyway, at least some of its constitituents)
Special Relativity: The person in the other queue thinks yours is moving faster.
The business domain appears to be such a place.
I would have liked to see a better description of TOP, perhaps a few pointers to tutorials.
I have plenty of examples hyperlinked around the site. (One of these days I will prepare an index, but I have NO budget.)
The guy's own descriptions are pretty useless for quickly grokking his point.
I am not sure T.O.P. is easily grokkable, at least for some. (Niether is OO according to many practitioners.)
Thanks for the feedback, though.
Table-ized A.I.
The burden of proving that OO is better is on you, not me.
You've said this a bunch of times in other posts so far. I don't see how this is true at all. YOU are the one who wrote the paper, and you want the reader to go disprove YOUR points?
That's like me saying:
Oh, by the way, I think non-OO programming sucks. Go prove me wrong, and give me 3 examples! Otherwise, I'm right.
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
[quote] In point of fact, your web page is the one that didn't cite hard data. If you're going to claim that OOP isn't effective, you need to back that up , just as the people who claim OOP is effective do. [end quote]
Group A says it is great, group B says it is of slight help, and group C thinks it is crap.
So, then how do we settle this?
1. Establish agreed-upon metrics
2. Test each against these metrics
3. Look for patterns and form hypothesis
4. Test new hypothesis (goto 1)
IOW, good, old-fashioned SCIENCE.
Right now all we have is opinion. Prove first, THEN innundate the instrustry with the winner. NOT the other way around.
Table-ized A.I.
>>I just think gtk should have been C++, since it essentially is
Yeah, but as the authors point out, there are some systems for which there isn't a C++ compiler; by writing it in C you get ultra portability.
And, yeah, I love GTK too. It's really well designed, IMHO.
Is is just me, or does the author seem to trample his own argument?
One point the author makes throughout his article is that OOP pundits claim that if used properly, OOP is TGSSB (The Greatest Thing Since Sliced Bread(TM)).
After the market place realizes the shortcomings of these technologies, the die-hard supporters always say the same thing: "They WOULD work if people simply used them properly." We are already hearing this from OOP apologists.
However, he also says
I am beginning to get the feeling that many people are forgetting how to do good procedural programming and blaming the paradigm for their shrinking knowledge. The above claim about memory recovery is just one example.
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.
Intellectual elitism? Stubbornness? Perhaps a mere oversight? I actually prefer procedural programming myself. However, I can't stand to see someone make a bad argument in my favor.
First of all I agree with you, Mike.
This "Tablizer" person seems to not realize that business applications revolve around the concept of "business rules" which tend to be procedural in nature (no wonder he had such trouble writing OOP code for the business rules!).
The most commonly changing part of a business app are it's "business rules", other parts are usually stable in concept therefore a good OOP design should be able to handle the application objects.
Personally I like OOP because, if I wanted to, I can create a monolithic business application into "client" OOP code and "server" OOP code and since the client code uses polymorphism to call into the server code... if the design changes all I have to do is recompile and relink the server code; of course the "business rules" are usually embedded within the server code, which makes for changing the application logic simple.
Of course if we look at 3 tier business applications we have the frontend, the business logic, then the backend (business logic==business rules). the frontend, since it is graphical in nature tends to be OOP. The business rules are usually _very_ simple objects, which of course talk to the backend. The reason they are simple objects is because they are coded with simple interfaces so that the frontend can manipulate them easily. But if you take a look at the actual business logic underneath, youd be impressed with it's complexity. The _only_ reason for the 3 tier system is that it provides for stability, redundancy, and most of all flexibility and reuse. I can't _even_ imagine someone being foolish enough to write a 3 tier business application using no OOP; would this person realize how much of a pain it would be if a major component in the frontend changed or if a major business rule changed!?
I think this kid, like most amateur programmers, just has no clue when it comes to OOP programming, especially with C++.
o The self-containedness of objects does make code reuse simpler and less bug prone.
I don't buy that one. A well-designed C module is just as easy to maintain and reuse. Basically classes (without inheritance) are just structs with syntactic sugar (i.e. the first parameter, "this" in C++, is written in front of the function name).
I disagree. With the C++ class the initialization and cleanup are done automatically for you, whereas with the C module the programmer can easily forget to initialize or to cleanup under some particular failure case. With enforced (via private:) opaque data interfaces, the C++ class protects the integrity of the data, whereas with exposed data structures the tempation is there to modify something directly, particularly if you're under time pressure.
I'm not saying that a well-designed C module can't be easily maintained or re-used, but rather that a well designed C++ class can outright remove the possibility of certain types of bugs. Using class-based code, I've sometimes surpised myself at the complexity of programs (e.g. multithreaded, shared complex data structures, communications code) that have worked first time. I consider myself an expert level programmer, but we all create bugs, and anything that can eliminate that possibility is a good thing!
Dude, if you can understand LISP you should have no trouble understanding ANYTHING.
(And I say that, me the big LISP fan).
I disagree. Essentially this point of view leads to implementation focus instead of interface focus. For the most part, I don't care how a module works, only that it does. I do care how I get that module to work for me. Structure turns out to have nothing to do with public interface design (and very little to do with private interface design, other than making functions). It is unfortunate that slashdot posted this stupid article. You can watch the author rant on news: comp.object. He goes by topmind there. His name is the least obnoxious part of him. His understanding of OO is not very deep. But comp.object is pretty smalltalk biased, so the objections you get usually aren't very interesting either.
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.
- Steeltoe
http://www.debunkingskeptics.com/
The guy who wrote this article just trolled the shit out of all of you. I bow to him. Goodnight.
---
"You just stranded one of the world's greatest leaders in San Dimas!"
Bob Fucking Costas. Does anyone else hate that motherfucker?
I think that you confuse OOP with modularisation here.
You can do that in a procedural language too, it isn't an OOP feature.
You have to think in modularisation that you can do with OOP, but not (in the same magnitude of difficulaty) with procedural langauges.
IOW direct benefits from the polymorphism and inhertance, not purely from writing modularised.
> 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.
[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.)
[quote] It encourages opaque data interfaces (method access vs public access) which results in less bugs [end quote]
Real-world business example?
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.
[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.
In short, you are comparing C to C++. C is NOT the pennacle of procedural/relational programming.
[quote] The self-containedness of objects does make code reuse simpler and less bug prone. [not quote]
Specific example?
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. People are trained by rote to think of the standard OO benefits, but often don't notice the side-effects. (Extreme example: if your hand itches, then chopping off your hand will stop the itching. However, the salesmen forgot to tell me about the itchy stump, among other things.)
Table-ized A.I.
Wikiwiki link about code re-use:
http://c2.com/cgi/wiki?OoIsNotAboutReuse
Quotes from it:
"Anyway, OO's (hypothetical) re-use benefits were pitched so agressively that people seemed to confuse the two. In reality, OO and re-use have turned out to be really orthogonal things."
"Software reuse is a management problem, not a technical problem. Always has been, always will be."
What specifically is it about OO that allegedly makes for better code reuse anyhow that subroutines and modules cannot provide?
(Hint: if your answer is based on inheritance and/or hierarchical taxonomies, tred carefully.)
Table-ized A.I.
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 was chanting along with you, but you stopped...
Did you run out of stack space?
Well, often the differences do not fall neatly into sub-type taxonomies. Real world things don't chop up nicely into taxonomies for the most part I find (at least not lasting ones). See the Employee example.
As I said, it's very rare that you find two OO designs for the same project that do agree where the boundaries are. However this is not a problem, if you took any two OO designers and gave each the design or code of the other designer, each would be able to rapidly understand the design of the other without too much difficulty; something that seems to be extremely difficult to manage using other methodologies. I regard the PRIMARY purpose of a design as the ability to communicate the ideas of that design to others so that they can understand and implement it, and in that regard OO works with the minimum of hassle.
You appear to object to OO because at some points there are not hard and fast rules about how a class/function should be implemented in all cases; I say that it doesn't matter if there is some arbitrary choice and freedom provided the design ideas can be communicated simply and easily to others.
I agree with you that real world examples do not often split neatly into sub-type taxonomies. It is at those points where I have to make some design decisions and hope they work out. I often find that in the event I do screw up and have made a bad decision, that OO has set some boundaries that limit the effect my bad decision has had on the rest of the design and make it easier to reengineer the bad components.
You are talking about shop-specific conventions (method per file), not paradigm differences.
Yes, but OOD seems a method which encourages, without using brute force and thousands of pages of "standards" (which do make me hurl), those shop conventions which do make for good maintainability.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
ohhh, poor guy...
I've been programming for some years now in all possible languages, and OOP *did* make the overview and management of the data-structures very much easier. (developement speed and costs of course profitted from this)
If this guy only has to *script* twiddly-diddly less-than-10,000-lines programs, then DUH! He's simply never really experienced how practical a tool OOP can be...
virtual interfaces, encapsulation of data & methods and inheritance are as natural as functional programming, namespaces and dynamic memory. If he fails to see that then he's simply never written a respectable application.
If you only do calculations in the single digits then you're gonna question why everybody thinks calculators are so grand...
this guy is problably the local loser (compared to his OOP-luvin colegues) in the his company and is playing the contrarian...
______________________________________________
sigamajig...
You think you proved your point? There is just 1 Class in your example...
AC is AC
inheritance breaks all that. in particular the fact that you can (and probably will) inherit inappropriate superclass methods means that objects can often be broken by calling those methods.
instead of a "one interface, one purpose" scenario, you get "large numbers of slightly different interfaces, obscure numbers of purposes"! look at a diagram of the Java class hierarchy sometime to see what i mean.
i have found that the best code reuse is to be found by choosing well-designed, tight, and simple object APIs, using no inheritance at all. this approach avoids the constant fretting familiar in OO circles "how can i mutate that interface into the one i'm after?" a.k.a. "what should i inherit this object from?".
>>Your style book isn't the be-all and end-all of correct English. What counts is how everyone writes. Officially correct style is determined by common usage. Some rules, like those relating to "its" and "it's", are so dumb and commonly violated that we can only hope that style-book-writing pedants will eventually accept that common "mistakes" are correct.
I'm not talking about MY style book but the actual real rules of English grammar. The "it's"/"its" rule is not "dumb", no-one feels inclined to write "hi's" or "he'r" instead of "his" and "her"- it's only because *coincidentally* "its" is the same as "it" with an "s" on the end; If the word for "his" was "hims" then people would probably want to put an apostrophe in there too.
Officially correct style is NOT "determined by common usage"; The language can and does evolve over time, and this process is affected by common usage, BUT it hasn't evolved yet, so the examples given are still wrong.
Do you call your C compiler a "style-book-writing pedant" when it complains about a missing semi-colon? We have these rules in the English language for a reason- they help to resolve ambiguities. Unfortunately it seems as though English is going to "evolve" into a piece of crap without any of the subtle nuances we have today.
And don't tell me "It's only grammar"; It was you who started this by incorrectlty "correcting" someone else's grammar post.
Graspee
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
I think the issue is that OO mostly seems to shine in places where the interfaces are fairly stable. Some domains are like this I hear. But certainly not mine.
OO seems to have more overhead when interfaces change because it is based on the assumption of stable interfaces. For example, you may have more get/set wrappers to change than you would in a typical procedural approach, where you are more likely to only change the places that need the changes.
OO is overly obsessed with the concept of isolating implementation changes, at the expense of other app/code management issues.
Table-ized A.I.
[quote] He is a well known troll on comp.lang.perl.misc. When he showed up there the first time, he was pissed that Perl wasn't Visual Basic, then he went away for a while. When he showed up again, he was pissed that Perl wasn't COBOL (seriously). [end quote]
It is already circulating well that Perl encourages write-only programming. I asked for code proof that one NEEDS perl's cryptic stuff, and nobody could do it.
You were afraid of scrutiny.
[quote] and fancies himself an expert on whatever topic he read about last.[end quote]
Well, since everybody else votes themselves experts-without-proof, why should I be exempt?
Table-ized A.I.
You seem to have failed to grasp the point of my post. I *can't* prove that OO is better- not because it isn't, but because it's impossible to prove that one programming paradigm is inherently superior to another.
It's as if I said- "How can I prove that my cheese is faster than your cheese? Cheese doesn't have a speed!", and you said:
"If you are unable to prove that your cheese is faster, that is NOT my problem. Stop making excuses."
Graspee
My major gripe with his article is that it seems to be one big rant against OO with very little in the way of decent alternatives.
Foul! Only at the dinner table (and then only when Mom is presiding) is it fair to tell someone that "If you don't have something positive to contribute, don't interrupt." Negativism is a perfectly good debating position - it worked for Martin Luther!
Even when he talks about C, he is critical; so my question is, what techniques/languages does he suggest we use?
PL/I would be a good start. Algol (but not '68) would have been too. What's that you say? PL/who? Right, these languages were the darlings of the Structured Programming fanatics in the late 1960s and early 1970s. You don't find them in too many places any more, although Algol has survived somewhat as Pascal.
VB? Pascal?
Edgser Dijkstra (please don't say "who?") said (way back in the early 1980s),
(emphasis mine)[quote] "The burden of proving that OO is better is on you, not me." You've said this a bunch of times in other posts so far. I don't see how this is true at all. YOU are the one who wrote the paper, and you want the reader to go disprove YOUR points? [end quote]
The orthogal taxonomy issue and the method boundary issue are specific things that bother
me about OO.
We can focus on these for days.
However, I have never seen OO code that was better for a biz app. I can't fight what does not seem to exist.
IOW, you claim your car is faster, but you won't race it. If you won't race it, how can I compare? All I can do is concluded that you are probably full of it. This is where the situation stands right now.
Table-ized A.I.
If you're really the author of that dreadful article, I'd like to ask you why you decided not to respond to all the other way-more damning criticisms of your arguments.
Also of course I'd like to point out that in your article you can't use an apostrophe to save your life, so why the hell should we believe you are qualified to address semantics of languages when you haven't even grasped the syntax?
Graspee
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.
I'm definitely not arguing against the use and creation of libraries. The problem is... most of the time, that _is_ developing one thing, and then quitting.
When it's not... the cycle usually runs something like. I develope on program. I develop another that does something similiar, i get the project assignment for a third that does something similiar, then i abstract a library, write the third, and back port the two during the next review.
As a blue collar business programmer though, i usually find myself moving on before i get to that third program. Additionally, justifying that time i spent on the library to management is often painfull. Then taking into account my deadlines, and often i'm just stuck writing three programs that have alot of very similiar code.
If some of the abstracted libraries are interesting enough, i might work overtime, or in my own time on them if they're sufficiently interesting, or if i know unequivcably ahead of time that the next two projects are coming down the pipe, and that i'm getting them.
These circumstances don't happen too often however, and more often than not they aren't of much use outside the relatively small context of those three apps. They can't be GPL'd, or BSD'd or, personally, Artistically liscensed and released because they belong to the company and most managers look at you like you're a moron, either out of ignorance or intolerance, and dismiss it out of hand.
Not that they'd be particually useful if released anyway, because they're usually aimed at biz niches.
I'm a mixed paradigm programmer myself, and intend to stay that way. I've walked in to far to many maintenence projects cold to believe any hype about any methodology, as they are all equally capable of producing crap. The proof is in the code, not the theory.
Old truckers never die, they just get a new peterbilt
Obviously, performance is rarely the prime objetive in a software project, compared to, say, completing on schedule and within budget. However, here's what a skilled OO Perl developer has to say...
From Damian Conway's excellent Object Oriented Perl:
I guess [anyone got any figures?] that the same might be true when trying to use any procedural language in an object-oriented fashion.
err... many Perl programmers will admit it.
"...don't do it unless you need it."
When there's actual common behavior - your sorting example is good - then generic stuff saves code. But a classic beginner mistake is to build it before you need it. If you only have one thing to sort, or everything you work with gets sorted very differently, then writing a generic function and a "sortable" interface just makes your code more verbose, harder to read, and often less optimized.
This IS a strawman argument (despite his claims otherwise) by somebody who clearly has little idea of what OO is about. I guess he is frightened and fearful for his prospects because he is unable to make the paradigm shift. The clearest evidence of this are the Myths; an OO authority would never proclaim many of these, some just don't make sense, some are 'clearly' miss-quotes or misrepresentations of what OO advocates do claim. That these are myths is only claimed with his opinion, not proven with evidence.
Myth: OOP is a proven general-purpose technique
Where is the evidence that it is not? His own pet hate about the massive growth of OO over the last decade directly contradicts this claim. I've used an OO approach successfully to produce many types of systems including, databases, real time, calculations, GUI's & parsers, print engines, utilities.
Myth: OOP models the real world better
Better than what ? OO readily models Physics, the most fundamental 'real world' model in existence.
Myth: OOP makes programming more visual Stawman
Myth: OOP makes programming easier and faster
This claim should be qualified as over the full life cycle of a system; the design may be longer than a traditionally 'hacked' project. However the iterative nature of an OO development more than make up for it during elaboration & maintenance phases, the most important phases in bespoke systems development.
Myth: OOP eliminates the complexity of "case" or "switch" statements Stawman
This is an algorithmic issue; the Command pattern is one OO approach to achieve this, there are non OO approaches that could also do the same (function pointers in C) if it is warranted. It was with Win SDK message crackers for instance.
Myth: OOP reduces the number of places that require changing Stawman
OOP aids a reduction in coupling. Reduced coupling improves a system in a number of ways, including maintenance.
Myth: Inheritance increases reuse Stawman
There is a lot more to reuse in OO than inheritance. Encapsulation, polymorphism, aggregation/ composition.
Myth: Most things fit nicely into hierarchical taxonomies. Stawman
As I just said there is a lot more to OO than inheritance.
Myth: Self-handling nouns are more important than self-handling verbs ?!?!
This miss-represents a rule of thumb used to aid the learning of OO; 'more important', this does not make proper sense.
Myth: Only OOP has automatic garbage collection Stawman
Garbage collection and OO are not synonymous, not all OO languages include [automatic] garbage collection, procedural & functional languages do include automatic garbage collection. it's probably only really essential in functional languages.
Myth: Components can only be built with OOP
Myth: Only OO databases can store large, multimedia data Stawman
Myth: OODBMS are overall faster than RDBMS Stawman
Myth: C is the best procedural can get Stawman
Myth: OOP would have prevented Y2K problems Stawman
No, just made it easier to fix.
Myth: Implementation changes significantly more often than interfaces Stawman
Myth: Procedural/Relational ties field types and sizes to the code more Stawman
Myth: Procedural/Relational programs cannot "factor" as well Stawman
Regarding the unanswered challenge, the old philosophy of science adage, that the absence of evidence is not evidence of absence, says more than I ever could.
The posting history of this identity, demonstrates a single narrow minded obsession with ignoring the evidence, that it's pointless trying to convince him otherwise. His ego prevent him progressing. I would guess that he's a self taught amateur who know a few [non OO] languages, rather than a trained professional with a range of tools [including OO] in his arsenal.
>>relating apostrophe usage to general intelligence is a
little bit of a stretch. Why are some people so distracted
by such things?
Because if you could grasp the syntax of the English language I might have more time to listen to your rants on language semantics. I didn't relate apostrophe usage to general intelligence anyway, even though someone of moderate to high intelligence would probably be curious enough to go and look the rules of grammar up rather than just blindly guess when posting.
>>You remind me of my wife: you find "messes"
that nobody would otherwise notice
Look, if everyone else is too polite to tell you that you shat under the coffee table again, then that's not my problem. More power to your wife for pointing it out to you.
Graspee
P.S. just tell me if I go too far- I'll mark you done as "flunked because could dish it out but not take it"
There's a long history here with "Tabilizer" and myself, and many others.
As for syntax.. well, you should have seen some of his earlier missives on semicolons on IWE. (nevermind when people _explained_ why they were used, etc... he didn't like them, so they were stupid"
The reason he doesn't respond to the good criticisms is.. its his MO. he'll wait and attack some tangential position, divert the argument, then declare victory.
I'll recommend you to the link I've posted several times... Its as good as any other, the arguments always go the exact. same. way.
Prove him wrong, pin him in a corner, and its a technicallity/silly/not important. More often, he'll just ignore them, and worry on the tangents, and get things so mixed up that nobody can be sure where he started.
(For example, he demands that people who say that OO is better "prove it objectively". A study was produced that did exactly that. (measuring Lines of Code/Function Point) He then went on a rant "demanding the code they used". When pointed out that the methodology was available, and he could measure it himself, he said he didn't have the time, but since the "code wasn't open" the study didn't meet his prior demands for a scientific study.
Lather, rinse, repeat.
Addison
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 was talking about the distinction between procedural languages and assembly. I wasn't referring to OO languages at all. My essential point is that assembly guys could make similar arguments against procedural constraints that you are regarding OO.
Wrongo! In a nutshell, I am saying that its hype-to-proof ratio is way too high.
I really wish the author had the confidence in the claims to actually site some hard facts and not some made up claims.
There are no "hard facts" either way. That *is* one of the very problems I am fussing about.
What specificly is "made up"? I agree it is missing some citations, but not on key points.
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.
I am not sure which reference you are talking about. Anyhow, there is no proof that OO is better for all domains. Comparing NASA's needs to WalMarts is perhaps a bad idea, BTW.
Most the data I have seen shows that OO is wash in system or engineering domains: no clear benefits. (The biz domain data is harder to find.) But, if its all the same, why not use procedural/relational? It is easier and more natural (IMO). It also has a lot of areas that can now be improved because of more CPU power. We don't have to be stuck in the 80's for ever WRT procedural/relational.
BTW, it *is* dumb in my opinion to jump into something without more proof. Then again, IBM and NASA have may other mundo bloopers that prove they are only human.
Table-ized A.I.
a sub routine call is always going to be a sub routine call, which has always slowed down CPUs.
Unless it's inlined. Really clever C++ compilers (www.kai.com) can optimize away whole classes.
Not that any of this matters a damn. The future belongs to dynamic, very high level languages like Python. Real programmers worry about complexity, not performance.
-DA
Try programming in ASM sometime, you might realize the usefulness of abstraction... Actually, why don't you read The Mythical Man Month by Fred Brooks, it'll probally be educational to anyone trying to say OOP is not a good thing in most cases. For a small program, it isn't very practical, but as the code base grows, the time required to maintain a list of a thousand functions grows, and it gets increasingly difficult to actually improve the software, too much time is spend debugging and causing more bugs. OOP may not be the most efficient thing in the world, but c++ compilers are improving greatly which results in better machine code, which means better speed. Don't get down on Objectifying software projects just because OLD compilers do not handle it well. People need readable code, and OOP concepts help keep the human side of programming managable.
Spring is here. Don't believe me, look outside!
[quote] Plus, OOP is one way to make having multiple programmers work on the project more likely to be productive. When programs can be broken down into clean interfaced modules then different programmers can work on them with much less coordination than in pure structured programming. In my experience writing BIG BUSINESS in house apps (as opposed to the author's small and medium business) the procedural COBOL work is in some ways organized in an intuitive parallel to OOP. [end quote]
Modules are not OOP-only constructs. You seem to be talking about the benefits of modules, and not OOP.
I notice that OO tends to break things into noun-centric modules while procedural tends to break things into verb-centric modules. I feel more comfortable with verb-centricity (code-wise) in many cases because verbs are more stable a base than variation-based OO nouns. (The criteria for the variations is often too dynamic.)
IOW, a task will always remain a task, but a noun taxonomy is subject to violent changes. Plus, many operations involve multiple nouns. If you notice, sentences tend to have only one verb, but many nouns. Thus, you often face the problem of which noun to associate a verb with. (See the "aspects" webpage.)
[quote] I wonder how the next programmer to maintain the author's code will feel about his objection to abstraction and separating the project into self-contained pieces. [end quote]
I am NOT against abstraction, just OO's brand of it. I think tables make a very nice abstraction tool because they are not tied to single-listic relationships the way that OO tends to be.
Table-ized A.I.
Only if you're absolutely retarded will this happen.
OK, I totally agree with that. As long as you follow the OnceAndOnlyOnce rule rigorously, everything's kosher.
On a side note:
One legitimate criticism of 'classic' OO is that it places too much emphasis inheritence hierarchies. Some kinds of behavior, however, occurs at 'right angles' to the inheritence hierarchy. Common algorithms like sorting, or policy things like error logging, transactions, etc. These things tend to occurr all over the place, but don't always have a clear place in the inheritence hierarchy. Generic programming (templates) and aspect-oriented programming are two attempts to mitigate this problem; I think they hold a lot of promise.
Stephen Molitor steve_molitor@yahoo.com
"IBM and NASA have may other mundo bloopers"
Should be:
"IBM and NASA have made other mundo bloopers"
"Other" as in not directly related to OO.
Table-ized A.I.
It's already 5 years that OOP design has lost its hype.
Get some recent books on C++ or general design
topics and you'll see that the focus has already moved away from classic OOP. Today's hype is mostly for generic programming (which I second) and design patterns (which I don't like that much). There are *lots* of books suggesting *NOT* to abuse inheritance and other OOP techniques of the past. Yes, even simple
inheritance is bad if it leads to a deep hierarchy.
//BernardoInnocenti
Bernie Innocenti - http://codewiz.org/
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.
it was meant to be "end quote"
I think the double-angle style is nice for text, but slashdot does not like the right side. Bummer.
There are too many messages for me to use direct HTML, thus I need a nice text shortcut. Any ideas?
Table-ized A.I.
(The Deja.com archives are down, else I'd try and link to that).
He's also IIRC called Turing, Meyer and Dyjstra idiots....
No, Bryce is the only expert, we've established that well.
http://pub1.ezboard.com/fobjectorienteddevelopment languagewars.showMessage?topicID=175.topic&index=2 2
That forum has lots of good posts...
But no.. no amount of real world examples will make him back down - he's unable to consider the ability to back down. The German WWII high command retreated more than Bryce. :)
Addison
This is outside of my target domain, but it kind of reminds me of issues in collection access interfaces.
What I have decided is that a taxonomy of "types" of collections, or pipes/streams in your case, is an insufficient model.
Perhaps you could model them as a bag of *indepedent* features rather than try to filter them through a hierarchical taxonomy.
That way you can get new combinations without making a new node on a tree. The number of combinations you can get this way is astronomically greater than a tree will give you. You can get dogcats and horsebirds and boatcars, etc. (Some combinations may not make sense, but such spots may not fit a hierarchy anyhow.)
You are then freed of the artificial restraints of tree-based taxonomies.
I apply a similar philoshopies to business applications. My bank and publications example illustrates this concept.
Think about it. Could it work for sockets/streams?
Table-ized A.I.
That's because you sir, are an idiot.
Thank you.
Any paradigm would suck for GUI's without a framework. Besides, writing GUI's is outside of the domain of most of my criticism. Even if OO was good for writing GUI frameworks, that does NOT mean it is also good for writing everything else.
Whenever you talk to the OS, you're always having to pass a handle as the first parameter! This just screams: this should be OOP.
Why is that? What is wrong with handles?
Table-ized A.I.
It has only been mainstream for about 11. The fat-client fad has/had been around for about the same, and is now fading.
I agree that OO has it's place, but that place is not everywhere.
Table-ized A.I.
Sorry, never really look at the UIDs. I point out that he stated he was "posting anonymously to preserve my precious karma". Since he did NOT post anonymously, it seemed a bit like reverse psycology, daring the moderators to mod it up.
My only regret is that I responded not to the poster but to the comment - in the future, I'll try to address my comments to the poster rather than the SlashDot community at large.
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
I saw it, and I'm still disputing your estimation. Saying "average" doesn't make it more truthful. If there are more exceptions to your rule than there are "average" cases, you have an ill-computed average. The vast majority of software I see in commercial settings is several years old, generally more than 3, almost without exception 2. Businesses, especially small ones, are reluctant to put money into upgrades if the current system is working fine. The amount of work available during the Y2K scare is also representative. Some people might have been writing programs that weren't Y2K compliant as last as 1998 and 1999, but it doesn't strike me as too terribly likely. Y2K might be the only reason your figure holds true, since a lot of antiquated systems were updated or replaced in the past two years. However, I still have my doubts, here. Even video stores and pizza parlors are using software 4 or more years old.
If a corporation is a personhood, is owning stock slavery?
I prefer procedural programming, but I still use C++. It's not a contradiction.
C++ supports *both*.
In my opinion, that's one of the reasons the language has been so successful. It allows a programmer to use the programming model that best solves the problem.
(* ... *) = quotings
(* That these are myths is only claimed with his opinion, not proven with evidence. *)
I have rarely seen a "common myths" list in literature that gave references for all the myths.
Why do you hold me to a higher standard?
(* His own pet hate about the massive growth of OO over the last decade directly contradicts this claim. *)
If popularity == Good, then hug NT
(* [re: case statements]
This is an algorithmic issue; the Command pattern is one OO approach to achieve this, there are non OO approaches that could also do the same (function pointers in C) *)
That is NOT ridding the complexity, only changing the nature of them. It simply exchanges one type of "list repetition" for another.
(* The posting history of this identity, demonstrates a single narrow minded obsession with ignoring the evidence *)
What evidence? Your anecdotes? Anecdotes are nearly useless as proof unless you place them in a statistical context.
Table-ized A.I.
No, bub, you're completely wrong. That's why the 's' is smaller, to separate it from the main word. (The only "excuse" for the apostrophe was to separate things out so it was clearer that you were referring for example, to CDs == more than one CD, instead of CDS == some acronym for something.
>>An apostrophe is commonly used to denote plural for acronyms and such, hence it is perfectly correct
Ever heard of logic, bub? MS Frontpage is "commonly used" to write web pages, but it doesn't mean it's correct (or even sane). The word "it's" meaning "belonging to it" is "commonly" written with an apostrophe, despite its (haha) being completely INcorrect.
Check "Fowler's Modern English Usage" if you doubt me.
Not only that, but the author of the article writes things like:
"...just as messy and more confusing than it's competitors"
(There are loads of incorrect "it's" in the document).
"1980's languages"
(Nuh Nerrrrrr. Wrong again!)
"Even OOP's goal's are not clear"
(How anyone can even *start* to justify the above is beyond me. It's a simple fucking plural you great fat illiterate fucking god-damn lobster-dating fuckwit, sponge-for-brains!)
As I said in an earlier post, (regarding the author of the original article): How can we take seriously a person's views on language semantics when he can't even use the syntax of the language he's trying to convey those ideas in? And don't give me that "maybe English isn't his native language" nonsense, because if he's German he could have written the article in German and I'd point out grammatical mistakes in that... (Except that it's mostly English Language lusers who can't use their own language).
And don't moderate this down, because I'm damn-well right. I can let all sorts of bad grammar pass in ordinary posts, but when some fool tries to "inform" slashdot readers of grammatical rules and is wrong, I WILL NOT LET IT PASS.
Thus the great lemur spoke, and lo! the people beheld his words and were in awe!
Graspee
So, as we can see, he obviously has no clue, just like 90% of Slashdot readers
Again, I would have to look at your specific case in detail.
Perhaps your previous procedural approach was crap. Often when I examine such claims, I find bad procedural/relational programming techniques. It is not taught/updated anymore because it fell out of style.
Self-fulfilling prophecy
Also, see the links on my webpage about code resuse.
Generally I find anything that cannot make use of deep inheritance hierarchies to have just as much re-use potential as OO would. Thus rule of thumb has never proven me wrong yet.
Table-ized A.I.
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.
If you have a good foundation in C and C++, you can imagine how all the C++ code will be "translated" into C code, and then from there into assembly. (C++ code is not really translated into C) This allows you to create efficient code, because you can tell when using an object poorly will result in inefficiency.
For example, using a call such as
cout << "hello" << 59 << 10.2;
uses 3 function calls, whereas
printf( "hello%d%f", 59, 10.2 );
uses only 1, and is more efficient overall.
The other aspect, designing good object abstractions is much more subtle. Some people seem to come at it naturally, others never do. I suspect the answer is simple: If you like creating object heirarchies, and are flexible in changing them when you realize that they are flawed, you should do well. The only way to get good at that is to practice it. You will feel the point when your designs are more often helpful than harmful.
http://members.wri.com/johnnyb/comppapers/factorin ginheritance.html
The link appears to be down right now.
Anyhow, it is still the same problem of trying to squeeze differences into mutually-exclusive subtypes. The differences in "things" often need a finer granularity than what is offered by subclassing.
Interface inheritance is little more than inheritance without teeth IMO.
Table-ized A.I.
So admitting to being the author of the original article and then restating things in that article gets you a "4- interesting" these days? WTF is the world coming to?
Graspee
For the proof that its not.
:)
You've been served with objective proof against your point before - that you've ignored. I don't have the original link - but you do, don't you? Post it for everybody to see.. then we can post the links that you had in rebuttal.....
You're making a statement. Its your job to back it up.
If all you do is "jump up and rub it in" without any backing.. then... you're a troll.
Addison
>>I might have a big mouth, but that does NOT
make me wrong.
Well, yeah, but the fact that both are true can't be mere coincidence...
Graspee
P.S. OK, so I'm not actually *advancing the argument* here, but since he put "Ah, poor widdle kid. " he deserved to be given a slap. All those in agreement, say "Aye!"
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...
Totally not worth reading. It was just some happy-to-spout-out-idiotic-nonsense that probably wrote part of the Linux kernel. OOP is what builds nice software. It makes things nice and neat. That guy just didn't get the idea. Scott Lloyd
Long live Microsoft!
You don't even have the "smarts" to be able to use apostrophes correctly so I suggest you cease and desist...
Nobody will ever come up with 3 "biz app/model proofs" that satisfy you because even if they were damn good you would just nitpick.
You just don't sem to realize that there are some things which cannot be "proven" in a scientific way.
Asking someone to "proove" that OO is superior is like asking someone to proove that John Donne's poetry is more sophisticated than Shakespeare's, because:
a) whether it *actually is* is partially a matter of personal preference
b) The reasons why it is are abstract and not quantifiable.
You can't go round counting lines of code or timing how long projects take to write. What are you some Dilbertian nightmare IT manager?
Graspee
You forgot about them being idiots as well as criminals. Scott
Long live Microsoft!
you can find me at:
e nt
http://pub1.ezboard.com/bobjectorienteddevelopm
It is a good place to get into nitty gritty details (although the message ordering is a little weird there).
Table-ized A.I.
Well, I was in a very large corporation (I'll tell - it was BellSouth). We started our project at a departmental level, using Visual Works Smalltalk on Windows and HP-UX.
We brought in several teams of tutors/mentors to get us going with OOP and OOD. We "got it" and things were going very well. Within a few months, we had a highly functional demo of what our end result could look like and do.
Then, the big corporation management saw that we were having some success and decided to fold us in to a corporate-wide project. We were told that Smalltalk would no longer be used and that the project would shift to C++. We were retrained.
Even though we had our experience with Smalltalk and OOD, HUGE teams of consultants were brought in and we were told to do everything differently. They bought tons of equipment. We were forced to work in other cities for weeks at a stretch. Because of the largeness of the project, NOTHING was ever finalized.
After about a year of this, all of the old, departmental Smalltalk team begged to be released from that project and found new jobs within BellSouth (some dis quit and go elsewhere). A couple of years later, I ran into someone in the corporate project and I found out that the original Smalltalk demo we had produced was still the only real output. Even better, the management of the big project still used it to show off what "they" were able to accomplish!
He did mention some things along these lines in the article. (It has been several days since I read it, so I don't remember the specifics). I am generally talking about the parts where he was emphasizing that everyone on the project has to buy in to the same methodology and have excellent team-wide cooperation. IMHO, the larger the team, the lower the liklihood of this occurring.
Hmmm. I have to admit, there may be biz applications where other techniques are more effective, faster, etc than OOP. But I find, as complexity increases, it is important to start thinking in terms of seperate, smaller units communicating through interfaces, or atomic peices being acted on by functions or procedures. I've worked with procedural code, some of it quite complex, and written by several people. The best procedural code, the code that was easiest to modify and had the least errors, worked under a small component model. On the other hand, the stream-of-consciouness code, where the structure of the data and code was not thought out, was the most error prone, the hardest to debug, and the most difficult to change.
If I had a OOP language like C++ availible on the machine (which only had Fortran), the "good" procedural stuff would have very easily translated into OOP, while the "bad" stuff would take quite a bit of work, requiring some reverse-engineering and redesigning. There were some parts, however, that appeared to work best in procedural code (possibly the scedulers), which we may have left alone.
This has been my (limited) experience, that as complexity increases, thinking in an object-oriented fashion makes code cleaner and easier to maintain. This is the problem, though - you have to demonstrate a complex system, that would neccessarily be harder to understand, to prove this point. It's not enough to show a "Hello, World!" program. Mininum requirements would be a program large enough to seperate into many modules, with at least 3 non-trivial components (for instance, text processing, a GUI interface, and file management), and, once a working program is completed, try to make a modificiation. Oh, and you'd have to do it once in an OOP language/style, and once in a procedural language/style.
It's too much to show in a quick example, and businesses don't have the resources to do both, just to prove it to themselves. It's a little like the Windows/Linux debate - neither arguement is convincing unless you try both, but who has the time in a business environment to experiment with operating systems/languages, in a fair and balanced way? If that's the case, then your business is probably in trouble, because you don't have enough work to do!
(* I read numerous IT journals and periodicals and I have not encountered anyone uttering these alleged myths. *)
Well I *have*.
(* "Myth: OOP is a proven general-purpose technique "
Again, this a broad sweeping statement that I have not heard anyone assert. *)
I just got done responding to a poster (OO fan) who AGREED with it. Go argue with him instead. QED.
(* The idea is that polymorhism -- implemented correctly -- will eliminate the need for 'mainline' case statements that need to be amended to add new options. This is pretty straightforward. *)
No, it is NOT straightforward. It often exchanges one type of duplication for another. See my Shapes webpage.
(* Myth: Only OO databases can store large, multimedia data
Not even OO vendors say such a thing. Another straw man. *)
From Meyer's OOSC2:
Page 1051, "[relational DB] types are drawn from a small group of predefined possibilities (integers, strings, dates...), each with fixed space requirements."
I have also read similar implications in trade rags.
(* Myth: C is the best procedural can get.
Did you make this assertion up ? *)
Examples comparing C to C++ and indirectly implying the differences are paradigm differences are very common.
(* The salient facts are the sizes of the applications and their data oriented nature. *)
OO proponents disagree widely about whether OO only shines (signif) for larger projects.
(* OO has been around since the late '60s (Simula) and C++ (the most popular OO language in industry) is more than 20 years old. *)
I was talking about entering mainstream, not its birth. The fat client fad also lasted about 11 years before showing a decline.
(* VB for the interface, C++ for the actual application logic. This was the case even before VB4 when some OO support was introduced. *)
C++ for business logic? Yuk! That is not what C++ is meant for IMO. VB, Java, and even COBOL are probably a better fit than C++.
(* Have you actually had any experience with a business system that has several hundred "entities" (in the relational modelling sense of the word). I can tell you -- as can many case studies that you obviously don't nother to read -- that OO greatly aids in the management of the complexity that several hundred interrelated entries presents.*)
Bullsh*t!
OO only makes a difference if there are useful hierarchies in the model. If not, then the relationships in both paradigms will be very similar.
You called me a million names, but STILL gave no inspectable proof that OO is better.
Typical. All talk, no walk.
BTW, there are other issues besides the "myths" that would make more interesting technical debates (like method boundaries). However, you would rather dwell on social aspects and resume bragging it seems.
Table-ized A.I.
Show me your proof! This is yelled incessantly at all who disagree. However, Bryce is not capable of proving his points because he has been shown time and time again to not know anything about object oriented programming. If I spout enough nonsense about a certain subject...one or 2 points may actually sound resonable...even if I don't know what the hell I'm saying.
(* GUIs are OOP? *)
I don't remember claiming that.
(* Where I find OOP useful is in constructing frameworks. The standard Python libraries are a fantastic mix of procedural and object oriented. For example, take file-like objects. Where some task involves stream-oriented actions, file-like objects are provided. They can then be used by other code that expects file objects. *)
That is a systems programming domain, which is outside of my complaint scope. Being good in domain X does not necessarily translate into being good for domain Y.
Anyhow, I talked about sockets and streams a little bit in another message around here somewhere.
(* There are just too many things to pass around and remember [in procedural]. *)
Huh? Example? What are you passing around? Perhaps I can give you some procedural/relational tips.
Table-ized A.I.
An exaggeration. Anyhow, Perl is KNOWN to have problems WRT readability. People tend to find languages and paradigms that fit their own way of thinking and organizing. A lot of programmers have trouble reading their OWN Perl a year after they wrote it. As it goes/went mainstream, how non-diehards react to it *is* important. That was my main point.
He's also IIRC called Turing, Meyer and Dyjstra idiots....
Now where did I call Turing and idiot? You are WRONG. Your memory has failed you before. Why should one believe you now?
But no.. no amount of real world examples will make him back down
How do you know? So far you have only tried ZERO. How can you extrapolate zero into many?
Addison, you are an unscientific jerk.
BTW, learn to attack ideas, not the person. What do perl debates have to do with this? A point I make about OO should stand because it stands, not because of something else the author said. It is evidence of Addison's club mentality.
Table-ized A.I.
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.
However, the object orientation, well used, tends to produce a more readable code, a more reusable code. The reusability of a code is very important. Doing a perl module and submiting it, is better than doing a quick and dirty script to do the job. Plus, I think this is a good exercice to the programer, as the usual approach is functional. It helps structuring code.
Of course, it takes more time.
The benefice for the community is an objective to keep in mind.
xavier.
It's clear that the slashdot community includes a healthy portion of experienced professional programmers who know their craft and aren't afraid to call flamebait flamebait.
Yes, I've poked through slashcode, I know a bit out Taco's mad skillz. I also know that every single programming shop I've been in for the past 5 years has used object-oriented programming to a greater or lesser degree. I've even worked in multiple shops doing object-oriented (gasp) Perl.
Let me leave you with this. There really is a paradigm shift in going from procedural to object-oriented thinking. Those that get, by hook or by crook, to that Aha! find a whole new world, like Columbus, but this one has been charted and mapped -- somewhat -- by thousands of those their predecessors who, like myself, are more than happy to guide them through the scenic areas. Those that don't cross that ocean are like the critics of Copernicus, zealously insisting that the Earth is the center of the universe, while it blithely turns in its orbit, oblivious to their holy war.
Man you know by now he is unable to grasp concepts like this. This guy is an idiot and he just rolled slashdot, he has a huge notch in his belt you think he actually cares about the truth?
War is necrophilia.
If you are talking about Capers Jones LOC study, it is not a good one as I already described on my website.
Just because you can measure a number does not mean it is a meaningful number. At the turn of the century they used to measure intelligence via head circumference. Now, that *is* indeed "objective" because 2 different measurers will get the same result. However, that is not the same as being a good metric for intelligence. This is essentially the problem with the Jones study. Besides, LOC is only one metric. There are several other key metrics missing.
I don't know why Addison is bringing up messy areas from past debates. He is just pissed because he cannot produce 3 examples of superior biz OO code. (Not even one so far).
Table-ized A.I.
>> I'm quite sure you don't remember your paper getting a point by point dissection from people like Tom Christiansen, Randall Schwartz, Tad McClellan, and Uri (God Love Him). Of course, those are folks who generaly Know What They Are Talking About. <<
It is mostly subjective anyhow. There is no agreed-upon standard algorithm that you can dump a language definition into and out pops a "goodness" score.
Computer Science is in the dark ages WRT measuring the merits of languages and paradigms.
Kingdoms simply fight over doctrine and territory.
To pretend like it is a science and quote "experts" is deceiving yourself. It is a turf war and a religious war.
Science, where for art thou?
Table-ized A.I.
(* What is clear, is that when looking at a system most programmers I encounter start to think about the functions that it should carry out. *)
IMO, this models the business world well because things or features are often assigned as tasks. "Make the computer do X" is a common request format. Even in business projects you bring people and teams together to get a certain something done. The OO approach tends to scatter the task-oriented info all over the place.
IOW, it over-emphasizes WHO does something instead of WHAT needs to be done it feels to me. This bothers me about OO thinking. "Who" is less important than "what" in a good many cases.
(* That was the crux of my point. OO might be the theoretical correct way to do things, but actually there are two ways to thin[k] about the architecture of a solution (functional decomposition or entity decomposition) and the thought processes right at the start need to follow the second approach. *)
Why the second?
Often it seems like an orthogonal tug-of-war. The "noun" aspect and the "verb" (task) aspect are indeed both important. However, one is not clearly more important than the other. It is sort of a ying-yang thing: both are needed, but one should never have full control.
Neither paradigm brings both together in a hormonious way. One is simply forced to choose one to dominate over the other. (Given a choice, I usually prefer task-orientation for the code and noun-orientation for the tables.)
Note that this is how discussions *should* flow IMO. Mutual respect for people's opinions and a desire to understand the other side. "Why does X bother you?" is less rattling than "Who of importance says such? Where is your citation?"
Thanks
Table-ized A.I.
There are no reference because there is NO PROOF. Simple.
IEEE and ACM have many good articles on OOD/OOP/OO Metrics.
IIRC, these either were for comparing one OOP language to another OOP language, or they were only comparing engineering applications, a single domain. Most of them also focused on C (yuk). C is optimized for productive machines, not productive programmers IMO.
Table-ized A.I.
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.
The procedural/relational versions of relevant OOP GOF patterns are simpler to manage, view, and construct IMO.
( http://www.geocities.com/tablizer/prpats.htm )
OO Visitor scared me right back into the friendly arms of procedural/relational. Viva Tables!
OOVisitor makes GOTO's look friendly.
Table-ized A.I.
>>This "Real programmers don't use " is getting tired.
...unless you finish with one of the following words:
a) cobol
b) decaff
c) soap
d) sleep
...in which case it is hilarious and should get modded up +3 at least.
If they are more productive under assembler and can easily read each other's code, I have no problem with that. I do not wish to dictate how to make programmers productive, because most know what kinds of tools and languages they work best under.
However, the trick is sometimes finding like-minded members for teams. Languages do this to some extent by attracting certain types of people to them. For example, Eiffel fans are going to approach things very different from say Smalltalk fans. Both have very different, but valid ways to reduce bugs and test.
(I am still not sure about Perl. Can most heavy-Perl fans easily read and fix each other's code? The "more than one way to do things" philosophy means that their may be whole different levels of sub-cultures within Perl thinking. Almost a "build your own language". I don't get it. It still seems to emphasize writing over reading IMO.)
Table-ized A.I.
Hey you commenter, people...
Yes, the article is overzelous.
Yes, the article is light on raw data...
However, buried in with all the noise are a few actual valid points and interesting concepts.
First, there's the point that OOP isn't necessarily the right way to solve every problem. Second, there's the point that if you want to argue that OOP is unconditionally better than procedural, you *shouldn't* use C as an example of procedural, b/c C isn't very representative of its group. Third, there's the interesting possibility of using some paradigm other than procedural or OOP. OOP isn't necessarilly the only way to support info-hiding and such like.
Furry cows moo and decompress.
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
Smalltalk has no compile-time type-checking, yet is considered THE most OO language by many.
IOW, type-checking and OO are perhaps orthogonal concepts.
Table-ized A.I.
Everybody thinks different. That is why flamewars break out.
IMO, software engineering would do nice to have more psychologists in it rather than be dominated by math whizzes.
(I will be posting a webpage one of these days about how *I* model the world in appliations.)
Table-ized A.I.
Well, I will pit well-designed procedural/relational apps against well-designed OO apps any day.
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.
Thus, what is left?
Table-ized A.I.
No language is bozo-proof. Don't blame the language, blame the bozo.
Who is going to read that roll of paper ? Forget it !
OOP debunking seems like a great waste of time itself. Better write your stories in C and publish them to GCC.
I never disagreed with this. If it is subjective, then my fav paradigm deserves tools/research/respect just as well.
The reasons why it is are abstract and not quantifiable. You can't go round counting lines of code or timing how long projects take to write. What are you some Dilbertian nightmare IT manager?
Those are the guys who usually pick the paradigms, for good or bad. If you can't justify OO in some quantifiable way, then it will be tossed or fade.
Thus, metricize it, or risk kissing it goodbye.
Welcome to business reality, dude.
Table-ized A.I.
>>Bertrand Meyer hinted this in OOSC2. (See OOSC2 critique section). Many trade rags also imply similar things. Is Berty silly then?
Yes. Bertrand Meyer is a freak. Just look at the bondage-and-discipline language that is Eiffel and you will know it for yourself.
Graspee
> 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.
Show me clear, objective proof, and I will shut up and go home.
I don't want:
I want clean, clear metrics. Examples would include lines of code, change points given a dozen typical change scenarios, etc.
That is such a simple, basic request, but you guys simply cannot do it.
You don't want to race your car, yet yell at me for complaining about lack of evidence that it is faster. That is what it all boils down to. If you make the claim that your car is faster, then you must agree to race it or shut up.
Table-ized A.I.
I just had a vision of an S&M girl whipping Berty's behind as he crawls around reciting Eiffel philosophy.
Somebody ought to make a little simulated movie of that. Developers would get a good laugh. (At least the non-Eiffel fans.)
Table-ized A.I.
Well, I don't have much argument there. It is not hard to beat C (depending on who ranks the metrics. What bothers person A may not bother B).
How can you feel qualified to write an opinion piece on design technique (OOP) if you can't understand this without an example???
Quoting OO scripture itself is not sufficient. One has to look at real-world situations. For example, RDBMS can provide data protection via triggers, referential intregity, etc. Thus, it is not an all-or-nothing thing. Protection also can create red-tape for developers. It is a delicate balancing act.
BTW, who said anything about business programming?
It is the main domain of the very source of this discussion.
Where's your pennacle [sic] of procedural languages? Ada?
I think OO hype killed progress in procedural languages. Vendors stopped tuning the procedural side and instead focused on OO-itizing them all. Thus, I am not very happy with existing procedural languages.
Table-ized A.I.
This does not make sense. It is YOU who needs to provide the proof, not me. I never claimed that X was objectively better.
You can complain AFTER you present the proof. Until then, stop speculating about my future behavior.
Table-ized A.I.
But nobody can describe exactly HOW. How does it increase re-use over a procedural version? How are you measuring the increase? A warm feeling inside?
The few times that people actually present something inspectible, I find that their procedural approach is not up to snuff. They were poor proceduralists (at least with what they give me to compare). They indeed do work better with OOP because their mind does not work with procedural code well it seems. They just think in objects. I don't.
I can match it 99 percent of the time. Unlike you guys, I am not afraid to put my code where my mouth is.
All you guys want to do is talk. Code instead. Show me code. I am NOT afraid. I can compete with your OO code "proof". I don't need government quotas to protect me.
Table-ized A.I.
I didn't say the interface isn't important, it is. What I meant to say is that a lot of companies are aiming at reuse, while they should be aiming at reducing maintenance costs.
This comment says it all:
>I don't care how a module works, only that it does.
You want software that works. Only structured code can be debugged properly. Of course the interface should be good, so code gets used properly. But this has little do with the 'blind' aim for reuse. Companies should push their programmers to write solid code, not to reuse as much as possible.
Reuse should be based on a commitment at the beginning of a project. A reuseable piece of code should be identified and written as such (i.e. in a general, multi-purpose way). It then should be refined and used in multiple projects. Code reuse should not be based on just ripping code out of projects. Remember the ariane-missile? It failed because of improper reuse. The code was not designed for a launch with any missile, but only with a specific one. It worked with the first missile, but not with another.
The Drowned and the Saved - Primo Levi
I had to do a double-take to make sure I did not write that myself.
(I swear to God, Buddha, and Darwin that I did not write that message.)
The world is a big graph (network). Changes change in graph-like ways, not tree-wise. Trees don't hack it in this environment.
Of course the typical OO fan response is that you "don't have to use trees with OO". But without trees, OO is like a Paul McCartny without music. It does not do or have anything really special or different about it. Modules provide similar grouping of functions (methods) and RDBMS provide the state. IOW, nothing that procedural/relational does not already easily provide.
Table-ized A.I.
I'll help you to understand.
Omitting white space really does speed it up; that's because the first thing the Perl interpreter has to do is read in the file, and if the file is shorter, it has to read less. If you *must* use some spaces, then pad it at the end and align it to a 4096 byte boundary (or at least 512 bytes). Also, when the code is tokenized, you don't have to ignore as much whitespace, or allocate as much memory as a buffer. All of these are improvements.
Enforced scope is fine, if you only need a variable in that scope; that's what my is for. But why always deallocate and allocate off the stack when you can have a few permanent, reusable memory locations? This is especially true for replacing extra loop counters, or getting rid of variable allocation in tight loops or small subroutines. Why be so wasteful?
Also, $m is a variable, and probably a mnemonic as well. $m2 is another $m distinct from the first. $mt2 is probably a temp variable, maybe for $m2. See the simple yet concise variable naming scheme at work?
So I suppose this self-taught programmer also considered comments and documentation to be a waste of disk space? I'm sorry, I've done that before. Managed to delete a lot of silly code, too...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Although a proof-of-concept has never really been tried, I disagree with this without proof. Sure, some of the early procedural GUI frameworks sucked, but that is because they were pioneers.
I hate it when people make such statements without proof.
Table-ized A.I.
They put switch statements at each call site. If you know you have three subclasses (A, B, and C) then you produce code like this: /* inline A's code here */
/* inline B's code here */
/* inline C's code here */
/* Normal jump table thingy here */
switch(type_id){
case A:
case B:
case C:
default:
}
--
Patrick Doyle
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I meant "proof of concept" of a table-oriented GUI system, not a procedural one.
Table-ized A.I.
The benefit is time to market.
If I have the chioce I use OO and C++, so I'm faster than in pascal.
And if I have the scale of the project (+5 years running time for enhancement development) I can try to build a framework or several framelets.
In the long run a oo development environment beats a procedural one by a 50% to 100% productivity increase, so what do you argue?
Take a mentor and go for it, if you would know what you are talking about, you probably could indeed do somthing constructive and give advice what to do better but currently you only talk crap.
a'o's
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Perhaps you could model them as a bag of *indepedent* features rather than try to filter them through a hierarchical taxonomy.
I'm not exactly sure how something like that would work.
I suppose one way would be to have base classes like Readable, Writable, Seekable, and Selectable. Then each class, like FileStream would be derived from just the ones it implements. But that doesn't really make the problem of things appearing to do more than they can go away, because what a FileStream can do depends on what you open. Ie, you can select() on /dev/tty but not /etc/passwd. You can lseek() on /etc/passwd but not /dev/tty. And besides, it makes everything considerably more complicated to have lots of multiple inheritance involved.
Another solution might be to make each of these -- Readable, Writable, Seekable, and Selectable -- something you get from the Stream. Ie, you have a stream and call getReadable() on it. If it returns null, you can't do that. It would give a complete picture of what the object could do, even if it changes at runtime...but it would also make it slightly more complicated to do basic operations. I don't really like that.
My solution to this problem is to put most of these things -- read, write, seek -- all the way in the base class. I also have canRead(), canWrite(), and canSeek() members to tell me if these options are available. (If you try to use read(), write(), seek(), or tell() when they are not, a CallerLogicError is thrown.) Since the answer can change at runtime, this seems to be the only real option to me. Plus, this way makes the interface very simple and easy to understand, a big goal for my project. It doesn't perfectly model everything, but it's better than having a different set of functions for dealing with each type of stream...a complete pain to use.
StreamSocket, on the other hand, is a dogcat. I gave an abbreviated version of my inheritance. More completely ...
... so StreamSocket combines the attributes of a stream and the attributes of a socket. It can be closed, created, connecting, connected, or listening. (bound is not listed, it seems to be optional when either connecting or listening.) Most socket options are available in any state. Most stream options are available only when connected. I had to design the Stream interface a bit carefully so this wouldn't violate it. In particular, its isClosed() and isOpened() checks may both return false, if the StreamSocket is in one of these other states. So far, this choice works well. StreamSocket gives much of the functionality of the basic UNIX system calls already, and I see no reason it can't eventually do it all. All while being fairly easy to use.
Anyway, thanks for the suggestion.
How? You just got through saying that most of the time inheritance is used sparingly in good OOP?
What is left? Encapsulation? That is a loaded issue because what aspect to "encapsulate" by is not cut and dry.
The advantage OO has is that it is a discipline that describes how you write well-designed components.
So OO is all about component design? That does not sound like a majority OO fan stance to me. Besides, the making of components themselves are not what most custom application programmers do. Does that mean that OO is nearly useless for them?
Procedural is not analagous to OO, as it does not prescribe in any way how you properly design your code.
I disagree. 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.
Table-ized A.I.
Welcome to the world of OOP.
"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."
I get answers all over the spectrum when I ask when, where, why, and how big about OO's strengths and weaknesses.
I don't have all the answers, but niether does anybody else.
Table-ized A.I.
I agree that there is a strong lack of organized planning. That is actually a more important issue than which paradigm to choose. However, it is not something that switching paradigms can't fix. There are no real rewards for planning in most organizations. Bad code often is job security. Bad code is like a cypher that only the author knows.
I have personally seen massive improvements in my coding since I've started using an OOP style with thorough documentation and formal notation.
If it is truely "massive improvements" then it should be easy to demonstrate exactly how this comes about. I here jillions of anecodotes, but rarely anything real. (And the few real ones turn out to be language-specific or comparisons to bad procedural/relational practices.)
Table-ized A.I.
The reason you went nuts trying to figure out the syntax for WHILE is because the only way to do WHILE loops in FORTRAN77 is with GOTO and IF. FORTRAN 5 had WHILE, but it wasn't widely implemented.
What a long, strange trip it's been.
So if they reject it, they are probably "not well informed" in your eyes. AKA Circular logic.
especially the Y2K one, where did he hear this [myth]?
Bertrand Meyer. Ever here of him?
This is absolutely true, but the pay-offs are more than worth the time expended. One only needs to look at the explosion in the component marketplace which had risen to over $600 million in 1999. Components don't only increase re-use, but are good financially for developers on the buying and selling side.
1. I was most talking about custom applications, not wide-market components.
2. Components != OO
he points out OOP's inadequacies at this. Nothing is perfect, but are the alternatives any better?
Yes! Procedural/relational modeling generally does not depend on the real world matching trees, for one.
His code sample shows that he doesn't even bother following encapsulation.
Which one? There are about 50 on the whole site. What? You didn't read them? Surprise surprise.
I would suggest to this author to read "Design Patterns."
Procedural/relational does most of them better, as already discussed. (Or, at least equal.)
NEXT!
Table-ized A.I.
You seem to be in the "OO best for large projects" camp. I get wide ranges of opinions on this when I ask OO fans. Some say that it *is* only meant for large projects, some say it helps for their small and medium projects also.
If it is the first (large only), then more OO books and training/PHB-intro materials should point this out. If it is the second (all sizes), then you appear to be wrong.
Table-ized A.I.
But they don't agree on WHERE one is better suited. IOW, a philosophical overlap.
Your last sentence seems a bit ironic, since it just may be that there is more than one right paradigm.
(I just love to pull the pins out of the grenades and toss them right back.)
Table-ized A.I.
Good. This is all moot then. Hear that Berty Meyer? You are now Legacy Man.
currently we are working on Subject Oriented and Aspect Oriented programming.
Oh, I see. A Buzzword Lab. Hey, I always wanted to see Hallucination Oriented Programming, where applications make managers imagine benefits.
That everybody and his dog can programm with Visual Basic does not mean that those are programmers.
Yeah, they have to be certified by you first of course.
I KNOW for my own that OO is the better concept.
But like most other OO proponents, you couldn't articulate the reasons for the specific benefits if the KGB tortured you for 20 years. OOP kills tungues.
Table-ized A.I.
In the most long-winded way imaginable, the author has said "OOP doesn't live up to its hype" and "OOP wasn't a silver bullet that quickly and easily improved the quality of his work."
Duh.
Before the web came along, OOP was the most hyped thing in technology. A lot of people made their livings selling snake oil in the form of books, seminars, methodologies, training courses, tools, libraries, etc. These leaches are just out there. Always have been, always will be. And they aren't just in tech. Pick up an investment rag and look at the ads. They're ridiculous. They're the culmination of almost a century of hucksterism.
Professionals have the responsibility to see through this and find the kernel of useful genius that made the topic so cool in the beginning. Believing the hype always leads to bitterness and regret. Creating the hype leads to a painful demise (I hope).
OOP tools are a big improvement. I like a lot of them, but none substitute for good techniques. How something (anything) is constructed has more significance in its final value than what material or which tool is used (except for things made from rare metals or minerals). I spent some time around IBM as a kid, and the acronym seen everwhere was TINSTAAFL - There is no such thing as a free lunch.
Don't believe the hype, and don't waste time being pissed off if you did. That's just more time wasted. You're young, your smart, go build something!
>> He didn't mention maintainability much in his rant. Perhaps because it would be a major counter point to his assertion. The only place where I can remember it even being mentioned was in an idiotic metaphor with automobile mechanics. <<
:-)
I usually use the word "change", not "maintainability" (Too hard to spell
It is discussed often WRT to "change points". For example, issues about case statements and how many places need changing per change request. I talk about it also in the "goals" section.
Table-ized A.I.
I was simply addressing the "real world" issue, since that was the heading it was under ("encapsulation" remember? :-) Whether a class can be modified or not and the protection value/problems this solves/creates is another issue that is brought up other places.
For example, the "set/get bloat" complaints debate.
Table-ized A.I.
>> For instance, when you go to design a GUI, it's much nicer to create a button instance and pass that to a form, than to call a function that puts a button on the screen, and continually have to keep track of all the details. <<
That is *not* how I would design a procedural/relational GUI interface/API. There are several other p/r techniques for this kind of thing.
>> IMHO, the strengths of OO programming only arise when you are writing a code base for *other* people to use, simply because it encapsulates everything and provides an abstracted interface. <<
This can be done in procedural/relational also. It is just not a buzz-concept and nobody bothers educating people how to create procedural frameworks anymore. (Nor researching.)
>> but since most people don't believe this, I don't think it qualifies as a myth. <<
What percent have to believe it to qualify as a myth? (My rule of thumb is hearing something from 2+ different OO fans.)
Table-ized A.I.
>> want an object to populate itself from the database? Call it's GetData method. <<
How is this different from:
handle = openDB(query)
>> We've also standardized that each object tells IT'S children to populate/save THEMSELVES <<
Children? What are these children? Remember, I am skeptical of hierarchical business modeling. Details?
>> Can you do this in a procedural language? Of course you can, but it's easier in an OOPL. <<
How do you measure "easier"? Less code? Prove it! Less change points? prove it! It makes you feel warm and fuzzy inside? Well, I will leave that one to your boyfriend to check.
Table-ized A.I.
>> The author does allow that he is not informed on enterprise level needs/development, but from my sandbox, OOD is the best thing since slice(bread). When coding for a paycheck, freeflow art usually doesn't last/can't be maintained/extended/scaled. <<
Where did I say I was for "freeflow"?
Regarding enterprise-level, I think relational tables are better for managing large amounts of stuff because you can view/query them by multiple aspects. OO's "everything in one class and only one class" thinking is small-time.
Table-ized A.I.
I picked "oopbad.htm" to help *me* remember it. "oopislessthanperfect.htm" takes up too much typing and I only had 8.3 (DOS-based) backup systems at the time. Now there are too many path references to change it now.
;-)
Next time I will use an ID number
Table-ized A.I.
... the pins back, 'cause your house is full of holes from all the live grenades you left lying around...
Regards,
-scott
Regards,
-scott
>> 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. <<
k
Encapsulation often refers to 2 things: 1. protection, 2. physical closeness.
#2 is purely a view-issue. What block/method/thingy appears next to what should be purely a *view* issue. Think abstract. OO *hardwires* everything into a narrow view (one class per method). That is inflexible IMO.
Regarding protection, that is something we should take somewhere else because it is quite involved.
>> 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. <<
For my view on Y2k, see:
http://www.geocities.com/tablizer/meyer1.htm#y2
>> 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. <<
Prove it with code. Show the world.
(I admit I don't fully understand OOVisitor, but I don't understand it because it is messy and has too many parts and cross-references. That is not a good thing. Software should be easy unless there is no other choice.)
>> ER data models are nothing more than collections of DATA and ways of relating the DATA. <<
That is only *one* approach to modeling that should be used in *conjunction* with other approaches. ER allows you to deal with "what" without having to worry about "how" at the moment. That helps the thinking process. It breaks planning into managable chunks.
Table-ized A.I.
Good! Then you of all people should be able to explain and/or demo in detail why it is "better".
I am tired of vague Zen explanations. Let's get back to science and rational deduction, people.
the examples given in this article are terrible
Oop! Vague metric. I guess you are one of THEM afterall.
Table-ized A.I.
Damned right it is. That is because it is easier, corresponds to the way many people think, and doesn't require fragile taxonomies or fragile type-dichotomies to make it work like the animal and shape examples of the textbooks.
Table-ized A.I.
>> worked under a small component model. <<
Do you mean OO components or procedural components? Components can be made procedural. with the better p/r langs, they even highly resemble OO components (or should I say OO highly resembles a certain kinds of prcdrl components?)
What did your components do?
>> It's a little like the Windows/Linux debate - neither arguement is convincing unless you try both, <<
Even if you try both, you get different opinions. They both shine in different ways. The differences can even be identified in ways that OO (alleged) benifs have not. You can say that Linux is more reliable, while Windows has more GUI management features. (You can count up-time and you can count the percentage of operations that have GUI equivs.)
This kind of info is not avialable for the paradigms. Try to think of the patterns of OO being (allegedly) better and why. Then see if you can create a little exaggerated skeleton example to show them.
Somebody somewhere has GOT to be able to articulate the benifits with examples. It cannot be that hard, is it? Wierd weird wierd weird.
Table-ized A.I.
You HAVE to have the methods as part of the structure in order for it to be a self contained "object".
What are they compiled into? A vtable, or a pointer to an array of method pointers (one array per class). I've seen similar polymorphism in the Allegro library's BITMAP structure.
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
Then again, OO fans would not know a refined metric even if they inherited one.
Chart of OO fan metrics:
1. Sucks
2. OK
3. Good
4. Very Good
5. Very Very Good
6. Very Very Very Good
7. Very Very Very Very Good
Know how the measure? Vote on comp.object or at Booch birthday parties.
Table-ized A.I.
>> I am generally talking about the parts where he was emphasizing that everyone on the project has to buy in to the same methodology and have excellent team-wide cooperation. IMHO, the larger the team, the lower the liklihood of this occurring. <<
So you think that a harmonly of like-mindedness allows the team to communicate and cooperate easier? But on a larger team, this is less likely to happen because it will be harder to find such a large quantity of same-minded people?
Now that I think about it, a book called something like "Rebirth of the American Programmer" had actual statistics that showed or hinted this for Smalltalk projects. When the Zealots are allowed to do their stuff together, they are very productive.
I think I tend to agree. When you give people their favorite tools/langs/paradigms, they seem happier and more efficient.
I am that way also.
That premise would make an excellent University research project IMO.
Thanks.
Table-ized A.I.
Lisp (aka Lithp) and its cousin Scheme are both OO and functional. There's no reason a language can't be both; the article shows that procedural languages can also be OO.
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
Do you think that it is because your mind is better tuned or something, or that it is simply a matter of matching the paradigm to the person?
IOW, should the human change their way of thinking to fit the paradigm, or the other way around?
I can understand *small* mental adaptations, but not a complete overhaul unless it was proven to have significant benefits.
This whole paradigm-mind-fit thing is a fascinating topic. When the flaming dies down, perhaps we can discuss it and speculate in more detail somewhere quieter. Things are a lot less combative if all members tentatively agree that paradigms may be subjective, because "better" is "very local".
Any takers?
Table-ized A.I.
You have no argument from me there. However, some OO fans imply a kind intellectual hierarchy whereby the smart ones "get it" and the dull (or Ludite) ones don't. It is these kind of innuendoes that fuel my flame.
It not only makes what I'm creating more 'real', but it divides the application into nice self-contained chunks that can be dealt with separately.
What is wrong with subroutines, modules, and tables for chunk-ification? Also, how are these "less real"?
Table-ized A.I.
It is if all the procedural programmers can't get jobs :-)
I can't remember ever hearing a single one of his supposed "Myth"'s. Where did he get those?
Not this again. There is plenty of material on the site to ponder if you are personally bothered by the myth list. Move on. Enough complaints about the fscking myths.
Some software designs really *do* fit better onto a hierarchical inheritance structure.
I agree, but why is everybody pushing Java et al for those that *don't*? Please explain that one to me.
For goodness sake, OOP isn't trying to "compete" with your (insert your favourite paradigm here.)
Bullsh*t! It sucks away attention and resources from alternative tools, progress, training, etc.
Table-ized A.I.
Applications programming? NO FRICKEN WAY! Even OO fans posting here agreed that hierarchies are often not the best way to model most business systems.
I think where OO may shine is "natural fields" such as chemistry, physics, geometry, etc. God does not change those hierarchies very often.
Procedural is good for some things, functional for others. And there are plenty of projects where OO is a natural fit.
Well, but nobody can agree on what, where, when, or why. That is a sign that it is poorly understood.
Table-ized A.I.
And 9 time out of 10 that's what you end up doing in C++ anyway, just more slowly.
--
An esoteric scratched itch:
Homeworld Map Maker Tool
You ALTERED it from the original. Not very nice form.
Regarding the latter, the OO code could look like this, using the Person constructor:
You did not read it very carefully. I was illustrating a *tendency* of OO to have heavy protocol coupling. A quote from that same page:
"It is true that one does not have to tie classes together in OOP, but I find this practice fairly common, and the result is no longer very 'OO' without it."
(I agree that I should probably move this notice up higher.)
As proof it is common: Sun's Java API's. Very intense protocol coupling.
Well, the procedural approach requires you to understand the parameters to the calcTax() function, and to remember the proper order for the parameters. And, the parameters you pass to the calcTax() function are in essence the attributes of a person necessary to calculate the tax -- so conceptually, you have to know just as much about people and taxes in either approach.
1. A few parameters are easier to grok than the meaning of a protocol name or object instance.
2. Ordered parameters are NOT the only procedural way to pass parameters. You are the second person to make that error.
3. The quantity of attributes needed to calculation tax could be significantly less than that needed to set up a Person.
4. I often pass table handles instead of parameters in real applications. ("Structure coupling")
In the procedural approach, the calcTaxes function would have to change.
The OO approach may *also* have to change depending on how it gets Person information. Besides, it is best to use a system-based identifier rather than external info like SSN anyhow *up front* in relational design. Thus, it should never change, barring something really different, like alien taxes or Siamese twins.
But this guy seems to be advocating a return to traditional procedural (not functional) programming, which be a big step backwards.
Oh, I get it, New == Good.
FYI, relational theory is NEWER than OO.
But, the guy should read "Design Patterns" regarding why aggregation is often a better tool than inheritence. Saying the OO people think that the whole world can be represented in an inheritence hierarchy is attacking a straw man. Contemporary OO gurus don't think that way.
Like I said in the "Paul McCartny" message, OO is nothing special (different) without trees. I won't repeat the details here. If you are not going to use sub-typing, then you might as well use procedural/relational
Oh, and inheritence is not primarily a code reuse mechanism -- it's a typing mechanism.
I guess that means that Smalltalk is not up to snuff for reuse?
Table-ized A.I.
As for disadvantages of OOP, I don't see any. I don't see why object orientation and structured programming are mutually exclusive. I often use both in a single program, and really, they share some of the same goals and benefits.
Where I find OOP useful is in constructing frameworks. The standard Python libraries are a fantastic mix of procedural and object oriented. For example, take file-like objects. Where some task involves stream-oriented actions, file-like objects are provided. They can then be used by other code that expects file objects.
It doesn't take much extra effort (for me at least) to consider future extensibility. If I can write two classes instead of one (same amount of code, different organisation) and have it so that I can plug in future extensions then I get some benefit for little (or no) extra effort.
There is no downside to using them both, together. Although, I have to say that I find that whenever I start off in a structured way, I find that I miss some of the power of the object oriented way and end up converting. There are just too many things to pass around and remember.
I'm afraid I just can't agree with someone who seems so emotionally involved in their argument.
Heh. Again, I have not made myself clear to this troll.
My point is that you cannot say, "This project, which took 5 years to develop, did not actually write a line of code for the first 2 years of development. Therefore, no project which will last less than 2 years should use OO, because they will not write a single line of code."
You are, apparently, trying way too hard to see the forest, here, buddy, and forgetting that you need to back up each individual tree. Maybe if you started writing down some of these references when you make them up############come across them...
-=Best Viewed Using [INLINE]=-
Person_Tax class? I think even most OO fans will winch at that. Division lines in procedural/relational are so much easier to "figure out". The tables are the main nouns, and major tasks/verbs are modules. This works about 85 percent of the time. Simple simple simple! Viva p/r man!
I would be willing to bet that modules and tables would be very similar between good p/r programmers, but classes would be wildly different between different good OO programmers.
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 ....
You sound just like those OO "brochure" books. Sounds wonderful on paper, but is full of holes in the real world. Sometimes you don't want some things to "trickle down" and the pattern of exceptions is NOT hierarchical. The real world and it's changes are NOT HIERARCHICAL. It does not care about trees. What force of nature makes business things follow/change along tree branches? I see none.
There is an allegedly true military story of an OO combat simulator. They took a copy down to Australia for a demo down there. To add some local interest, the modelers decided to add kangaroos to the scenery. Rather than make the kangaroos from scratch, they decided to inherit from the Soldier class, and then override the methods that were different. During one of the sessions, the kangaroos took up arms and started shooting at the users. It seems they forgot to override/disable the combat behavior method(s). The point is that absorbing behavior via "trickle-down" has to be done with care. Automatic can be too blunt. (I have more examples on my "buzzwords" page.)
(I would probably have modeled battle entities with a feature list. One then checks off or selects the feature strategies needed for any new battle entities. It would be a big, flat panel of selections. That way you can get more combinations than trees would allow. However, the military would still probably click the wrong checkboxes and still end up with mutant roos.)
and this could be extended for various types
You are assuming that taxing can be nicely split into "types". I question this. The only time things come close is if the "types" are so different that sharing is minimal. For example, calculating taxes for corporations and calculating taxes for individuals are *so different* that the shared stuff would be very minimal (and probably best modeled via financial "roles" instead of hierarchies because most of the shared stuff is financial, and involves more than just employees and clients).
BTW, I just yanked the original tax example from my webpage. It introduces too many side-issues and tradeoffs to be on the front page. This just causes confusion and flames. The later "black box" example covers the same concepts anyhow.
Table-ized A.I.
But the confusion and workarounds to the bureaucracy might even introduce errors in itself. Bureaucracies are usually full of rules intended to protect and keep-in-check. Try getting a business license in India for example. You may have to visit dozens of agencies to make sure you are not polluting, disturbing, hampering, etc. with anything and anyone with any political or legal protections. Indian politicians would love Eiffel (the language).
The athor actually makes a few good arguments, but it takes some effort to get past laughable comparisons like OOP and Communism.
Bertrand Meyer made a few silly political analogies in his book, but nobody seems to be complaining or calling him a "troll". DiscrOOmination!
Table-ized A.I.
Anyway, don't sweat it - in another few years, some new programming abstraction will sweep procedural and OO right off the map, and we'll all bitch and moan about how much our old ways beat the newfangled Neural Network-optimized Stack Developement Abstraction Model, or something.
BTW, my comment is a fiiiiiiiiiiivvve, not a fooooouuuuuuuuuur.
Of course! They make a lot of strategic decisions. My article audience is not limited to just programmers.
But it's just one way, among others, to go about modeling and solving your problem.
Indeed. But, the OO approach is over-hyped and thus choices are harmed because it sucks away resources/attention/research/training from other approaches.
All I really ask for is balance. The hype on my page simply mirrors the OO hype.
Table-ized A.I.
>> Oh..so he hasn't provided any examples of superior OO code <<
NOPE. Jay posted some pattern examples, but never gave any clear metrics about why he liked them. And no, "If you knew OO as well as I did, you would feel the benefits, not needing words" Zen crap. This is 2001, not 1001
>> much the same as you never having produced ANY examples of the mythical ITOP code, <<
Not relavent to OO superiority claims. Red herring from an old debate enemy.
Table-ized A.I.
At least I know how to make paragraphs.
His says that this is complicated: T t; t.att1 = value1; t.att2 = value2; t.att3 = value3; t.method(); But that this makes sense: fn(value1, value2, value3);
Where did you get this from? Why is everybody obsessing on parameters? I did NOT say "always use parameters instead of structures".
If OO is so overhyped then I'd like to see a non-OO library that does container classes and algorithms like the STL. vector myvector; // add elements to vector myvector.sort(myvector.begin(), myvector.end(), ANY_SORT_I_WANT()); No no, i *like* sending pointers to functions around in my code... that's safe, right?
Ever heard of a RDBMS? I almost never use arrays and hashes in a decent p/r system (except possibly as an interface storage mechanism). They don't scale well as new needs come along.
Perhaps a DB interface could optionally use arrays/hashes/linked-lists as the underlying implementation, but that is (or should be) abstracted away from most of the application code in a good interface.
Generic collection protocols are a pet sub-topic of mine. I would be glad to discuss them with you in detail somewhere else. The devil is in the details, and slashdot is too impatient a place to discuss them.
Table-ized A.I.
>> object / functional programing <<
Note that "functional" is a different paradigm than "procedural".
>> The reusability of a code is very important. Doing a perl module and submiting it, is better than doing a quick and dirty script to do the job. <<
Doing *anything* quick-and-dirty is usually not going to result in good re-use.
BTW, Modules are not necessarily the same as "classes", and are found in many procedural languages (depending on how defined).
>> the object orientation, well used, tends to produce a more readable code <<
How do you measure "readable"? Could you by chance supply sample mental steps along with a code/psuedocode example?
Table-ized A.I.
>> No, you ignored my more important points for the sake of poking holes in minor issues. <<
.... <<
What did I miss? Most of it is anecdotal. I squashed anything I saw as not anecdotes.
I defeated your parameter change claims, and your abstraction "missing" claims.
>> Moreover, "bullshit!" is not a valid comeback. <<
There is a whole paragraph below "bullsh*t". You didn't read it well then, and you didn't read it well now.
>> I thought of another problem with procedural languages: memory management. <<
They chewed me out for not providing any references that somebody believed my memory management "myth".
Now I have a reference. You.
>> When you deal with even medium-sized software solutions, you'll probably be using a lot of variables. <<
Most variables are local to a routine or module. The tables handle most of the more "global" stuff.
>> Anyway, don't sweat it - in another few years, some new programming abstraction will sweep procedural and OO right off the map, and we'll all bitch and moan about
Good. Then OO'ers will know how it feels. The new fadcrap won't have any evidence either except anecdotes from the people who's thinking it fits.
>> BTW, my comment is a fiiiiiiiiiiivvve, not a fooooouuuuuuuuuur. <<
Yeah, rub it in mob-boy. They are probably cranking it up *just* to piss me off. I defeated your claims. I have no idea why they like it.
Table-ized A.I.
Another sounds-good-on-paper statement that I have been unable to translate into real benefits. How about a realistic example. I find it hard to draw a single wall around things in a system without creating a nasty little bureaucracy for the team. The "walls" depend on the aspect that you want to view things by at the moment. Aspects are often orthogonal. For example, one manager might want to "lock" things up by region, another lock things up by product line, another by org ranking, etc. OO assumes too many mutually-exclusive walls and divisions. The real world does not offer clean borders like that. The borders are often orthogonal. OO deals with orthogonality rather poorly overall. Look at something like the OO Visitor Pattern. That is the mess created by increasing the aspects by *one* dimension. Add another, and kapoof!
Sparingly is not the same as not at all.
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*).
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.
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.
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.
I hope you are not one of those who try to generitize everything. Even most OO fans seem to agree that this usually backfires because:
1. The orthogonality issue (above)
2. It is hard to make a decent, flexible interface to anything complex.
The idea that you build all these generic tool interfaces and use over and over again via simple plug-n-play is bullsh*t. Time magazine had a hyped-up article on this dreamy idea about 4 years ago. (It is at my in-law's house, so I can't cite it right now.)
I find the most intra-shop re-use from things with simple interfaces. Whenever one "thing" starts to have a complicated interface, it will almost NEVER achieve true genericness. It rapidly turns into a monster as you try to adapt it to new requirements. K.I.S.S. and intra-shop re-use go hand-in-hand IME.
It looks at the processes to be modeled, aka use cases.
This is not really OO, per se.
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.
Bullsh*t!!!!!!
Here is a copy of a message I posted on comp.object:
Title: A 3-Graph P/R Model
The way I model procedural/relational business applications in many ways does model the domain world. The data model (ER) is based on actual relationships between things (customers, products, invoices, etc.)
Then the interface design is based on the flow of the UI (or tasks), which is more or less "real" (at least visually tangible).
Thus, we have one graph (network) for the data and another for the UI/task flow. OOD tends to try to force-meld these two with it's self-controlling-noun viewpoint, which in my opinion is a mistake. (There are some places for potential overlap, but not enough to justify only OOD, IMO.)
These two graphs are then connected usually via SQL joins (you can automate some of the joining in frameworks if you wish). Thus, there are three graphs: the ER graph, the UI flow graph, and the Join graph.
SQL tends to "flatten" the source of the data supplied to the UI/task modules so that you can change the tables or relationships, but a given task still works by only needing an SQL statement change. Thus, SQL serves as a kind of *interface broker* to relate the two. In other words, you de-couple the data relationships from the task at hand by limiting the data source negotiation to one spot (usually early in the task/module).
I don't know if OOD has similar techniques for turning real world relationships into classes in the business domain. OO classes often seem obtuse and unrelated to anything real. They will have names like StateTransitionManager, etc. I don't know whether that is bad engineering or over engineering, but I find it unpalatable.
The 3-graph model has worked well for me and tends to relate to actual, real world domain relationships, and is fairly simple. It is hard to beat that.
I have been thinking over the years how to best describe my modeling techniques, and the 3-graph description is my latest articulation attempt.
(I am preparing a write-up to describe it in more detail.)
Table-ized A.I.
I wish it were that easy. The non-OO choices are shrinking because of OO hype. C++ at least allowed easy procedural programming. Java does not. At this pace, the next language is going to give out an electric shock if one tries to do procedural programming.
The tools, education, attention, PHB approval, etc. for procedural programming is rapidly drying up.
I WANT CHOICE!
Table-ized A.I.
I was counting the *usage* time, not the development time.
If a project which took 5 years to make is no good, then it make only last 3 months, for example. (Then they will sweep it under the carpet and nobody will ever talk about it again unless they are really drunk.)
Table-ized A.I.
>> and OOP *did* make the overview and management of the data-structures very much easier. <<
.....etc..etc.....Z, Z++, Zebra, ZEEK, Zenith, Zu, Zubol, ZZ, and ZZ++. Good communication skills also a must.
Probably because you are a crappy procedural/relational programmer. Most challengers end up exposing this fact.
>> I've been programming for some years now in all possible languages <<
In all 5,000 implemented programming languages?
Boy, I feel sorry for the *follow-on* guy:
---------
WANTED: Programmer, Immediate opening.
Must know Ada, Afa, Amaga, Amonza, Amu, Azure, B, B++, Baana, Beep, Beltran,
--------
>> If this guy only has to *script* twiddly-diddly less-than-10,000-lines programs <<
Most of the systems that I worked on like that were NOT originated by me because I know how to factor and often move the repetition to tables instead of code (menu systems, field and form defintions, etc.). However, I have worked on a few systems of that size started by less skilled programmers who like linear, repetitious comb-code that inflates the count via set/get-like crap.
Table-ized A.I.
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.
In an ideal world, I agree 100%, but in the real world this doesn't work well. Let me explain why.
Almost 10 years ago I was really into NeXTstep (I still think there were/are many great ideas in that OS and toolset) and I became very enamored of Objective-C++. All of the NeXT development tools were built around Objective-C, which is a very Smalltalkish OO extension to C. But NeXT (or someone) chose to implement Objective-C in GCC, to which others were adding C++ support. At some point someone realized that the syntax extentions of Objective-C and C++ were essentially orthogonal, and that it wasn't too difficult to implement a compiler that allowed programs to mix them freely.
The result was (IMO) beautiful. C++'s strengths are strong typing and the performance advantages of minimizing run-time binding. Objective-C's major strength is the supreme flexibility of completely dynamic binding (as well as simple syntax, but I'm looking at this from the point of view of a developer who understands the languages thoroughly). Objective-C even offers a nice middle ground between strong and weak typing in the form of "Protocols". Finally, since Objective-C++ was built on C, I could always use procedural styles where appropriate (plus, of course, the ultimate escape hatch -- assembler).
With this toolset I always had just the right tool at hand and could for any situation implement the perfect balance of dynamism, reliability and performance. I wrote some really nice code, if I do say so myself :-)
Then, one fine morning, my boss decided that I could use some help and brought in two other programmers to work with me on my project. In general, that was a good thing. The project wasn't in a crisis mode, there was plenty of time to get the other guys up to speed and they were both bright, although still a little green.
Can you imagine what they did when they saw my code? I had spend years cultivating a deep knowledge of each of various styles of programming, both OO and procedural. I had a visceral knowledge of what the compiler would do with any bit of code and how common processors would execute it. I had a complex system of semi-formal rules that I used to decide how to approach a given problem, *and* the understanding to know when the rules didn't apply.
To those two bright greenhorns my code looked like a mess of conflicting styles with no real rhyme or reason to it. They couldn't make minor changes without breaking something and they had no hope of adding major chunks of functionality that would blend nicely with the existing code base.
This is a really extreme example, of course, and I chuckle at my own naivete, foolishness and arrogance when I look back, but I think there's a very valuable lesson to be learned here:
Most software, today at least, is written by relatively inexperienced programmers. These greenhorns won't have the background they need to select the right approach from a wide variety of options. Simple, but adequate, toolsets are the best choice. Slightly more experienced developers (like I was) may have the knowledge required to use diverse and powerful toolsets effectively, but the result will be very difficult for anyone less experienced than the author to maintain. Worse, the result may even be difficult for someone of comparable or greater experience to maintain, because they won't understand the author's style.
Rather than a single powerful toolset, you might suggest a collection of simpler tools, so that the developer must pick one, appropriate, tool for the job at hand. Again, though, this results in an unmanageable profusion of languages and tools. I'm in favor of picking the right tool for the job, but IMO, we're better off with a single simple, easy-to-learn/use general-purpose language and toolset alongside a small number of other tools that are very well tailored to specific applications (and obviously very poor for anything else).
Should that basic tool be OO or procedural? In theory I don't really care (in practice, I'm more comfortable with OO).
My point here, though, is that unless the project is (and will always be) a one-man job, the tool choices need to be constrained in the interest of maintenance.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
You see, people abandoned procedural stuff because without planning it grew messy over time. OO came along and suggested that if you use the 3 buzzwords, then things would almost *automatically* work out.
Guess what. They were wrong. If anything, OO needs *more* babysitting.
I am not saying procedural is (objectively) better. I am only saying that neither is OO. Both deserve tools, research, etc. Procedural is *not* ready for the legacy pile. There is still way too much to be squeazed from it (when joined with RDBMS).
People just keep switching paradigms every 5 or so years in search of the magic bullet that does planning for them. Until Hal9000 works, it is good old fashioned management, oversite, reward systems, and planning that is needed.
Table-ized A.I.
----
o pbad.htm with a clear head.
..dbf files are limited from what I recall). The size of the market segment is irrelevant, what matters is the type of applications you are developing.
Subject: My thoughts on `topmind@technologist.com` AND his site
From: "Peter" <peter@somewhere.net>
Newsgroups: comp.object
[Submitter's Note: Topmind has been baiting people on comp.object for
years. People not familiar with him try to correct his ignorance, but
invariably become frustrated by his refusal (inability?) to learn.
Occasionally flame-gems are produced.]
Please excuse any spelling or grammatical errors (I have just popped an analgesic which is starting to kick it. I hasten to add I reviewed http://www.[deleted].com/SiliconValley/Lab/6888/o
People usually want to know 'where someone is coming from', what therebackground is so I'll pre-empt any questing on the matter. My commercial experience follows
I have programmed in three xBase langauages.
I am an experienced C systems programmer on numerous flavours of Unix and in Win32/NT. (Most of this stuff doesn't even have a user interface).
I have also programmed in VB.
I am well versed in all of the structured methods (analysis, design and programming).
I have RDBMS (Oracle, Sybase) experience.
I currently relearning OO/VC++/MFC.
Thus I am approaching it all with a critical eye.
Now on to the substance of my post.
Firstly the "OOP Myths Debunked" section.
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
Where did these come from ?
Surely these are just "straw men" you are fighting. I mix it with C programmers, C++ programmers, RDBMS programmers, GUI programmers. I have read literally dozens of books on these topics and I read numerous IT journals and periodicals and I have not encountered anyone uttering these alleged myths. Where on earth did they come from ? You are fighting straw men, you have found some fool uttering these remarks and recorded it as 'beliefs held by OO practitioners' for your easy refutation.
I'll comment specifically on the those especially worthy of attention:
"Myth: OOP is a proven general-purpose technique "
Again, this a broad sweeping statement that I have not heard anyone assert. I have read Bjarne Stroustrup argue that C++ is a proven general-pupose language and this is unequivocally true. C++ is used to write literally all kinds of application.
However, the genericity of OO depends on its implementation. This is the same as procedural languages. Not all procedural languages are of general application. So who or what are you arguing against ?
"Myth: OOP models the real world better "
Better than what ? Better than the structured methods ?
Which structured methods ?
"Myth: OOP makes programming more visual "
You are using a misconception that uninformed people have about the relationship about GUI and OO and using this as a criticism of OO ? Lame indeed ?
"Myth: OOP makes programming easier and faster "
Well that depends on which language you are using and whether you are using class libraries, templates and/or frameworks. More straw men.
Myth: OOP eliminates the complexity of "case" or "switch" statements
I think you are referring to the connection between polymorphism and case/switch statements. The idea is not that case/switch statements are complex. The idea is that polymorhism -- implemented correctly -- will eliminate the need for 'mainline' case statements that need to be amended to add new options. This is pretty straightforward.
Myth: Only OOP has automatic garbage collection
I've read heaps of OO material from reputable authors and I have even read a book on AGC algorithms and I have not encountered this assertion. Where did you get it from ? More straw men.
Myth: Only OO databases can store large, multimedia data
Not even OO vendors say such a thing. Another straw man.
Myth: C is the best procedural can get.
Did you make this assertion up ? You can go on comp.lang.c and will not find anyone asserting in an unqualified fashion that C is the best procedural language. For embedded controller programmer it may be the best procedural language owing to its space/time efficiency. I am a C programmer and I know plenty of them and this idea that you post as a myth -- implying that it is a widely held misconception -- is a load of rubbish. "C is the best procedural can get" in certain domains. A higher-level domain specific 4GL will be better at putting together a General-Ledger system.
It seems what you have done is qulified your position
"SCOPE DISCLAIMER: I have been programming small and medium custom business applications for most of my career. Most of my complaints against OO are related to this rather large niche. Perhaps OO is good for other niches..."
But have put a series of unqualified and lame -- deliberately dogmatic sounding -- statements in the mouths of others and proceeded to argue against them.
Your qualification in your "SCOPE DISCLAIMER" limits your domain of discourse to small-meduim databased applications. You say this is a "rather large niche", but that is not what is relevant. The salient facts are the sizes of the applications and their data oriented nature. You are speaking from the bottom end of the market: small, mainly single-user applications, databased, servicing 1-100 (?) users accessing small databases (~1000s records,
On the basis of this narrow and specialised position you are trying to mount a general critique that OO is a load of rubbish.
It would take about 20 pages to dismantle your site -- and it would be like shooting ducks in a barrel -- but I have better things to do. I deliberatley scrolled up and down really fast and stopped randomly. I arrived somewhere in the "Another Fad?" secion. OO has been around since the late '60s (Simula) and C++ (the most popular OO language in industry) is more than 20 years old.
I can print out your site and throw a dart confident it will land on more
idiocy: "The GUI Link".
The consensus of opionion amongst Windows developers in general is that VB is the best tool for creating GUI, many Windows programmers use a mixed-language model: VB for the interface, C++ for the actual application logic. This was the case even before VB4 when some OO support was introduced.
I could go on and on. But I'd be wasting my time. You are plainly an intellectual fraud.
You say,
'Do you think I am full of horse droppings? I have offered a challenge to produce realistic business examples demonstrating OO's alleged superiority. So far a few attempts have failed. I often like to say to brochurish braggers, "put your code where your mouth is." '
But what is the connection between your vague, ill-expressed allegations presented as myths and your challenge ? What can refute a set of vague claims that no one with any standing or credibility states anyway ?
Horse droppings have use and value. Your ideas, thoughts and web page are without any discernable value or merit.
More dross plucked at random:
"In short, business programming does not get the respect that it deserves. Just because it has failed to produce the aura of "rocket science" that other niches have, does not mean that business programmers should have to put up with technologies and paradigms better tuned for other niches."
Which business programmers exactly ? Those that produce small systems (few users, small database) or those that help develop the large databases that hold motor vehicle registration, census data, national flight reservation systems, stock-exchange transactional data etc ? Are you proposing that the NYSE could throw out Oracle db and replace it with one of your cute Clipper applications (LOL) ? Is it all the same to you ?
You seem to live is a very simple universe. Your categories are broad and monlithic (when it suits).
Your web-site is doing a disservice to business programmers (Incidentally I started my career as one) and you definetly do not deserve any respect. I think you need to actually learn about a topic before criticising it. That is a basic requirement.
Have you actually had any experience with a business system that has several hundred "entities" (in the relational modelling sense of the word). I can tell you -- as can many case studies that you obviously don't nother to read -- that OO greatly aids in the management of the complexity that several hundred interrelated entries presents.
You should take your little Clipper compiler and continue writing POS systems, Video rental systems or whatever the heck other cute little systems you write and just do your thing. If you don't like OO don't use it. No law has been passed that requires its use. Your trying to pass yourself off as someone worth listening to but you are like an old whore in a dimly lit room, attractive from a distance but frightening up close. You are a charlatan.
I too could dredge through Usenet looking for idiotic opinions and arrived at a set of `myths` on any topic. But this is the classical informal logical fallacy of the "straw man". If you want to do a serious critique then go for it. What you have on your site is your parochial and selfish concerns about the future of your skillset and some really lame critique of OO.
Whether you like it or not OO is here to stay. C++ is most definitely here for decades to come. Its too early to say for Java. Irresepective of specific languages, OO is most definitely here to stay as per structured methods.
Give us a break with the
"Programming Wisdom Center"
"By the Galileo of Programming (the only dude with enough arrogance and smarts to fix the computer world!) Death to Unproven Fads!"
stuff.
There are websites by those that are literally geniuses that have made substantial contributions to IS and CS that don't self-proclaim their genuine brilliance. Their work speaks for them.
Your website distinguishes you as not only ignorant but meta-ignorant. Your understanding of OO is poor -- this establishes you as ignorant. You are not even cognisant of the things in IT that you know nothing about, hence you meta-ignorance. Ponder this, it is meta-ignorance that is the more dangerous of the two. Ponder.
On the topic of your self-proclaimations: xBase is flat in complexity. It's a crappy procedural 4GL, conceptually simpler than MS-Access. I haven't seen anything on your web-site or posts that indicates anything other than mediocrity and priggishness. Smarts ? Where were they ?
I could be more hostile -- and you would deserve it -- but there is a whole NG full of people like you (that I occassionally follow for the same reasons people watch wildlife documentaries) , see comp.databases.pick. These guys aren't even familiar with structured programming. They are convinced that `Pick` a late 60s vitage DBMS is flawless, was the best, is the best, will remain the best. I know better than to waste my time on people like you. Perhaps you could subscribe to comp.database.pick and try convince them that xBase is the way to go. This would be redolent of the asylum scene in '12 Monkeys'.
--
Moderators accept or reject articles based solely on the criteria posted
in the Frequently Asked Questions. Article content is the responsibility
of the submitter. Submit articles to ahbou-sub@duke.edu. To write to the
moderators, send mail to ahbou-mod@duke.edu.
--<end quote>--
-- we turn sound into light...
>> but I'll tell you that it's certainly more fun to code using some kind of plan/design. <<
OO has NO monopoly on PLANNING!
I discussed some of my procedural modeling techniques under the "Orthogonality Problems" message.
>> In other words, the code was not factored at all <<
Procedural factors JUST AS WELL overall.
>> 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. <<
Try a simpler, more natural paradigm for once instead of one that requires the real world to change only in a hierarchical way in order to work as advertized.
Table-ized A.I.
While exceptions is not really related to OOP, usually non-OOP languages (C,Pascal) do not have exceptions while OOP languages have them.
C++ has exceptions but there are rarely used.
Why am I so fond of exceptions?
Well, they ensure that errors are dectected, so by default you are aware of errors!
Otherwise you must hope that the programmer wasn't lazy or the error won't be noticed, if you're lucky the problem will cause a core dump if you're unlucky the programm will seem to work correctly even if it don't!
The major downside of exceptions is a performance issue, but as long as you use exceptions to send error messages only this is not really a problem..
No, you were trolling.
-=Best Viewed Using [INLINE]=-
>> Really??? I think that generic programming is the missing key to effective code reuse. If I find myself sorting things over and over again, shouldn't I abstract that out into a generic sort algorithm, <<
Sorting is something that has complex algorithms, but a realatively simple interface. Most business "things" require fat, complex interfaces.
There are so many tools out there to sort, that anybody who has to write a sort by hand is either doing something wrong, or using dumb tools/langs.
I have been letting the DB system do any needed sorts 99 percent of the time. The remainder is because some idiot used arrays where a DB table should have been. Arrays suck! They are the GOTO's of containers/collections.
Similar comments apply to collections in general. There should be no reason why an applications developer should have to code standard collection operations by hand these days.
In one aborted OO challenge an OO fan tried to demo how easy it was to build a half-ass DB in Python. I am not impressed by how easy a language allegedly makes writing stuff that is already readily available. Some people get off on the stupidist things.
Table-ized A.I.
>> I would like to hear your response to my refutation of your "Person and Tax" inefficiency problem. I mean, we're talking about a terribly complex problem with several parts to it. Plus, the tax code changes frequently. Having an object to encapsulate the problem allows you to set the necessary parameters, and then just run T.CalcTax(P). That seems much better than your method. <<
:) <<
It is hard to cover a realistic tax example in a few paragraphs. I would be happy to dig into it at ezboard.com (see msg #900) or some other forum system of your choosing. But not on slashdot.
>> Second, using an RDBMS for variable management is probably not such a good idea. Access is ridiculously slow, even for the best of them. <<
My point was that using tables reduces the *need* for lots of variables. It is not really a matter of putting variables into tables. Again, I would have to study specific examples. Sweeping generalizations usually don't cut it.
>> I'm not sure how you don't see that the Object, Attribute, Method framework is logical. It seems so natural to think of a person as a Person() rather than a more haphazard collection of defining variables. <<
It was an example to illustrate a specific point. I have since replaced it with another example because that one seemed to confuse people who did not follow the links.
One nice thing about tables is that it is easy to see and manage the data (state) without the clutter of implementation. I compare this to only seeing the front of the control panel instead of having to wade through the guts of the insides of the box. Some OOP IDE's can do something almost like this, but they emphasize trees, which you already know my opinion on.
>> As for portability, well, Java serialization allows you to pass objects between platforms. <<
How is that better from say EDI, XML, or DDE? Also, only Java can participate without converters, unlike EDI and XML, which is more language agnostic.
>> It just seems like your attempts at abstraction would result in parameter overload: every object would be a list of parameters in your model, and trying to keep track of or pass them around would be sick. <<
Like I said, I use RDBMS for this.
The original example was misleading without following the entire link trail.
>> But hey, write a platform with your model... <<
I don't need a dedicated platform/language for it. (It would simplify many aspects of it if I did though, and I have plenty of suggestions and draft protocols on my website.)
>> In any case, they were trying to piss you off when they modded your comment down. It was a good comeback, for some of it at least, but you just can't convince the Slash crew of what they don't want to hear. You should have seen me try to convince them that copyright wasn't always a bad thing
That is a common complaint of importance ranking: unpopular, but potentially good ideas get slashed (pun). If Einstein had slashdot when he first came out with relativity, he would get a lot of zeros. Most good ideas are not welcomed with open arms when they first surface. That does not imply that my suggestions are on the same level, but new/fresh ideas and junk usually do get the same treatment under voting.
Democracy: where 51 percent *dictate* to the other 49 percent.
Table-ized A.I.
The points next to the missing references are rarely pivotal to my arguments.
Complaining about that is not key.
Table-ized A.I.
"Democracy is two wolves and a sheep voting on what to have for dinner. Liberty is a well-armed sheep protesting the vote."
-Benjamin Franklin
Yet more anecdotes. Why can't anybody give specifics of where OO allegedly helped. Again, the few times that I actually got to see some specifics indicated either personal subjective preferences or bad procedural techniques. At least one little example. Arrrrrg! Frustrating.
Table-ized A.I.
>> And besides, it makes everything considerably more complicated to have lots of multiple inheritance involved. <<
I was not really thinking about multiple
inheritance as the way to get away from
a strict (single) tree.
>> I also have canRead(), canWrite(), and canSeek() members to tell me if these options are available. <<
I notice in my collection protocol analysis that operations like seek() {as in query, not position} are often not-all-or-nothing. If no index/hash is available, then a sequential search is still possible, just more expensive. If there are only 50 items, then rejecting a seek just because an index does not exist may not make sense. Also, many collection engines cannot tell you if a seek expression can use an index or not.
Those are the kinds of sticky details one encounters when trying to make generic anything.
I have some draft examples of generic collection stuff at:
http://www.geocities.com/tablizer/array1.htm
Perhaps we can combine your sockstreams and my collection protocols and make the ultimate generic "multiple thing getter"......just a thot
Table-ized A.I.
>> and has been willfully resistant to all efforts to educate him. <<
As in Soviet style "re-education".
Todd Blanchard and his group are a bunch of egotistical clubby trivia pedantics who could not create external proof if their Linux box depended on it.
They piss on the scientific method and rational, step-wise analysis. Being right or wrong is based on a club vote, and not external, inspectible evidence.
Their brand of Zen Science is similar to what fuels OO hype.
Show me your 3 code examples or shut the h*ll up! I am tired of your authoritarian hot air.
Table-ized A.I.
Since most programmers are mediocre, what if we look at the paradigm from that standpoint instead of under ideal conditions?
I once asked what works better with mediocre or bad programmers, and surprisingly some of the OO fans would rather work with bad procedural code than bad OO code.
Table-ized A.I.
It is true that companies don't want to spend on upgrades, but it just seems that things get toss or replaced anyhow IME.
I have seen a lot of stuff that was tossed because of mergers, new server brands, can't find programmers, manager retirements, purchase a whole new packaged/bundled deal and so old stuff gets tossed if it was good because of one that comes with the bundle, etc.
That is just my observation. I will change the figure to "3-to-5 years" just to be on the safe side. Better?
Table-ized A.I.
I *won* the dollar-sign argument. Malraux agreed it could be done. What are you bragging about? It wasn't even about OO.
Regarding the device driver, I already admitted that OO may be better at device drivers on my anti-OO webpage. (But, in my domain I spend zero time writing device drivers, so it is moot.)
Table-ized A.I.
(* This is not a programer! *)
That is how most "programmers" (or whatever the h*ll you want to call them) do their GUI's.
Perhaps you are going to rattle on about seperating biz rules from display logic, blah blah; but IME it does not work out that clean in the real world, partly because such taxonomy boarders are often fuzzy or artificial (similar to IS-A mentality in general), and partially because it costs a bit more to do it that way in the short-run and thus few companies bother to pay for the time.
Table-ized A.I.
Labview is OO? Isn't that the visual chip-like interface where wires between chip-like blocks are parameters and the chips are the functions?
An interesting concept, but hardly OOP.
Table-ized A.I.
>> But I found them better for storing data long-term than for programming, because the write/delete time is horrendous, especially if you use a good indexing system, which you must to get reasonable read times. <<
I am not sure what you mean. If you mean like as a substitution for arrays, then I agree that some sort of "lite DB" engine/driver would be nice. XBase had such readily avialable. I am not saying that XBase is the ultimate language, but when it comes to temporary array-size structures that may grow to need a spectrum of relational operations, then it was wonderful.
Perhaps if more languages/libs offered a lite-driver that was upwardly compatible with RDBMS calls (and some little syntax adjustments), then it would do that kind of job using less resources. After all, its only a protocol.
As far as indexing, if you need the indexes to begin with, then you are doing something that a simple RAM collection probably cannot handle to begin with. IOW, indexes are optional.
Perhaps you were on an expensive SUN box? It seems Sun shops are relunctant to buy faster servers, and thus worry more about performance. Just a hunch. NT might be crap, but hardware upgrades are relatively cheap. Switch to Linux instead of Sun perhaps.
Table-ized A.I.
Actually, I should compare it to a religion, not politics. It is all based on faith and anecdotes. Nothing external to inspect.
Why is there nothing external to inspect?
BECAUSE OOP IS NOT BETTER!
I have seen decent examples of how OO could help with device drivers, so examples/proof *can* be made for benefits. However, nobody can do the same with biz apps/models.
What else am I to conclude?
(Actually, I might take another stab at those driver examples one of these days. But for now, I will give them a tentative victory.)
Table-ized A.I.
>> I think that this guy's point of view is incorrect though because he has only ever had to be the initial designer of a product and has obviously never had to assume somebody else's code base where he had to figure out what the initial developer's purpose of code was. <<
I never said that was the case. Where did you get this presumption?
>> By the way, there have been new development disciplines to speed up this exact process he is complaining about. http://www.extremeprogramming.org/ <<
Extreme programming is orthogonal to OOP. Frankly, I think XP's effectiveness depends on the group/people involved. It makes some rather shakey assumptions about human interaction behavior that may apply to some, but not all people. Anyhow, another topic.
Table-ized A.I.
>> Myth: OOP models the real world better.
OOP models objects really well <<
Do you mean real world "objects"? If so, Bertrand Meyer disagrees with you. He says that the purpose of OOP is not to model the real world directly.
>> Myth: OOP eliminates the complexity of "case" or "switch" statements.
Yes with a properly designed class hierarchy. <<
Prove it with CODE.
>> Myth: Most things fit nicely into hierarchical taxonomies.
Actually most things can if they can if designed right. <<
Do you mean that if real world things are "designed right"? Are you telling God how to program or Honda how to make cars?
>> Myth: Components can only be built with OOP.
Again not true but it is easier and more natural to develop components in a OO framework. <<
Demo, example, proof?
>> Myth: Only OO databases can store large, multimedia data. Where does he get these? <<
Bertrand Meyer.
Table-ized A.I.
>> If you do not like set/get methods so jsut skip tehm and access teh datafields. <<
Then you have a typical DB access approach that has not changed for ~25 years. JDBC looks an awlful lot like the Fortran DB API's I used to use on a Prime when I first started. (It was even a pre-SQL engine that was not upgraded for about 10 years at the time I came.)
IOW, no advantage over procedural/relational. Wash.
>> all who access direct the field have to be changed if the field is changed) <<
And odd self-stopper of DB's is that once they are populated with data, you don't change existing fields very often because then you lose backward data compatibility. Generally you would just add a new field and slowly phase out (any) old one.
It is just one of the odd self-preventing situational rules of thumb. What is the name of that concept? I can't remember.
Anybody?
Table-ized A.I.
Jim Weirich started cataloging the same Shapes example done in many difference languages, both OO and procedural:
http://w3.one.net/~jweirich/oostuff/
It is sort of a take-off of the 100-bottles-of-beer website, but with shapes instead.
Table-ized A.I.
You might be right. If OO falls out of style, then C++ will live on, but Java will toggle to legacy-status.
Java bet the farm on OO by not catering to procedural very well. (It is doable, but not as easy.)
Table-ized A.I.
>> He's also (ironically) not very well versed in relational techniques, either. If the entire world went back to XBase he'd be in his element. <<
:-) <<
:-) <<
That is a sloppy misrepresentation of my point of view. Jerkass!
You are just sore because you CANNOT make code proof that OO is better.
Flunkie!
>> One time he claimed that cursors in external processes ran more slowly than stored procedures in the server for political reasons.
Ignoring the set-optimization issue, I still say this is true and you have not proved me wrong.
>> He likes to compare it to pure OO, as if OO programming can't use relational paradigms as well.
I allowed you to combine OO with whatever you wanted. You are lying (or bad Reagonitous on your part).
OO and RDBMS are hardly a clean fit anyhow. Look at all the expensive tools to simply translate from one paradigm to the other. What a waste.
However, that is what you often have to do because OODBMS are flops.
Table-ized A.I.
I think he meant "many blocks" or "more syntax".
Classes not meant to be instantiated are often bulkier syntactically than procedural in many languages.
Would you rather type/read:
print("foo")
print(x)
or
system.print("foo")
system.print(x)
all over the place?
global methods would be nice in certain cases.
Table-ized A.I.
>> This is amazingly powerful. You can adapt existing classes to multiple purposes, mix in new behaviour, or swap out an old class for a better designed one. <<
I perfectly understand these swappability and override-differences concepts, and talk about them extensively on my website.
However, I have been *unable* to apply it to *real* stuff in my domain. It is woooonderful on paper, but.....
Like already discussed around here, new things often/usually require major *interface* overhauls. The idea that the interface is stable and all the dynamicism is only/mostly *underneath* the interface just does not apply to the real world, at least as I see it.
Perhaps for device driver domains it might be great, but I can't find much use for it in custom biz software.
The client is only going to pay for *one* implimentation per interface, and exceptions/variations don't fit cleanly into inheritance trees.
If you can show me a good biz example, that would be great.
Been waitin' for 3 years.
Table-ized A.I.
Examples? links?
Table-ized A.I.
This message almost sounds like it was copied verbatim from the "why you should use OO" chapter of a Java or C++ book. I agree that the concepts sound wonderful on paper, but they rub against a reality that does not plug into these concept cleanly.
The message has things like:
>> This is quite powerful; with a single line of code specifying what to inherit from, your object gains a whole lot of new functionality "for free". <<
But then tempers it with:
>> Once again though, there is very little special here, it can all still be done with imperative languages. OO languages just, once again, make this concept more a part of the syntax and constructs of the language. <<
Which does not mean much if the pure version is too idealistic to work in the first place.
>> Inheritance also allows you to override methods, so if the object you inherit from has a function, you can redefine that function to behave differently. <<
If you solve the "method boundary not matching the difference boundary" issue, then this might just fly. (For example, only 1/3 of a given method may need to be different than the parent.)
You also have the "fragile-parent" problem to deal with.
Tackle the hard issues rather than keep repeating the doctrine over and over. That is what is really needed.
Table-ized A.I.
[quote]
Just compare getting the address of the client's parent with:
theclient.parent.address
vs doing the same thing with:
select address from people p
inner join people p2
on p2.idparent=p.id
and p2.id=theclient
[end quote]
If that was a common need, then write a function to do it. (Personally, I don't encounter a need for such very often, but specific apps might be able to make need of such a fucntion.)
[quote]
In the end, no-one needs to prove anything about any language, db type or method of working since everyone will just go ahead and use what works best for them.
[end quote]
But like I aready said, the over-emphasis on OO is harming tools/training/research in the alternatives.
No programmer is an island.
BTW, thanks for the example. They are rare around here.
Table-ized A.I.
>> 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 <<
Note that you can plan for good structure and future change handling in procedural/relational code also.
However, you seem to be implying that OOP *forces* you to plan, and therefore it is good.
This is hard for me to swallow. Somebody who wants to hack out OOP code can do the same by following the standard simplistic/formulaic-OO rules: One class per major noun, and subtyping for any variations on these nouns.
That *will* get you "instant OO". Now, wether it will look so good 2 years down the road is another matter.
Table-ized A.I.
>> If you break OOP down into it's basic parts, there are some good and useful ideas there. OOP as a religion sucks. <<
Sometimes looking at things in an OO way can indeed stimulate some thinking. However, I rarely conclude that the OO way would have been the best path (unless, sometimes the specific p/r language I am using does not have a certain p/r feature, and OO is the next best alternative.)
Table-ized A.I.
>> 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. <<
So if somebody wants to resurrect
respect for procedural/relational programming,
then what they need to do is codify the good practices?
I guess I am the one who is going to have to do
that. (Fortunately, I have already started).
Table-ized A.I.
>> 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. <<
I picked that title mostly because it rhymed. I am NOT against abstraction, just OO's brand of it.
The bottom line is that there is still no proof that OO is better, REGARDLESS
Table-ized A.I.
>> I've written server scripts with raw SQL statements, and trust me, this is much easier. <<
You may want to look at:
http://www.geocities.com/tablizer/chal01.htm
Bottom line: you can have a procedural/relational framework tha hides most SQL also.
The good thing about SQL is that you can paste it directly into an SQL browser and play with it to test or debug or experiment with it and then put it back in when you have what you need. A framework may make this harder to do.
There is indeed alot of duplication in SQL that can be factored out, but when access gets tricky or complicated, the framework will not work. For example, I have not seen how they deal with left outer joins as an option. Can anybody fill me in on this?
Table-ized A.I.
>> Because languages like Java and C++ let me bring home the bacon! Thank You, OOP! ...
Let's face it, all programming languages and paradigms mostly suck. I gave up on searching for truth and beauty (at least with programming) years ago <<
I wish I could learn to go with the flow.......of money.
Hmmmmm. Maybe I can be the next Bertrand Meyer of Table Oriented Programming and also sell $75.00 books.
My website might have bad references and apostrophes, but at least I did not charge you 75.
Table-ized A.I.
>> Object orientation makes it easier to manage changing interfaces. <<
How? That is a rather new claim.
Table-ized A.I.
>> Being a programmer, I can say first hand the OO is easier to learn at an intuitive level. <<
Intuitiveness is highly person-dependent.
>> FYI I coded a chat server in C, and it took me about 1/2 the time to do it in Java. <<
I am not surprised. C sucks as far as human productivity is concerned.
Table-ized A.I.
That is actually what OO was originally invented to do. It started in Simula-67, which was a modeling and simulation language. Thus, your experience there is not surprising.
Note that "multiple instances" (state) usually go into tables in my domain. Easier to view, manage, report on, and monitor the "state" there also IMO. However, relational/indexed tables may not be suitable for some engineering apps due to timing or hardware constraints.
Table-ized A.I.
(* Someone care to explain to me why one might see this as good thing? I tend to use these a bit *)
Background info:
http://www.geocities.com/
tablizer/meyer1.htm#singlechoice
(you will have to concatenate these URL sections, because the browser cannot handle long things--either can my wife, he he.)
and
http://www.geocities.com/tablizer/shapes.htm
BTW, my page stated "eliminating the *complexity* of case/switch statements". It makes a difference when you get into the nitty-gritty of the debate.
Table-ized A.I.
>> OOP gave us just right level of hierarchical abstraction to make platform-specific issues irrelevant to higher layers; <<
...
But how did this system get around the "method boundary" issue?
>> 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. <<
XML? Yikes!
XML is:
1. Not Relational
2. Not Easy to browse by itself if lots of cols.
3. A storage/xfer format only
The format that the data is stored/transported in is a table/DB implementation detail, not an end-all-be-all.
But, if that is the best way to sell T.O.P. to the world, then I will pretend that I like it.
Table-ized A.I.
I don't dispute that OO worked well for you, but what exactly are you comparing it to?
Procedural shops can also acheive high amounts of re-use if they try and given planning time by the powers that be.
It might also be that OO fits the way your particular team thinks.
Not everything is abstractable/in a hiearchy, true but I find in most of the work I do, it is.
Which line of work is that? I think that may be the key. If the domain is tree-able, then OO may indeed shine. But, when where how and why this occures is not well studied. I was just chatting with a radar installation software guy, and he said that his interfaces tend to be very stable and thus they can use the OO Driver Pattern or something similar. But, I rarely see (write) this kind pattern in my domain.
Table-ized A.I.
>> 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. <<
Bad code can be written in *any* paradigm.
Often there is no incentive or training to improve procedural talents. It is as if software engineering training has been *written off* for procedural works because OO is supposed to take that mantel.
The self-fulfilling-prophecy-ghost is back
I can see plenty plenty plenty of places that procedural code can often be fixed up when I encounter slop like you talked about.
Almost 80 percent of p/r code *I* see is *highly* in need of tender-loving-care.
It is amazing how something simple can be fubared in the hands of ignorant/stupid programmers. Oh the crap that I have seen. But ALLLLLLL fixable.
Table-ized A.I.
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.
While I am glad you tend to agree, the size thing seems to be the opposite of what many OO fans are saying: that is "OO tends to shine more as the project gets larger".
About half of OO proponents seem to say that improvements scale with size, while the other half says that OO helps all project sizes (except for one-off scripts).
But the suggestion that it mostly shines (or can shine) for smaller projects but not larger ones is kind of unique.
Just something to ponder.
Table-ized A.I.
I am all for a consistent collection protocol. Whether the back-end engine is Oracle, a flat-file driver, or arrays, it should not matter. Look at ODBC. You can make an ODBC driver for a hair-dryer if you want. (There *are* ODBC drivers for flat files, spreadsheets, Word documents, etc.)
You don't need OOP to do that.
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.
Why? SQL is easier. If your query links 4 classes, then you have to subclass 4 times. Besides, where do those links come from? And, all that code left around if you forget to delete it.
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.
I am not sure what you mean.
Table-ized A.I.
by "two dimentional" i mean logical. With an rdbms you can't make an intellegent nested structure without a myriad of joins and lookups. Flattening a tree into X tables (or a single self referencing table) drives me batty.
The native format issue is mostly an elegance issue. Good engineering makes complex structures easy to deal with. So a well engineered view centric data orgainzation system should make dealing with data as either a tree, or a table equally elegant. So where do you start...
-T
Old truckers never die, they just get a new peterbilt
>> However, unlike many people who criticize OOP, I don't believe that "C is all you need" <<
As an OOP hater, even I would rather use Smalltalk than C for most projects.
However, if sombody's mind works well with C and they can prove it with productive and flexible code, then nobody should complain. The things that throw me in C might not throw them (and other C fans).
>> 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. <<
Agreed to some extent, but people then stop looking for procedural/relational gimmicks to improve focus on software maintenance because all the attention goes to OO. IOW, the self-fulfilling-prophecy again.
>> 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. <<
I don't know. Often you get pack-rat languages with more toys for bored programmers to make messes with. Minds wonder. Spend complexity wisely.
Besides, there are some sticky tradeoffs in that list, but I will leave them to Smalltalk versus Eiffel battlers, etc.
Table-ized A.I.
I would have to look at a specific, real example. Tables overall have more dispatching power than classes.
Besides, "nested structures" are of limited use IMO in biz applications and the "nestedness" is a *particular* view for a particular need. Tables allow multiple views of things better than any other collection handling structure. Perhaps they are not optimized for each and every specific "kind", but they the most morphic and most practical.
Table-ized A.I.
Using Microsoft Word as an example of the benefits of OOP flies like a lead balloon around here.
But, to continue beating a dead horse: MS Word is buggy and has a crappy interface IMO. I think MS inherited the bugs by encapsulating stolen polymorphic designs.
Table-ized A.I.
>> However, here's a quick example where OO excels. I was in the game industry for many years. <<
Note that most of my criticms target biz apps and not games. I don't know enough about games to be any authority on them.
>> 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. <<
It almost sounds like a good use of tables, if it was perhaps not for speed considerations (i never tried it). Giant switch/case statements in biz apps are almost always a sign that you need a table, especially if the list repeats.
I love tables. They compact information so tight and concise and understandable. Classes and hierarchical browsers can't compete, at least not in my mind.
Table-ized A.I.
RE:
"Took a shower this morning, looked on the bottle and it said:
0. Hair takes water
1. Hand takes the shampoo
2. Hair takes the shampoo
3. Hand works shampoo into lather
4. Hair takes water which removes instance of lather
5. this->repeat()
A lot of OOP programming I see is like procedural except the first parameter is the object. Like foo(bar,crud) becomes bar.foo(crud)"
Table-ized A.I.
>> It appears the mob has spoken, Troll Boy. <<
But my counterpoints *were* valid, were they not?
I don't get it. (Neither the ranking nor OO.)
I squashed a fooooouuuuuuurrr fair and sqare.
Is a "mob" the opposite of a "troll"?
Table-ized A.I.
But there is no clear, standard reference. For example, "encapsulation" contains some aspects of security, and some of positional locality (next to each other).
These are sometimes orthogonal. I think they should be divided in sticky discussions.
I would more likely blame lack of coherent design.
Often there is more than one candidate for grouping something by. If you group it by aspect B, then you risk A-related problems. If you group it by aspect A, then you risk B-related problems. I find these kinds of tradeoffs common in arguments over how and where to group things. Code is generally one-dimensional, but life is multi-dimensional. Thus, a forced tradeoff.
Table-ized A.I.
A gross, biased over-simplification. My summary: they said they made compilers faster and more predictable. I simply weighted the tradeoffs and concluded that errors caused by human semicolon typos were a bigger cost than rare re-structuring of code that the compiler may trip on.
Prove him wrong, pin him in a corner, and its a technicallity/silly/not important. More often, he'll just ignore them,
Bull! Name your best 2 points that I ignored? Name them or shut-up! Most often your best victories are imaginary.
Regarding the Capers Jones LOC study, I discuss it on my "goals" webpage.
Table-ized A.I.
I could lose a thousand references, and you would STILL have to inspectable proof that OO is better.
A personal, pedantic, red herring attack. Typical of you guys.
Table-ized A.I.
not related to the article per se, but i do like your sig quote ;)
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.
Well, I'm in that category. I came first to Perl 5 (having used Perl 2..4) then tried to make sense of C++. Not pretty.
Larry's done a remarkably good job of adding OO semantics to Perl. And has had one hell of a good idea: splitting bless from creation of the object. I put this on a par with Unix's split of fork and exec, which allows flexibility unknown to other OSes.
I have used Perl a lot; and of my programs about 10% have used the OO semantics. They are handy, but not worldbeaters. There is a problem set that can use OO, but it's not everything by any stretch. If there really is a set of "objects", maybe. Otherwise not.
Just my £0.02 (worth a bit more than $0.02).
This "article" is biased from the getgo, and I smell a familiar stench of elitism. This "Real programmers don't use " is getting tired. The author does allow that he is not informed on enterprise level needs/development, but from my sandbox, OOD is the best thing since slice(bread). When coding for a paycheck, freeflow art usually doesn't last/can't be maintained/extended/scaled. OOD provides a great framework if you think OOP constantly.
No, I think I'll just tell you that people who click on little boxes all day are program users not makers. Yes, this does lead to spagetti code with fuzzy borders that's imposible to maintain, but that kind of con job is another story. The man's a troll, Tablizer, he knows better than what he writes and seeks ignorant responses such as yours.
Friends don't help friends install M$ junk.
I usually do a compromise, something like
this:
...
acell("name", t.name, "")
acell("rank", t.rank, "")
acell("cost", t.cost, "$")
...
sub acell(title, data, options)
formatStuff()
display(title, stuff)
display(data, stuff)
more_formatstuff()
end sub
This way the formatting stuff is near-by
but not repeated over and over for
every fricken column and cell, like
amatures do.
Table-ized A.I.
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.
An OO fan could argue that you need hammer.slam(nails) instead of nails.slamBy(hammer), or the like.
I notice that in most sentances there is only one primary verb, but often two primary nouns (subject and object). Thus, it appears that the verb is a more central and consistent a concept to model around. I find that in (decent) "procedural programming" the grouping will be more consistent. The module grouping is almost always around a central verb or activity. With OO you cannot predict which noun that the behavior was stuck into. Thus you go into somebody else's OOP program not knowing whether the nails will be doing the action/asking or the hammer.
That bothers me about OOP. I never came to grips with that.
Table-ized A.I.
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.
I agree that this is very commonly said by OO enthusiasts, but since most people don't believe this, I don't think it qualifies as a myth.
In my experience, writing up a quick program is much more easily done in straight C, and faster too. Most people realize this.
IMHO, the strengths of OO programming only arise when you are writing a code base for *other* people to use, simply because it encapsulates everything and provides an abstracted interface. For instance, when you go to design a GUI, it's much nicer to create a button instance and pass that to a form, than to call a function that puts a button on the screen, and continually have to keep track of all the details.
I think that OOP is actually *harder* because if you do it correctly, you have to think about how others see your interface. This is something that should be done even if you are writing code procedurally, but OOP forces you to do this.
I agree though, that there are other paradigms that are just as good. Anything that promotes modularity and generalization is good. OO is one way of doing this, but normal modular programming habits, peer review, and even structuring your app as separate processes or threads will also help to achieve the same results.
"I have never let my schooling interfere with my education." - Mark Twain
Lisp has had object-oriented facilities for at least as long as C++ has existed (e.g., Flavors). Common Lisp is an object-oriented programming language with several unique properties. As I understand it, Common Lisp was technically the first object-oriented language that fully passed ANSI standardization. Lispers think of their language as multi-paradigm (functional, procedural, object-oritented).
in university at the moment, we're taught a lot about oo programming and design. in fact - this subject come's up more than any other.
it's becoming a trend, to not only to develop your programms using oo design - but more and more new languages claim to use it too.
in my opinion, the benefits of using (code reuse, easy maintenance) it will eventually make it the standard design of all programming languages in the coming years.
i wish i was but oh well
The problem is that most people dont get far past that point. The hardest part of using an object oriented programming technique is deciding how to structure your class heirarchy. Even for a trivial program, deciding how to throw up an elegant, scalable, and expandable set of classes to implement it can be a non-trivial problem.
There are countless bad coders who dont concern themselves with that aspect of the problem, and go around creating mob's of classes that work, but are not ideal for the problem domain. Pretty soon their code degrades into spaghetti worse than procedural coding styles. Also, they tend to use the good interfaces available to them in horrible ineffecient ways (doing alot more work than needed to solve the problem).
They give the whole technique a bad name, and I think wrongly so. It is possible to gain advantage from OO code, and to minimize the drawbacks, but its alot harder than some think. Many programmers fail to make the jump from procedural style to OO style without realizing it.
The fundamental problem with non-functional programming is something called side-effects. C code is rife with side effects stemming from global data, static function variables, assignment, the environment etc. Object Oriented programming is a technique for minimizing side effects, and confining them to small manageable sections of code. This is known as "encapsulation".
When used properly, changing how one part of the program works will only break things in a small part of the program (one source file usually). This can be a tremendous benefit.
OO programming techniques, combined with C or C++, give you the best combination of application efficiency, portability, and development expediancy avaiable today.
What it wont do is turn bad coders into good ones. Actually quite the opposite: it tends to turn bad coders into horrible ones.
Every useful programming project I've ever completed was done in C or TCL/TK. I've even paused to wonder how much easier or understandable my code would have been if it was C++, and I have to say honestly that it would NOT have been. If anything, it throws in too much jargon and demarcation. I'm sure Java is an improvement in OOP, but I don't use it, so I can't comment on it. The only useful application of C++ that I'm familiar with is MFC. M$ COM model is vague and ties the developer to too much proprietary M$ crap. It is too bad TCL/TK never caught on in the scripting world. It is much easier to read than Perl, has an excellent GUI toolkit, and is easily interfaced through C constructs.
When I drive to work I generally go one route. However, there are days when I realize that because of traffic, weather, or just for the sake of doing something different, I go a different route.
When I write code, I tend to go with OOP. I find it's easier to explain to co-workers and easier for me to visualize restructuring whole sections of code. Then there are the days that the I don't. For whatever reason, I throw OOP out the window for that particular project. For me, the methodology is defined by the project.
I look at an argument bashing one or the other and shake my head. I don't have time to fiercely defend or attack either one... I have code to write.
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
There is a lot of sucky OOP support out there. IDL is really bad. R on the other hand, has some very simple OOP support, but it is certainly very nice, and makes the job done very nicely. I haven't really gotten the hang of the Perl OOP stuff, but then, my Perl stuff isn't really sophiscated.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
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.
That's what I'm doing in my Electronic Design class in college. I'll be using HPVEE to have hardware controllers do stuff. Then, I'll use it for my final project to show off a piece of equipment that fulfills a set of objectives. I'm already light-years ahead of what the big hardware design corporations are doing. Take Intel, for instance. They haven't been able to release a reliable chipset for two years!
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
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)
And now the price question: will it become pregnant?
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).
Actually you need to check your grammar. An apostrophe is commonly used to denote plural for acronyms and such, hence it is perfectly correct to write "GUI's" to mean the plural of GUI. I think you need to slap yourself in the face.
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.
After that, I started learning more about OOP and OOD. What I found out is that done right, OOP can be written just as fast as procedural. Sometimes faster. Once you get into the habit of doing things a certain way and thinking a certain way, it becomes second nature.
OOP is not just for GUIs. In fact, if done right, your should have a GUI object that talks to a Business Object which talks to a Database Object. You should be able to change out any combination of the three and not notice any change (in a perfect world ).
Obviously you can do this in a procedural fashion, but OOP lends itself more to this (i.e. makes it easier on the programmer).
People complain about the speed of C++ and OOP in general. Speed is not a major problem with todays computers when it comes to business applications. What is more important is the ability to have stable software that you can change easily and quickly. When speed is important, there are always ways to optimize.
See, I can ramble on just like the author....
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
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.
--
Took a shower this morning, looked on the bottle and it said:
0. Hair takes water
1. Hand takes the shampoo
2. Hair takes the shampoo
3. Hand works shampoo into lather
4. Hair takes water which removes instance of lather
5. this->repeat()
A lot of OOP programming I see is like procedural except the first parameter is the object. Like foo(bar,crud) becomes bar.foo(crud)
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
How can you refer to something that's been going on for what, at least 10 or 12 years that I know of, as "Hype"? Britney Spears, there's hype for you. But OO? You'd consider the Web established, wouldn't you? Well OO is certainly older than the Web!
1) When it works, it works really well
2) When it doesn't work, nobody can understand what it is anymore.
-----
The global economy is a great thing until you feel it locally.
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...
And the one code example about persons and taxes was so contrived and bogus. OO doesn't say you have to do it this way. A good programmer evaluates the situation and does things appropriately.
What, the Apple suing Freetype article not too long ago wasn't enough of a troll for you?
--
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
"Code reuse" is easy to sell to managers and the advantages seem obvious to anyone. There is a serious lack of studies proving that extra work done to facilitate code reuse ends up paying itself back on average.
Using object oriented design to structure programs can be a great help. Design is a very personal topic and no set design system can fit everyone. I have seen people who would design things using a functional model, essentially using a scientific method to solve problems. Others, perhaps the author of the article, think primarily in terms of the work that the program needs to do, and are productive that way. Still others are most productive when they design things as collections of objects that interact.
A given programming language tends to fit a specific design paradigm best, but there is nothing stopping you from designing using one paradigm and using a programming language intended for a different one. It is just a matter of knowing what you are doing. The author uses relational database tools as an example. Yes, it sucks to use a relational database if you design object oriented, but since other people already developed the methods needed, it is a SMOP.
Finally! A year of moderation! Ready for 2019?
In practice, free software has solved the "software recycling problem" in a way that object oriented programming proponents promised and generally failed to do, because it is much easier to reuse free software in ways that were not originally anticipated, and it is economically unoptimal and often impossible to anticipate all of those ways.
For example, people adapt hardware drivers (kernel, X windows, etc.) to new hardware and there are frequently features that require internal changes that could not have been easily anticipated in the original programming interface.
This is one reason why mutually compatible copying conditions are so important to free software.
I also think that embarrassment over this why one well known OO proponent denounced free software.
This is not to say that inheritance, data abstraction, and calls of the form object->function(object,...) are useless. They are useful at times, and sometimes even in the peculiar combination called "object oriented programming", but their benefits have been oversold and the demand for free software is a testament to the fact that OO failed to remove most of the barriers to reuse that make the proprietary model so much less efficient.
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
its called red-baiting, and its often used "this thing is like communism, and we all know how evil communism is" (or fascism, or whatever)
its dumb folks, the dumbest sort of strawman arguement in existence, and because its such a rotten example of a strawman, i think we should rename it the communism logical fallacy (or maybe just the name-calling logical fallacy)
either way, this guy is crackpot, is arguement are poor, stacked, rambling and often incoherent, and falsely didactic.
i can't begin to imagine how such a poorly written article made it to the front page of slashdot. honestly, no idea. none. really.
kellan
Please remember that nothing in this world is a panacea, there are trade-offs in every decision one makes. The same counts for OO... it's no magic solution to problems the industry faces, but it is IMHO a step in the right direction.
Either one factors to the same thing. A single entry point into the program. Java does the object thing by default because there is no idea of a "global" function. But it is still just a "main" function in a class that starts the thing. I find this feature of the language VERY useful because I can put a main function in a class I am testing and run it independant of the system I am creating. Without having to make a dummy executable file to do the same thing. So basically you have to bootstrap the program somehow (into a function). Its all the same.
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.
Most of the points made in the article are very close to the truth in the general medium and large business world. I worked on a OO project (we did use OO design methodology) at a large corporation in the early to mid 90's, and it mostly played out exactly as the article describes.
However, in the course of my participation in that project, I saw some absolutely amazing things done, both by our staff of programmers and by the outside consultants (several sets of them) who came in to mentor and tutor us.
I personally believe that OOP can be extremely powerful and productive for an individual developer or for a very small team of like-minded, cooperative developers. There ARE some strong benefits to be had from OOP/OOD but, just as the article says, you have to apply the paradigm consistently in order to reap them.
I still enjoy using Smalltalk (Squeak) at home, but I never get the chance to use it professionally, anymore. I wish I did.
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
On the other hand a compiler could spend time optimizing this stuff more (maybe more inlining of those tiny calls at least).
Or in other words, it's a compiler issue. Which is pretty much exactly what he said in the first place.
... 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.
but can you link to some of your own code (perl, preferably) to give an idea of what you consider acceptable? Otherwise, you're just blowing some rather pungent hot air.
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.
The point of all this, is that there is a different method for programming but that still evolves (like adding to your cooking equipment, etc) over time faster than the older one, at least IMHO. Now, I like both. I like to use different styles and tools for different tasks. But I find it both disturbing and strangely amusing that there is such a large contingent of snooty, self promoted elitists out there who think that by snubbing the newer method they are afforded some extra degree of credibility and recognition than they would gather from good work and assistance to others. Perhaps I just see them as the snobs that fall all over themselves trying to prove that they have been doing what you do, longer, more, or their father/mother did it, making them l33t.
As for OOP vs. Procedural and all... ahh, what are ya gonna do? I have heard a lot of the talk about OOP being bad because it has more overhead (compiler or pilot error?), larger file size (see above), and the ol familiar, how can you reuse code when the method to reuse keeps changing? (well, that sounds like the upgrade argument, its gonna happen for awhile, so get used to it!). If you don't like it, or are stuck in the Procedural world, fine. I am sure you can do the very same thing (or very close at the very least) as an OOP program. But if you take someone with 20 years procedural experience and habit who then writes an OOP, then bitches about it and the results... well I'll let you finish this. cheers
I seek not only to follow in the footsteps of the men of old, I seek the things they sought.
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
Someone care to explain to me why one might see this as good thing? I tend to use these a bit
"We are not saying the OOP is bad, per se;" Hmm...interesting URL you chose then...
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.
I got through the first few paragraphs before I stopped reading. You don't get far in this article before you start seeing stuff that doesn't look right. He says, "Myth: OOP is a proven general-purpose technique " I HAVE seen OOP proven on several projects.
Later, he writes "Fact: OO fans have repeatedly failed to demonstrate OO superiority. They can talk up a good storm, but cannot walk their talk. " OK, name one software programming technique that HAS demonstrated it's superiority. Have any? If so, let me know so I can start using it. Superiority FOR WHAT? Every application has different requirements. It like saying "truck owners have failed prove that trucks are superior."
Those 2 gems are before the article even starts.
Don't waste your time..
"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety"-B.Franklin
Stop your whining... I forgot to check the box that removes the +1 posting bonus. If it is too high, it'll get modded down as over-rated, or something.
--
www.scorbett.ca
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 ...
OK, i'm just a comp sci student not smacked by the real world yet. I've been (mostly) taught C, C++, Java, Perl...etc. Most guys (in the real world) tell me that they love Java...why? Not because it's an OO language...because deployment is quick and "multi-platform" (more or less). I think this guy has spent too much time on a non-issue. -ted
But how does one do interface reuse in C ? Perhaps you should study OO more carefully ( in particular, polymorphism )
Engineering simulations involving structures (think animation). Objects work great here, b/c every object can have it's own state assigned to it, and then it's just a matter of doing an object->move, object->rotate, etc. OOP is the better way to go here.
I guess this applies anywhere you have several 'things' all doing something different at the same time. OOP makes sense for that. But if you are working with only one 'thing', why would you need an object to describe it? You could simply use normal subroutine calls instead. OOP masks that complexity for multiple instances of a 'thing'
Of course there are many other examples, but this one was the most obvious to me. That said, most the stuff I do is procedural unless objects make it easier in the long run (rare).
I think people forget that the whole point of OOP is to make modular routines that *MASK* the complexity of the function. You simply do object->foo, without worrying about the internals.
If you aren't masking the complexity of the action with an object, you shouldn't be using it in the first place.
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.)
... or just somebody pretending?
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
Furthermore, that people may perceive OOP to only happen in C++ and Java does mean that it cannot happen in Pascal or C. This is the same for structured programming in Pascal instead of Basic. It is harder to do structured programming in Basic, but not impossible. If we are going to talk about OOP, lets talk about facts, not perceptions.
It is also true that OOP can take more time. On the other hand, the same can be said for any project in which reuse and modularity is an issue. I believe time can be saved with OOP because the mechanism for reuse is part of the language. I completely agree that if reuse of code is not an issue, then OOP may not be your best choice. Likewise with objects, interfaces, etc.
When I read an article like this I wonder if the author has ever written anything over 3000 lines, or worked with a team greater than 2. The article may be useful to someone who has never coded more than 'Hello World', but no one else.
First, I'm inclined to agree with the article. There are many cases of OOP that is seriously overdone. I'll use COM as an example. What was MS thinking when they made DirectX a COM object? It would be faster and easier if it was a normal API! But there are many good uses for the COM abstraction. It allows implementation reuse and dynamic binding to objects. Yes, this could also be done without COM or OOP, but it makes it more straightforward. Many of my programs use OOP for some parts and straight procedural code for other parts. Sometimes I use OOP-like structures in my program but without classes. It depends on the project.
What I don't like is the way the article is written. It lists things that it debunks, but then makes vague claims as to why they are bad. It even compares OOP to communism (!). If the article gave real-world examples, I would like it. But it simply criticizes blind faith in OOP while requiring blind faith in the article. This is not a good way to make an argument.
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.
To be quite honest (and it pains me greatly to say this being a C++ programmer) try Java. I've heard many people mess about with C++ and say they just didn't "get it". Then Java came along, and more than a few of those same people suddenly "got it". Having not used Java very much I can't say I know why, but I've seen it happen... let's see... I can remember 3 separate occasions.
I wasn't that impressed with the article at all. I've worked with OO systems in big business and as a Tools Developer. The company I work for is a recognized leader WRT OO.
In my opinion there are three main aspects of OO:
1. Polymorphism
2. Encapsulation
3. Code-reuse
These are the pillers of OO. It is no secret that each of these can be accomplished in any computer language. It just won't be as easy or as natural as in a modern OO language. In my experience, I have found that if your OO code isn't small and easy to understand the design was wrong. A properly designed OO program feels right. Incrememtatl changes tend to fit right in and is more solid. I can't imagine developing any of our products in a procedural language. Ugggh!
--
BorlandInsider
Kylix - Just too damn cool!
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.
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?
You make some good points.
However, (there is always an however) you seem to imply that abstraction and good interface design is the dominion of OOP only.
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
While this kid makes some valid points, the one "point" that kept annoying me through the whole thing is that an object is limited when it needs to interact with something it wasn't supposed to. The example he gives is a victim not having a victim.mug() method, so a mugger can't rob him: well, isn't that a good thing? If I design an object for a specific purpose, there's no way I can see into the future and see all the different uses my object may be used for. An object is not carved in stone: if your new app needs a method not provided by my object, then you add that method, and keep the rest. There's no law that says that you can't modify the object. The other example is that in the real world objects interact with unexpected things like trees and earthquakes. True... but this isn't the real world. This is a system where the programmer defines the scope - any external object that wants to interact with my object has to be explicitly added to my object somehow. I don't see how procedural programming, or any other programming paradigm, can see into the future and know everything it has to interact with. I apologize for this probably making no sense.
He didn't mention maintainability much in his rant. Perhaps because it would be a major counter point to his assertion. The only place where I can remember it even being mentioned was in an idiotic metaphor with automobile mechanics.
-- Jane you ignorant slut --
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?
This one does that and lots of other stuff. It generates some great code.
--
Patrick Doyle
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
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 author didn't seem to want a real comparison, but to trash OOP. Each have their stengths and their weaknesses. If you use OOP when it would be better to use structural, it will lead to bad code and vice-a-versa. It is more important that a project is well organised then the style that is going to be used.
I recently read the "conversation" between Linus Torvalds and Andy Tenanbaum about Micro Kernel Vs. Macro Kernel. After reading both it and Linus' essay in Open Sources i figured that it was the organization of the project that was more important then the paradigm used. There's no need for a flame war over this, it's just not nessasary.
"So you call this your free contry, tell me why it costs so much to live?" - Three Doors Down
The efficiency argument against OOP is quickly wearing thin given moderm processors. Realistically, function calls are NOT killing your performance; poorly written code and hitting the disk/swap file too much is going to slow you down more than anything else. The main thing people *should* gain from OOP is safety. In the book "Writing Solid Code" (no ISDN/author, look it up yourself) the author points out (from the perspective of a procedural coder using C) that the most important thing about software is removing bugs, which, if done properly, is easier and more reliable under OOP. Despite all the cycles you may save without OOP, every single performance gain you made will be lost in just one crash; speaking in terms of how well the software works for the user. I think any of us could stand waiting for our *nix/*BSD/Win* box for an extra 30 seconds or even 5 minutes on boot if we knew that it wouldn't crash once it was loaded, the same going for any other program used for creating content or doing something useful. The point here is that OOP's main point beyond data structuring is safety, which can be far more easily obtained if done properly.
Disclaimer: Badly done OOP projects are doomed to fail miserably, far worse than their procedural equivilents. TANSTAFL.
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 is the worst possible way to write code.
Except for all the other ways.
668: Neighbour of the Beast
Why do i like OOP?
Because languages like Java and C++ let me bring home the bacon! Thank You, OOP!
Let's face it, all programming languages and paradigms mostly suck. I gave up on searching for truth and beauty (at least with programming) years ago. I'm sick of companies that want their projects implemented in Java/ASP/JSP/C++/COM/VB/Oracle/SQL Server/etc. without really knowing why they want it done that way, other than having been impressed with a sales rep.
But... Programming for 60K+/yr will always be better than having a real job, especially one that involves manual labor.
The only thing that we learn from history is that nobody learns anything from history.
and in the mean time, lets have the compilers just create the code in the first place, yes?
I mean, I don't mean to sound like a dick, but you're blaming your slow inefficient code on a tool instead of on your code. If you can write something in a different order and have it be faster, that's YOUR issue, NOT the compilers. Yes, optimizing compilers are nice and all, but you can't expect them to do everything for you.
Face it, function calls take time, OOP produces a lot of function calls (you said it yourself), so there you have it.
OOP does produce a BUNCH of little subroutines. Thats how OOP usually works best (abstraction, encapsulation, etc.).
But in this day -n- age compilers should be able to work around that. Compilers should do more than literally translate code into assembly, they should be able to optimze, inline, and re-arrange code for speed. If I tell you to do A,B, C you can figure out that its faster to do A, C, then B, and to start the stuff for B when you do A so it'll be ready in time. A good compiler should do that too.
FunOne
FunOne
Sure. But those little subroutines tend to be inlined alot more often as they are part of the namespace and are usually jumped to with the proper jsr/ret combinations. What i'm curious about is the performance of a lot of the applications that we wrote under contract in c. They sorta faked oop with structures holding function pointers used as components. This gave us much better modelling of dynamic objects because their behaviors could be changed at run time.
Old truckers never die, they just get a new peterbilt
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..
Maybe he just thinks differently, but honestly I don't see where he can say 'I dont accept anecdotes as evidence' when his whole damn argument is based on nothing but.
It also seems to me like he really just doesn't understand it well enough to properly criticize it. OOP isn't a magic bullet, and it wont solve all problems, true - but then again, no-one was claiming that either. But it is powerful, and in most cases it is more powerful and more maintainable than procedural programming. And in large projects, it is damn near invaluable, due to the tight constraints that can be forced on the usage of objects and data.
And why the hell should it matter what the average lifetime of a project is? What if your project just happens to be one of those that lasts for 30 years? If good, maintainable designs were done in the first place, 3 years would most likely be unrealistically short. I personally think most projects are tossed because they too quickly become unmaintainable due to poor design, regardless of language.
And as for it taking many years to reap the benefits of OOP on a particular project, I certainly beg to differ. The rewards seem to come to me much quicker, on the order of months for breakeven - because the little utility classes and even large structures become like a library, a library of well tested code that does exactly what I want, and that I am very familiar with.
I remember thinking the same as this guy several years ago, when I knew C++ but didn't truly understand it. I have since learned the strengths and weaknesses of OOP, and changed my mind.
Anyway, I think I'm done with my rant...
-dentin
Alter Aeon Multiclass MUD - http://www.alteraeon.com
Most of the assumptions he disproves are ones that are not even valid. For example on one specifically, any programmer worth his salt knows that garbage collection is fairly language independant. It works better with some language syntax than others but it can be put into any language if you want to write the code to do it.
I'd be willing to guess that this guy along with a number of others hate OOP because of the large number of beginner C++ people that think they must use every feature of OOP in every program they write.
It all boils down to this, OOP is another tool in the tool box. You wouldn't use a hammer to tighten a screw, but it certainly does put nails through wood very well.
This article is a troll, right?
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.
Hey, thanks, good eye.
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.
Hmmmmm. That's really deep...
----Quid
----Quid
Less talk, more caffeine
I would have thought that factories and prototypes meant that one could instantiate objects "with regard to context".
I've done quite a bit of C++ programing and never once in my life have I reused code through inheritance
Then you weren't doing object-oriented programming. I don't care what language you used, that's a central part of OO. You can write in C without using do/while/for/switch as well, it just won't be good C.
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.
YES!!!
As a working programmer, I can appreciate this debunking tremendously.
I have worker mostly on both large, windows GUI applications as well as large, server side GUI applications. Having worked with more complex applications than the author, I would say that he actually gives OO too much credit. It is even worse than he thinks.
Certainly, SOME factors of OO are extremely useful for large programming projects. But the "theory" and the hype of OO both produce more harm than good.
OO produces more "tight coupling" of code on more levels than procedural programming.
-- One example is that a large function can be broken into smaller functions and each function moved another file. Once you have a large C++ class, you're basically caught by it. You can't break it easily into anything. ==> And this is only one of several ways that OO essentially screws you.
The thing is that OO "theory" is hype. Unlike, say, relational database theory which rest on both mathematical logic and rigorous ideas of data usage, there are no rigorous concepts behind OO "theory." The basic "ideas" of inheritance, polymorphism or encapsulation are simply intuitive, adhoc systems to make things easier.
They draw anologies between many common features of data structures.
The problem is that they force these anologies rather than calling on programmers to be extremely carefull in determining whether these analogies actually work. Sure, if an anology between an OO class and what we intuitively take as an object, "real worl" or not, then OO is useful. But for other objects, like GUI windows, lexical elements of a computer language or rows of database, the analogy is forced and counter-productive.
Oddly enough, despite being designed with an "intuitive base" of object, OO often becomes a matter of myth in practice. Rules like "no downcasting" are applied without an eye to actually reduce the complexity or increase the robustness of the resulting code.
Also, a lot of the arguments for OO, begin something like "If the definition is tight and the operations are well defined, then you have acheived OO'ness." This implies clear thinking and exact design, something seperate from OO.
So basically, it's like saying "with OO and a dollar, you can get a cup of coffee."
Best wishes.
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
Seems to be Tablizer
I should have proofed it better ...
;-)
OO stands apart from GUI. OO is useful for implementing GUI systems, but OO is useful for lots of other things too. The athor implies that without the need for better GUI implementation techniques that OO wouldn't be so popular today. I disagree with that - GUIs or not, OO is still popular.
A lot of people confuse these concepts:
- object oriented
- encapsulation
- code reuse
- inheritance/polymorphism
I'm not about to sit down and write a crisp definition - that's for the textbooks. Apparently the author hasn't read any recently.
C++ sucks. C++ sucks. C++ sucks. Bleat as necessary.
'nuff said?
OOP is not a panacea, but as far as rapid
development (especially for a *group* of people)
and maintainability as well as novel and
innovative programmatic structures it is far
superior to procedural programming for most
tasks. (I said most tasks... some tasks are
better done from a procedural standpoint...
choose the right tool for the job..)
In general I would say that OOP is 21st century
programming.
I didn't like OOP either.. until I got it. After
I got it, I loved it.
Java is by far my favorite OOP language by the
way. C++ is a little kludgy but probably a
close 2nd.
My statement about properly implemented OO gives you code reuse can be applied to paradigms other than OO, but I haven't done it will.
About half of the good OO code I have written in my life has been done in C. That does not include polymorphism or any other pure OO construct, however the design of the components themselves are modeled as objects.
A better word to explain my vision of OO is component based design.
--
Mike Mangino
Sr. Software Engineer, SubmitOrder.com
Mike Mangino
mmangino@acm.org
Quotes:
"Sorry, we accidentally lost the references."
"Although no references will be given here, this figure is fairly widely accepted in the industry."
I mean, come on here. Those two sentences ruin the credibility of the entire article. An assertion that is backed up by nothing is worse than useless.
The whole article suffers from a preaching-to-the-choir attitude and the only folks likely to agree with it are those that agree already. So what was the point of writing it then?
Monkeytreats
-BxT
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
One reason people "get" OO after working with Java is that its standard class libraries were designed with polymorphism in mind. For example, many methods depend on an InputStream object as a parameter. But, since InputStream is abstract, you have to pass in a subclass. Where can you get an InputStream? Well, you can create a FileInputStream, call the openStream on a URL object, create a StringBufferInputStream from a String, get one from a Socket, etc. It's also much easier to create your own InputStream type than it is in C++, IMHO...
If i remember my first-year CS classes, calling lots of little subroutines is encouraged by structured programming as well -- "always break up a function that's more than 10 lines long" or stuff along those lines...
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
"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.)
Unless you're designing a system with pretty extreme realtime constraints *everywhere*, odds are that less than 10% will impact real performance. That's where you re-code in C or assembly or whatever works. And the remaining 90% involves control structures and network and database calls. Who cares -- speeding this up will have minimal impact on system performance, you'll just call NOP more often.
Data point: I worked a few years ago on a fairly large exotic finance application. In Smalltalk. There was a competing system which had been written in C++ (also object-oriented, but especially at the time wasn't used very well). Smalltalk runs between 2 and 10 times slower than C++, especially for floating point performance (because they're portable across architectures). And when you're pricing derivatives, you do a lot of floating point.
End result? Not only was out system written substantially quicker -- which is the norm for experienced smalltalkers, but it was **faster**. Because we had a more understandable system, we had better tools to identify the 10% which was slowing things down, and we were able to make it work smarter.
Did you think about a stack-based cache?
I'm sure if you designed cars, they'd get great gas mileage... unless you drove them at speeds between 20 and 70 MpH, right?
here, you can only start something; there is no stopping.
What the fuck is this guy smoking? Why is slashdot linking to some idiot's ranting on a geocities page?
I am currently working on an artificial life program using Opengl in Python. I actually started out in C. However the program became too complex; too many switch and case routines etc... Beyond all that (And I know how to do this in C with good use of structs) the nice thing in OOP is the fact that you can easily scope your variables. Having worked inteams of programmers this is a godsend. Another issue is the use of good case tools. Like the gentleman who wrote the original article said: he basically knows small to medium sized business programs. I come from a background of fairly complex systems. The use of case based tools if only for documentation is invaluable in those cases. I do agree that C++ is an ugly language. I recommend that the author looks at OO Pascal (Delphi, FPK) or if he needs to be more platform independent Python or Ruby. Those last two languages are extremely popular with their users for good reason. One more issue; I am not sure after reading the article if the author understands OOP in the sense that he understands the philosophy behind it. Bruce Eckel's books do a very good job at going into that aspect of OOP. Also OOP predates GUI's big time. They have nothing to do with each other besides the fact that developing a GUI using OOP is a lot easier than in straight C. (Trust me; I've spend a long time developing GUIs out of staright C and using classes is just a lot easier. The problem with OOP is one of bloat. However unless you do embedded systems that same bloat is very much offset by modern machines. Frankly it is a lot cheaper to buy a new server than to have a bunch of programmers tweak code.
Hajo Monogamy: Belief so strong that millions of people end perfectly good relationships in order to start a new one.
Both communism and OOP rely on the concept of classes for the fundamental flavor.
Orbacus is faster than Orbix, adheres more closely to the CORBA spec, comes with source code, has better customer support, supports more platforms, has no run-time licensing fees, and is available for free for non-commercial use. There are probably some more advantages, but I don't remember them off the top of my head.
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
Check it out! OOP=Communism!!!
I'm sorry, but you lose a little credibility when you start comparing something to communism or fascism. Yes, there may be problems with an OOP approach to everything, but such comparisons only draw away from your criticism.
Even so, I'm still reading the article, even down to the little soviet flag at the bottom.
Why is this a /. headline story? A few pages of html with no research done by a "business application" (sounds like a VB fan) programmer who obviously himself does not even understand OOP.
No one ever claimed OOP was the cure to all programming, but this article does not even attempt to tackle the underlyning issues, it is just a rant by someone with little to no comprehension of OOP or design patterns.
Atticles with this low level of journalism that don't bring any constructive coversation should not be posted, what is /. thinking?
Please don't treat women^W^W^W^W^Wcode as objects. Please regard them as individuals, as worthy of your respect as any of Gods other creations.
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Or in other words, it's a compiler issue. Which is pretty much exactly what he said in the first place
Umm - that's what 'on the other hand' means - I'm trying to argue both sides of the issue in order to be fair - it's one of those things one does to try and keep oneself intellectually honest - no issue (esp. not computer architecture!) is completely one sided you have to argue all sides to try and find a good place to stand - a really good architect has a gestalt of all the issues and some good idea of the 'sweet spot' he/she is trying to address - it's never easy :-).
My point was that there ARE some compiler related issues - BUT lots that are more language/methodology related
Man, don't get me started. The artical makes some good points but what it comes down to is choosing the right tool for the right job. As a programmer, I have to make a zillion choices about how to implement the next great idea my boss has. To OOP or not to OOP ... that's about the last thing i think about. If you break OOP down into it's basic parts, there are some good and useful ideas there. OOP as a religion sucks.
The points he lists are all technically correct, but this is hardly new. These debates have been raging for decades now.
See that "Preview" button?
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.
Reusability is a croak. People were talking about reusability in the days of Pascal, but yet I never see anybody scrambling to re-use all that old Pascal code.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
He compares OOP to Communism for Christs-Sake!
The guy just doesn't seem to grok OOP in any meaningful way, and seems to have some serious issues with software development practices overall.
Maybe the guy used to date a Software Manager who liked OOP?
Syllable : It's an Operating System
OO is about defining data and operations on that data. If the definition is tight and the operations are well defined, then you have acheived OO'ness. Thus, you can do object oriented programming in BASIC, COBOL, C++, C, Java, etc.
If the guy wants to trash specific OO methodologies, then fine. However, generalizations such as linking GUI to the rise of OO program are hilarious.
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:
Actually, the NT kernel is written in C and assembly language.
I guess you won't be using those anytime soon ?
Who cares if 90% of your C++ program is horribly inefficient ? I only care about the 10% that represents a performance bottleneck, and by the time I'm done optimising it, that part of the code will be as fast as C. Sure, features like virtual methods etc come at a cost, but that's hardly a problem if you have 1 virtual method call to a thousand add or mult instructions.
best review of this "article" to date
I'll try to make a long story short:
My first computer was a Commodore 64. I wrote programs in BASIC. The programs started getting bigger. Harder to manage everything in my head (remember lines like GOSUB 3510?)
So I went to "SuperTurtle BASIC" (From an old Compute! magazine) which gave symbolic jump labels (GOSUB CalcPercent) and some nice graphics commands. But the programs got bigger, harder to manage.
Then I got a PC, and learned C. Now I had functions, scope, types, pointers... These were things that I knew I needed, before I even knew that a language existed that supported them. I'd been approximating them with my previous languages, just to keep myself organized. But then my programs got bigger, and eventually got hard to manage.
And then I learned Java and C++ (yes, just about simultaneously... I'm not sure which was first). OO was something I knew I needed... Again, I'd been approximating OO techniques with C, just to stay organized.
So OO isn't some magic bullet, of course... It helps those that already think in OO write those thoughts down in an efficient manner. Those people already try to write code in a maintainable manner. They already try to document code for themselves and others.
So OO doesn't do anything unless it's in the right hands. And with so many programmers now entering the field with an OO language as their FIRST language, I think there might be a problem... If you've never seen the hell of tracing GOTO statements all over the place on a C64, what makes you think differently? What makes you want to name your variables so you can tell its function and type by its name, if you've never had to find a bug with adding a STRING "0" to an INTEGER 0?
These aren't OO problems, but they're a way of thinking that OO kiddies never had to tackle, and I think it may be the reason OO has gotten this bad rep lately... I've met an awful lot of programmers that can't think OO, even though their only language is Java, for example.
So my suggestion is that with the economy slowing down, go out and pick up a C64 or Apple IIe and start from the beginning... Then when the wireless boom hits, you'll actually understand the technology from a more fundamental level... Plus you'll get to play a lot of Dig Dug in the process!
-Jason
A good module API is far simpler to design than a good object model (although neither is easy) and provides more potential for code re-use since it can be in a more portable programming language. Given the lack of good programmers with real-world experience, it's foolish to use OOP techniques unless there's a very strong need for the paradigm. The article is a bit weak, although the list of myths at the start is good. I also liked the observation that grouping procedures with data in OOPS tables is a bad idea. Seems a lot like grouping web page logic and source in the same file -- something experienced web designers know is almost always a bad idea.
On many of our projects, project managers and solution leads have touted the benefits of OOA&D, but then push for a rigid time schedule and do not maintain a disciplined OO approach. This frustrates me and many of the other developers.
However, there are a few projects which have started from the beginning using a rigid methodology. With good architects, I have seen some projects move inception to delivery very quick and smooth... touting all the benefits of OO. I see this as a good thing, and here is why: Many of our clients come hire us to give them additional functionality in their existing application, most of the time this additional functionality is simply expanding their business onto the web. Many of these clients have poor or no frameworks in place, giving way to much redesign and much recoding. These projects that I referenced above that used a rigid methodology have very good frameworks in place will enable our clients to put in place additional functionality in the future with minimal rework.
Right now, I am working on a reusable asset library. These are most written in Java and are (at the risk of using a buzzword) OO. These assets have already been deployed on multiple projects, already realizing a quicker time-to-market.
With all that said, I do not believe that an OO approach is always the best. I do believe that it has its place and I have seen its benefits; however, there have been tasks that I have been assigned that I did not believe OOP was best, so I wrote my stuff in a more procedural manner.
MB
I work for a large engineering company and I recently had to learn LabVIEW which is OOP. At first I thought it was going to be extreamly easy, but there is more to it than people think.
I find it very useful when doing multi-layers and sub routines because if you save things right you can re-use. I'm a big fan of the lib. system. I think if it catches on enough it will make programming easier in the long run.
I work for a large engineering company and I recently had to learn LabVIEW which is OOP. At first I thought it was going to be extreamly easy, but there is more to it than people think. I find it very useful when doing multi-layers and sub routines because if you save things right you can re-use. I'm a big fan of the lib. system. I think if it catches on enough it will make programming easier in the long run.
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
That's kind of ridiculous. By using overloaded constructors, the whole headache of initializing each individual member could be avoided. For instance:
Person P = new Person( "Fred", foo, bar, blah() );
I'm seeing lots of flaws in most of these arguments...I agree that OOP isn't the best solution for everything, but it certainly is more useful than this article claims it to be. I also think it's funny that he makes a comment that explains what a comment is in C++...what's the point? You can do C-style comments in C++; it's just another example of how he berates the language for spite.
Did he have an object bite him as a child?
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
The author of the article seems to enjoy passing lots and lots of attributes around instead of just passing an object. Stick to that, and i bet your interfaces are going to change veeery quickly...
-----
free the mallocs!
Chip designers have indeed done a piss-poor job of branch prediction in the presence of procedure calls. This hurts any code that isn't written using gigantic procedures. Yes, compilers respond with heavy inlining---but that's what leads to the ever higher icache miss rates.
.so and .dll shared libraries---break prediction completely for subsequent code.
...] code is lousy when our processors can't even make relocatable code work in a reasonable way.
It's time computer architects admitted that branching to an unknown offset is important. It's important because it's part of every procedure return, every shared library call, every piece of relocatable code, and every dynamic method dispatch that is ever done. There are limited solutions---the Intel architecture tracks CALL instructions and tries to map the to the corresponding RET. However, these solutions are so limited that common idioms---like the PC fetch required for relocatable code in
When this prediction works reasonably well, everybody will benefit. Even better, the need for inlining will be much less and we can hope for improved icache hit rates and smaller binaries. There is promise; the Pentium IV's trace cache uses a technique for eliminating dynamic branching that's proven itself when done dynamically in software (a la the HP Dynamo project). Too bad they made the ICache far too small to be useful. The Itanium provides special registers for branch destinations; these can be loaded well in advance, giving some hope that the processor can keep up.
For now, we're stuck. It galls me no end to hear claims that our [Procedural, OO, Functional,
I asked for 3 biz examples that demoed how
OO was better, and you only made excuses
and gave me Software Engineering Vocabulary
tests.
Typical style of the defeated who are only
good at trivia. God, that group was so
obsessed with trivia SE vocab. sick.
Table-ized A.I.
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
Of cource, lookin at slashcode will tell you that Taco doesn't belive in structured programming either.
--
M-x all-hail-emacs RET
He's also been spanked at:
here
here
here and here .
http://www.angelfire.com/ca3/marlowe Better a smartass than a dumbass.
If he's set out to prove that OOP is the enemy of folks who want to rush code out the door and be the first to market, well then fine... he's done so. Nobody is going to argue that to do things properly takes time, regardless of the methodology you use. Which do you admire more, first to market, or clean, elegant code?
Is it our fault his tax class depends on another class!!???
OOP, code indenting, editors, etc. - all personal choices that influence your productivity. I don't complain when I see someone drinking pepsi (ugh!) instead of Coke.
--
"The truth is messier, and OO is no better optimized to deal with dynamic feature relationships than competitor paradigms". --------- This was an astute observation. The author also observes that many OOP newbies and zealots alike have a tendency to attempt to jam their class definitions into a forced hierarchy. He's right. Note, of course, that this doesn't at all invalidate OO languages. The author also doesn't address newer OO patterns which are coming into popularity, such as attributes, dynamic relationships, and so on. He seems to not understand that experienced OO programmers like myself already know what he's saying and we've begun moving on to different patterns of design using our OO languages. C//
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?
I found the article a little repetitive, but he had good ideas. The point is, do we want a better program or a better programmer? Right now, the programmer costs more than the program, so it would be in the best interest of the company to take shortcuts. If using an object oriented language makes the development process shorter, at the expense of clock cycles, then management will certainly go with oop. They lose money when the programmer takes time, but not when the program does at home. Besides, you've got the cycles to spare. However, what do you use to develop the language? obviously you can't use that language. For example, the java platform can't be written in java. (I'm not sure, but I think it's written in C). The point is, OOP is great for getting a product out fast, but it's a little dirty and doesn't do the job as thoroughly as a higher level language. Either you pay the programmer extra so they can make a more efficient program, or you pay the programmer to produce. In terms of management, which makes more sense?
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.
Which one? The point that OOP==Communism? Taco smokes crack.
Then there's the constant assumption that the only thing you would ever want to do with a program is access a relational database. The lack of citations, understanding of how OOP actually works, any semblance of actual logic? And don't get me started on the stupid comparison with Communism. Slashdot, YHBT. HAND.
-- Arm yourself when the Frog God smiles.
I've also done OOP stuff, databases, etc... it's all just the right tools for the job. Sometimes it's nice to have GWBASIC handy, etc. If you take the time to learn the big picture as you go, the old tools still can be used to great effect, even today with OOP, and other constructs.
--Mike--
The author of that page is a well known troll who wouldn't know a class from his posterior and has been willfully resistant to all efforts to educate him. He has rendered more than a couple of programming message boards all but unusable with his prodigious trolling and oo bashing. Best bet is to ignore him.
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
Haha. Those graphs made me laugh very hard. I think they were lifted out of time magazine. Well, at least Time's studies involve at least 50 people... Better learn Object COBOL.
The problem is that out-of-the-box OOP is not the same as well-crafted OOP. An example might be SQLWindows/Centura. Great concept - drill down to the API. Lousy method - so hard to do real, effective OOP that it just gets in the way.
Look, we always have tradeoffs. Full #DEFINE statements for reused constants versus readability of code. Use of statics over globals. Full polymorphism over time to code.
The trick is to use those OOP features that give you the most bang for the buck. Yes, most OOP is vastly overhyped, but that's because PHBs read trade mags which do feature checklist comparisons. That's why MSFT sells so much dreck, and why things like Word have way to much code in a release.
But, that does not mean that OOP is useless. Where you do have many programmers reusing many objects, where those objects are well-crafted and not overly static but flexible, then it can really help you get robust code out the door, code that can adapt to the changes that always occur.
But where you use a non-OOP-optimized method of programming, you're wasting your time.
--- Will in Seattle - What are you doing to fight the War?
He's done very little OO programming, and prefers to set up straw-men (the shape example, the taxonomy example) rather than actually learn how to program with OO techniques.
:-)
t .html)
Object Oriented Programming ezBoard. A good deal of Bryce's material comes from there.
:-)
:-)
:-)
He's also (ironically) not very well versed in relational techniques, either. If the entire world went back to XBase he'd be in his element.
One time he claimed that cursors in external processes ran more slowly than stored procedures in the server for political reasons.
You can read more of his ranting on the ( bloody hell... damned link won't post correctly. Tried 3 times with an a href... oh well. http://pub1.ezboard.com/bobjectorienteddevelopmen
He doesn't seem to understand that OO is a tool. It's not a tool that can be used exclusively. It happens to be a very effective tool used in the right hands. But just because Bryce doesn't possess a set of the right hands, he thinks OO should be completely discarded so he doesn't have to think about it.
Another favorite Bryceword: P/R programming (procedural/relational). He likes to compare it to pure OO, as if OO programming can't use relational paradigms as well.
Ah, well. I could go on for a while. If you're truly interested in more Bryce, use the link above.
Regards,
-scott
Regards,
-scott
Ages ago in college, I simply thought object = data structure + functions. It is a way of packaging code. Later in the military, I went through some OO courses (using Ada, which ironically was not object oriented). When I started to learn C++, I thought "this is just C with objects; I understand this."
It wasn't until after about 2 years of C++ programming, when our group started to get heavily into interfaces that the light bulb went off, and suddenly I "got it".
For me, interfaces are the key (in C++ lingo, abstract classes). You can take a class, implement an interface, then plug it into another class that was coded to work with that interface. This is amazingly powerful. You can adapt existing classes to multiple purposes, mix in new behaviour, or swap out an old class for a better designed one.
Check out the introductory chapters to Design Patterns. I missed it the first time I flipped through the book, but it is all in there... One of the problems with books on C++ and/or object oriented programming is that they focus on simple self contained classes such as Stack, List, etc. Interfaces are key when dealing with complex systems of interrelated objects.
The structuring it imposes is one of the most important benefits. Reuse is mostly applicabel to standard libaries(for instance the API of Java). Only the best of programmers can make universally useful libraries.
In specific cases reuse can make a lot of money for companies. But the major advantage is in well-structured, maintainable code. Most bussiness-software is used for many years and expanded or partially rewritten many times. Well structured code pays off in each and every debugging cycle during the life of the software.
Now if only I could learn to structure my code properly, it would end these horrifying debugging nightmares ;)
The Drowned and the Saved - Primo Levi
1: "Biz things are too dymanic to be modeled via tree taxonomies"
As you have been told time and time again, there is much more to OO techniques than simple implementation inheritance modelling.
2: "You have to suffer thru a lot of junk to do procedural Java"
But then again, Java is not the sum of the OO world. Of course, you can't be bothered to learn things like Smalltalk or Python (or even Java, for that matter: "why can't I reference my static method from within a non-static method?" Remember that one? Or perhaps the two image translation programs I wrote for you because you couldn't be bothered to read the documentation thoroughly?).
BTW, 1/3 of the code is for large projects? What definition would that be? Can you link to it? Can you show your math...?
Regards,
-scott
Regards,
-scott
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?
--Mike--
I have the same ambivalence towards Perl that I do towards OOP, but one thing that rocks about Perl is that it reveals these magical objects to be the frauds that they are: aggregate structures with type information that connects them with a series of functions, and some syntactic sugar in the language to make this structure appear opaque.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
I am a java programmer, so obviously I'm a bit biased towards OO techniques; even so, I do recognize that OOD does have its failings and agree with several of the author's points. My major gripe with his article is that it seems to be one big rant against OO with very little in the way of decent alternatives. He lists all of these problems with OO, but never really says how similar tasks would be accomplished in a non-OO language except for some very trivial cases. Even when he talks about C, he is critical; so my question is, what techniques/languages does he suggest we use? VB? Pascal?
Unless he can answer that question, I don't think he has made a decent point for abandoning OOD.
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
This guy complains about purported lack of evidence of the benefits of OOP. Then he comes up with statements like these (emphasis mine).
"There are also a few studies that show that even non-OOP COBOL projects can achieve the same famous "code reuse" and flexibility" goals that OOP lays claim to if managed properly. (Sorry, we accidentally lost the references.)"
"The problem is that building generic abstract modules (intended for reuse in later projects) requires roughly three times the effort as a project-dedicated (regular) module. Although no references will be given here, this figure is fairly widely accepted in the industry."
What a hoot this guy is.
>K
It's a geocities site. They can handle boatloads of traffic.
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
Re: What's wrong with GOTO?
The software industry is as fad obsessed
as ANY other industry. XML is not even
Turing Complete, and look at all the
hype it is getting.
Table-ized A.I.
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.
Typically, Bryce tends to devolve in this fashion quite early in the discussions, hence earning himself the nickname, "Toddler".
Interested readers are invited to form their own opinions at the OO ezBoard.
Regards,
-scott
Regards,
-scott
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
Not a programming language.
It doesn't need to be Turing complete.
Regards,
-scott
Regards,
-scott
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.
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.
I'm all for biting the hand that feeds us, but is this just one man's opinion? He may even be trolling for karma, since attacks against the creators tend to raise eyebrows and earn karma.
I don't have time to look over the slashcode, and I don't know what it used to look like. I do know that often, in production scenarios, you have to run with your prototype and what you are familiar with, OOP and style be damned.
Anyway, I'm wondering if someone who knows more than myself wants to defend slashcode, or give some examples of what Shoeboy is talking about.
I just had to look at the name of the article html file to know that this guy is just ranting. It's called "oopbad.html"
Myth: OOP is a proven general-purpose technique
No actually OOP is a proved specific-purpose technique.
Myth: OOP models the real world better
OOP models objects really well
Myth: OOP makes programming more visual
Actually RAD tools make programming more visual. OOP is perfect for modeling component hierarchies.
Myth: OOP makes programming easier and faster
Not the first time. But it does make it easier to reuse code the second time.
Myth: OOP eliminates the complexity of "case" or "switch" statements
Yes with a properly designed class hierarchy.
Myth: Inheritance increases reuse
It can but so does aggregation. Actually aggregation or has-a relationships are easier to reuse. Unfortunately, Is-A relationships are easier to visualize but actually require more thought to implemement properly.
Myth: Most things fit nicely into hierarchical taxonomies
Actually most things can if they can if designed right.
Myth: Only OOP has automatic garbage collection
Not true.
Myth: Components can only be built with OOP
Again not true but it is easier and more natural to develop components in a OO framework.
Myth: Only OO databases can store large, multimedia data
Where does he get these?
Myth: OODBMS are overall faster than RDBMS
RDBMS have had longer to develop. And talk about improper models. Not all data should be modeled as relational.
Myth: C is the best procedural can get
Does he make these up?
Myth: Implementation changes significantly more often than interfaces
This is a design issue. If interfaces are imporperly designed then, yes of course, they'll change.
Myth: Procedural/Relational ties field types and sizes to the code more
I don't think so. OO or not if you don't properly encapsulate your variables you'll have trouble. It is just more natural to do this with OO.
Myth: Procedural/Relational programs cannot "factor" as well
This statement has nothing to do with OO. You can factor in p/r languages. You can always factor too little or too much.
OO is no silver bullet but it does a damn fine job until something better comes along.
--
BorlandInsider
Kylix - Delphi is just too cool to keep behind windows.
object oriented programming is gay!
ObjectOriented programming.
:)
e nt languagewars
Hey, should have seen those pages *before* the IW and comp.object crowd pointed out the BIGGEST piles of BS there.
http://pub1.ezboard.com/fobjectorienteddevelopm
*sigh* Bryce made the front page of slashdot. Maybe slashdot finally HAS hit rock-bottom.
Addison
tee hee hee
It is true that I focus mostly on the biz domain.
However, personally I think directory services should be based on RDBMS, not on trees. Trees are only one of many possible views of files. Most companies have very messy file directory trees. Part of the blame is lack of planning, but I also think that part of the blame is trees. Sure, weening people off of pure dir trees would not be easy, but worth it IMO.
The anti-tree guy.
(I am preparing a write-up on this.)
Table-ized A.I.
All the past arguments don't matter.
You guys simply FAILED to come up with
3 biz examples that proved that OO
was better. (They did not even come up
with one).
Stop launching red herrings. You flunked,
failed, flopped, and dropped.
Admit failure like a man instead of playing
sissy games. (Gee, I sound like such an
inflamed troll when I say that. Oh well.)
Table-ized A.I.
And therefore it isn't a "business app". By definition.
I'd post that definition, but I seem to have lost the reference. Accidentally...
Regards,
-scott
Regards,
-scott
this past year i was in charge of a rather large software project at an internet startup (may it rest in peace). i and our other programmer followed very strict oo analysis and design principles (don't think they're very different from most other analysis and design principles), and the author is somewhat correct that the initial design and start of implementation was relatively slow.
however, being in an internet startup, with all the attendant chaos and rapidly changing plans, we very quickly realized the payback on the abstraction investment. as our managers thrashed about trying to please all the various investors / business partners (sometimes changing the whole focus of large portions of the application) we found it relatively straightforward and quick to morph the app in the way we were being led, all without hopelessly breaking our original codebase. i have been on more procedural or data-centric projects where the type of changes we had to do here would simply not have been possible without enormous rewrites. (i have actually been through some of those rewrites and they are very painful.)
yes, cracks were beginning to appear here and there in our model because of all the change, but the entire structure was sensible, and major changes could be effected by modifying implementations in the superclass or overriding methods, etc. in short, rather than waiting three years for the payback (lots of time saved) we enjoyed the payback in under three months.
an added benefit was that our code was so well organized that when i went to technical meetings i could very quickly describe the structure of our app in great detail in a way that even business people could begin to understand, because it was all based upon entities in the domain that they could relate to.
i agree oo can be overhyped, and it is certainly not the silver bullet for all problems, but it isn't difficult and it provides very simple benefits without all that much investment of time and effort.
blurpy
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 thought it was a very poorly written article. There are a lot of problems with OO that need exposing, but this article didn't do it.
///////////
// assign attributes to our person
// display tax amount
// construct from person key
For example, he gave two code examples, showing how one might calculate a tax using OO and procedural programming:
// BAD, COMPLICATED OO APPROACH
Person P = new Person("Fred")
Tax T = new Tax()
P.x = foo
P.y = bar
P.z = blah()
output T.calcTax(P)
// SIMPLE, ELEGENT PROCEDURAL APPROACH
output CalcTax("Fred", foo, bar)
He complains that the OO approach requires you to understand the Person class, and is more verbose. Regarding the latter, the OO code could look like this, using the Person constructor:
Person p("Fred", foo, bar);
Tax t;
output t.calcTax(p);
Or even:
output Tax(Person("Fred", foo, bar)).calcTax().
So, the OO approach needn't be that much more wordy that the procedural approach. In many cases, it's more concise.
Now on to the more substantial criticism, that the OO approach requires you to understand the Person class to calculate the tax. Well, the procedural approach requires you to understand the parameters to the calcTax() function, and to remember the proper order for the parameters. And, the parameters you pass to the calcTax() function are in essence the attributes of a person necessary to calculate the tax -- so conceptually, you have to know just as much about people and taxes in either approach. The OO approach just seperates the concept of Person from the concept of Tax more explicitly. If you change the way that you identify a person (perhaps by SSN or employee id instead by name), you change the person class, but neither the interface nor the implementation of the Tax class needs to change. For example:
Person p(1234);
Tax t(p);
t.calcTaxes();
In the procedural approach, the calcTaxes function would have to change.
There are many limitations of OO. The book "Generic Programming" discussed many of them, and demonstrates how generic programming tools (templates, code generators, etc.) can help alleviate them. Functional programming languages like ML take a different approach, which could be better than OO. But this guy seems to be advocating a return to traditional procedural (not functional) programming, which be a big step backwards.
Also, there are many know limitations of naive or traditional OO. For example, inheritence is overused by many programmers new to OO. Java's combination of strong typing and lack of generic programming facilities (no templates) forces programmers into creating overly complicated interface (pure abstract inheritence) hierarchies, since you can't easily create generic methods. So, Java encourages complicated interface hierarchies. But, the guy should read "Design Patterns" regarding why aggregation is often a better tool than inheritence. Saying the OO people think that the whole world can be represented in an inheritence hierarchy is attacking a straw man. Contemporary OO gurus don't think that way. Oh, and inheritence is not primarily a code reuse mechanism -- it's a typing mechanism.
Stephen Molitor steve_molitor@yahoo.com
Ims in 3rd year of Computer Science at a university in Spain, and i really got annoyed when new students told that they were not teaching the procedural approach anymore. They have moved form Pascal to Object Pascal in first year, and second year you only see C++ and more Object Pascal. Do they really think that you need a hello object to write the hello world program?
Procedural is great because its what I know now, why would I bother learning something new where people will know more than me.
Its not immediatley better than procedural so just give up.(Lets see what 30 years of compiler tweaking can do.)
Spending 4 times as long to make it reusable later to save time is stupid, who know how long im gonna be around on this planet anyways
In fact, I can point out several references on his pages that directly refer to either myself or the group of people that have been arguing these points with him for the past 3-4 years. :-)
:-) Another favorite tactic: stridently insist that everyone else bring the proof. He's making the observations, but we have to prove it. :-)
Bryce's biggest problem is that he won't actually learn how to use the stuff he criticizes. He's more concerned with making the point than actually making a *valid* point.
He was an XBase programmer for a long time, and gradually saw his "niche" get eroded as people went on to better ways of programming business applications that subsumed his "TOP" methods. However, since he doesn't understand these other methods, he would prefer that the entire world take a step back in the WayBack machine and merrily go back to using FoxPro and Clipper.
He's also never done anything larger than what I would consider to be extremely small applications. A few of his comments are applicable to a very small segment of the programming world, but unfortunately he tries to apply them across the board.
Don't ever try to pin him down, though. His niche will morph as he tries to avoid any logic you might bring to bear on the discussion.
Priceless hours of entertainment if you ever get him in a discussion, but after a while it wears thin. He tends to get abusive and obscene when things aren't going his way. He has moderated that a bit lately, but occasionally the old Bryce surfaces...
Regards,
-scott
Regards,
-scott
I agree with his premise based upon what his application development space has been. Typically, OOP practices do not pay off until the maintenance period of a product and it does tend to slow down the development cycle because you have to put more thought into what you are designing. I think that this guy's point of view is incorrect though because he has only ever had to be the initial designer of a product and has obviously never had to assume somebody else's code base where he had to figure out what the initial developer's purpose of code was. He has a pretty narrow view of the world and I think if he had to maintain somebody else's code or take an existing product and continue to evolve it, he would rapidly find the advantage of code reuse due to OOP practices. I also noticed he has some fundamental misunderstandings about OOP. I could pick apart almost every statement he makes about the downside of OOP. I only agree with 2 statements of his - OOP advantages are only realized over time and that an OOP project needs to be well managed in order to be effective. This latter point though is true for any project and in fact ends up encouraging well managed projects whereas non OOP products tend to promote a program as you go methodology that promotes mistakes too late into development to back track from. I could write an entire book on why this guy's views are inaccurate and from a very narrow point of view. By the way, there have been new development disciplines to speed up this exact process he is complaining about. http://www.extremeprogramming.org/ . What he needs is not a non OOP language but instead a faster methodology for development of an OOP application.
-- Betting on the survival of the media industry is a serious risk. I advise investing elsewhere.
my point is that people dont properly implement programs with oop techniques because they have only been taught how to write procedural programs and dont know how to design a program in terms of objects and their behavior. if we want more people using good oop techniques, we need to teach the first programming courses in oop languages and stress oop design from the beginning.
Anytime one find themselves having to write workarounds, they should sit back and ask themselves this: If that's what I want to do, and this tool won't let me do it easily, why am I using this tool?
What happens in a non C-stack compiler? The only one I am remotely familiar with is Stackless Python, which is, obviously, impossible to validly compare to gcc, but avoids the C stack. By allowing frame changes the way it does (cannot remember the term the devs using it like for changing execution point between frames, grrr, it should in theory allow much more efficient virtual method calls.
Ah well, this is all one more reason to go back to grad school again and build better compilers :)
Frums
[quote] OOP is to help *PROGRAMMERS* write better, more extensible, more maintainable code, and optimization of code, speed, and badly written code are secondary. [end quote]
"Meant to help", yes.
Proven to help? Try again.
"The road to hell is paved with
good intentions"
(And by which metrics?)
Table-ized A.I.
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
Doesn't matter what language you've decreed to be used, if all you have are bonehead programmers, you're going to get bonehead code. The, um, quality of the code may be *slightly* different based on the language you've picked, but not enough to matter.
Hire good managers, hire good people, and let them pick the language and write their code.
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.
[quote] That's not a misconception at all. 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. You can't do things derive a new type of struct from another type of struct. [end quote]
Personally, I use relational tables instead of internal array strucs. More scalable in many many ways. (Please, no arguments about speed.)
However, I doubt such a feature would have much use in my domain. The differences in things are usually not well modeled with tree-based inheritence.
For one, what if you wish to change the original structure? You then have the "fragile parent" problem. Few things are safe to couple in such a way IME because few business things are IS-A relationships (unless you are a bad modeler).
Table-ized A.I.
I haven't enjoyed a good old-fashioned proto-rational flame war since I stopped reading USENET. I'm delighted to see it has thoroughly made its way to slashdot.
Face it, dude, you are a troll. You're just after attention, and you've got it. We've all seen this behavior before.
(as I fan the flames... whee!)
Maybe we need a way to mark a top-level post as "flame-bait" now.
[quote] 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. [end quote]
The "state" is usually (and best) stored in a RDBMS (or it's buffers) IMO. (RDMBS have flaws of their own, but they are usually vendor-specific and not a fault of the paradigm.)
[quote] 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. [end quote]
That was not my point. Like Communism, OO looks great on paper, and it sucked in a lot of intellectuals because of that.
Table-ized A.I.
with all this hype about "smart templates" and crap. I just met a sys admin who was sucked in.
It may certainly have it's place, but like OO, it is way overhyped at the moment.
Table-ized A.I.
Indeed. We tried this back on IWETHEY, and earlier back on IWE. It didn't take us anywhere but 'round in circles.
Good luck with the clueless horde here on /. You'll need it.
Wade.
My failure to realise this in the mid '90s was why I fell off the greasy pole. I was a technically oriented manager who pushed one of my project teams to build the next product in an object oriented way. I failed to understand that whilst an OO mindset was obvious to me, to the programming team they couldn't get a handle on where to start. Net result is a project that went nowhere for 6 months and didn't get moving until I abandoned my insistence on an OO approach. This killed me with the costs of the project overspend which brought the rest of my profit centre to its knees. I am no longer a manager with these sort of responsibilities.
Even today, I still feel architectually the OO is right and works the way I happen to think - but I have to be honest and realise most programmers don't seem to have the same mindset and that kills the benefits that can be had.
In "What's in a Name?," Kent Pitman makes the case that the notions of identity and intent to extend are at the core of object-oriented programming, not some check-list of features. But read the paper, not just my poor paraphrasing, as Mr. Pitman always has an interesting point to make.
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
I'm proud of my Northern Tibetian Heritage
[quote] Although it is hard to take this page seriously (the comparison with Communism just killed me) [end quote]
That is just an excuse to ignore the rest.
[quote] 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? [end quote]
I discussed Y2K OO claims in the "Meyer" section.
I guess I should add "OO would solve Y2K problems" to my myths.
[quote] Here I just think its funny that he lumps C in with Java and Pascal as a "strongly-typed language". [end quote]
Compare C to Perl, and then try another giggle.
[quote] I'd like to add that IMHO, OOP builds on procedural (structured) programming. It usually allows better abstraction than procedural programming [end quote]
I disagree. OO's brand of abstraction is too narrow (single-aspected) and relies too much an tree-based taxonomies. (Without the trees, it is not much different than procedural, as already discussed.)
Table-ized A.I.
Where once project is broken down into may parts and when you use another part, you don't see source but just get a library. Even when you don't have "source" you still have header files. That being said, I hope I never have to use C++ again.
This message composed using 100% recycled electrons.
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.
Operator overloading is a C++ feature, not an OO feature.
We're going down, in a spiral to the ground
Herbie J.
I stopped reading this site after the whole Apogee incident a while back, now I'm tempted to hop off again. I mean c'mon, this article is nothing but a trolling rock of flamebait, and a bad one at that - it could have been condensed into a one paragraph synopsis of "I hate OOP because..."
This article is nothing but rant. There are no sources, especially for it's "graphs" (which I suspect took someone about 10 minutes in PhotoShop to research). It's almost completely subjective rhetoric with some mock code tossed in for good measure. My cats running on the keyboard chasing a string could have written a more constructive and thought-out analysis of OOP.
The description for this should have read: Here are some good links on OOP. They're at the bottom of this otherwise useless webpage, so scroll quickly.
OOP is a mindmelding piece of communism?? I mean do you guys read these things before posting them??
It's on a geocities server... expect it to be slow; at least, geocities sites generally seem to be slow as far as I can tell...
"Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
[quote] Really, has anybody used "it's object-oriented" as a selling point since 1989 or so? [end quote]
Java (Sun), MS, etc. Any new language, even a scripting one, HAS to be OOP in order to be "in".
[quote] Accepted by whom? I've never heard that asserted by anyone in my academic or professional careers. [end quote]
I am sorry I did not keep better records. However, that figure has floated around several times and most debate participants seemed to agree with it.
[quote] When Pascal replaces C, how do I convert my C functions into Pascal functions? Eh? [end quote]
Don't. Put most of the control information into a database. It is easier to transfer data than transfer algorithms.
Table-ized A.I.
I've done quite a bit of C++ programing and never once in my life have I reused code through inheritance - it's actually more cumbersome to do it that way.
Destrago Z. Scudiero -Noize Incorporated -Void42
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 might have a big mouth, but that does NOT
make me wrong.
BTW, where are your 3 examples?
Where is one?
What, no proof?
Ah, poor widdle kid.
Table-ized A.I.
[quote] Indeed. We tried this back on IWETHEY, and earlier back on IWE. It didn't take us anywhere but 'round in circles. [end quote]
No, the trivia battles went in circles. The proof itself NEVER CAME. You guys do not have the smarts to build 3 biz app/model proofs.
You flunked!
(Note that many admitted they didn't want to bother making examples. But, that is their short-coming, not mine.)
Table-ized A.I.
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
[quote] If you don't like the way a class works - rewrite it - but preserve its interface. [end quote]
http://www.geocities.com/tablizer/chal03.htm
Also, the problem with method overriding is that the granularity of the differences often don't match the method scope. It is tricky to override say 1/3 of a method without refactoring your interfaces.
Table-ized A.I.
Peope with any sense at all will ignore this article. Of course OOP is not ideal for everything. It seems to me that the author had trouble with OOP, and wants to whine about it. Sure, he a couple got articles to support him, but that is no big feat, considering how many articles there are out there about this topic (pro or against oop).
Perhaps the author is working with some OO code that is really ugly, or back-asswards. It's my personal belief that by far the best part about OOP is it's tendancy to be self-documenting. The NOUN.VERB(OTHER_NOUN) convention is great. Sure, procedural programming can do that, but there is no convention for such things.
Navyrain steps down
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
NO, that is NOT what it is all about. There are plenty of technical issues to take head on: multiple orthogonal taxonomy criteria, the "method boundary" issue, etc.
He repeatedly fails to back up any of his points with citations or references
Moot. The burden of proving that OO is better is on you, not me. Remember: benefits are same or unknown until proven otherwise. I DONT claim that my favorite paradigms are provably better.
myths are outrageous to the point of being silly... Only Only OO databases can store large, multimedia data?
Bertrand Meyer hinted this in OOSC2. (See OOSC2 critique section). Many trade rags also imply similar things. Is Berty silly then?
Who, exactly, does believe these myths? PHBs?
YES! I did not exclude PHB's from my audience, BTW. They are full of myths as well.
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.
Being that I have zero budget, it is not a perfect paper. However, there is plenty of technical meat in there for those not looking for instant-reasons-to-excuse-it.
Table-ized A.I.
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.
An article by Katz on how the infospere is filling up with crap, next to this article... it's a sign I tell you.
I was going to write to refute this junk, then I got to the bit about "Why OOP is like communism" and realised that it was a waste of time. He's a crank and a troll.
My Karma: ran over your Dogma
StrawberryFrog
OO isn't something you plug into your software development system the way you put a faster processor into your computer. Instead it's a different way of approaching your problem space. From this perspective, it becomes much more like religion so why do we bother discussing it? Because we have to. If I design a system in an OO way, then those using my APIs had better learn to like them. However, arguing that ridiculous points like those in the article above isn't going to get you anywhere towards this goal in a software development organization. Liskov's book provides ample support for how object abstraction can help software. The subjects discussed in that book above show why OO is good, but do not forget that many ideas can be applied in non "00" languages. Liskov talks a lot about abstraction, which can be used in any programming language.
Sheesh.
Go ahead and moderate this message down. It's just a troll---the same as this entire thread.
end of line
I have encountered many places where OOP is placed as the main priority for any programming task. Make it object-oriented and all problems become easy etc etc etc.
OOP is a tool, like any other language feature. If the problem you are trying to solve could be easily done with a collection of interacting, self-contained objects, go for it. If not, use something else.
For example [entering the flamebait zone], I have never seen the point of making the entire app a class. Can someone explain to me how this is better than a simple main function?
You guys did nothing but argue by authority and vote. You presented nothing inspectable, only presented irrelavent trivia games.
Table-ized A.I.
Sure you can write OO code in C. I can tell you fron personal experience that it is a pain in the ass.
We had inheritance. Kind of.
We had virtual functions. Kind of.
We had templates. Kind of.
We had exceptions. Kind of.
It was all proprietary (meaning that new employees would have to learn "our way" rather than just use existing knowledge of C++). It also integrated poorly with debugging tools, and contained bugs. (And I realize that templates and exceptions are not OO per se...) Switching to C++ and throwing out most of that crap was amazingly liberating...
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
>>IOW, you claim your car is faster, but you won't race it. If you won't race it, how can I compare? All I can do is concluded that you are probably full of it. This is where the situation stands right now.
No, you dumb-fuck, it's more like YOU claim that your type of cheese is better than my type of cheese, and that my reluctance to enter a cheese race is due to the fact that I think my cheese will lose, when it's in fact the case that you can't race cheese. (i.e. you can't PROOVE that OO is SUPERIOR to procedural, it's just true that my nice fresh cheddar is better than your 20 year old piece of Brie you found behind the 'fridge...)
Graspee
P.S. Please, no posts on the practicalities of cheese racing- it might encourage G. Lucas to put a scene in Episode II...
I have nothing against specific wrappers for tree-centric operations, but overemphazing trees is not a good idea IMO. Microsoft has started orginazing feature selections into trees, and they often drive me bats when they get above say 80 nodes.
By "two deminsional" do you mean physical or logical?
The real question, is which format does the data exist in natively....
Should that matter? Is it a speed issue, conversion issue, or what do you have in mind?
IME, the "format" is often mixed.
Table-ized A.I.
Is a can of c++ like a can of worms?
Heh heh, oh yeah, of course it is.
Graspee
[quote] 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 [end quote]
Example?
Many OO debaters often stretch the meanings of the the big three (poly, inher, encap) to mean whatever they want them to mean. I sometimes say that OO is the Al Gore of paradigms. "Encapsulation" is such a vague, watered-down word that it can mean just about anything you want it to. Anything that is "not at the right spot when you need it" can be blamed on "lack of encapsulation".
Note that many of the goals of OO can be achieved in ways that are not necessarily OOP.
Table-ized A.I.
The author spend a lot of time in writing his thesis, he should have spend that time for learning OO.
...
...
His writing is full of sentences: some claim so and others argue that way
Or: even OO purists admit
Well, there are so many errors in his writing that it realy scares me:
E.g. OO is not a technologie of the past ten years, during the past ten years it came in comon use.
OO is at least 40 years old now and in academic environments NON OO is rarely ever used during the past 10 years.
Actual Software Sciense is allready far beyond OO, currently we are working on Subject Oriented and Aspect Oriented programming. -> www.aspectj.org, or see alphaworks.ibm.com and search for hyperJ.
Or Active Libraries and Adaptive Programming.
He talks about OO data bases and also about their complex API, and need for mapping or middle-tier mapping experts.
Modern OO data bases have nearly no API, the DB is "mapped into virtual memory" (thats a simplification). There is no mapping needed from attributes/objects to fields/tables.
(But you can define one if you think this is more efficient for your purpose)
He covers nearly everything from frameworks via patters over internal(whitebox) and external(blackbox) reuse up to metrics.
Nearyl every buzzword of OO is in his papers!
Sad that he did not spent the 15 years research the pattern experts spended nor the 30 years research the framework experts spent nor the 15 years research the OO data base experts spent, not to talk about the 40 years research the relational database experts spent.
Sorry, folks, its silly to talk about productivity in a question wether procedural or oo is more productive and to compare a 30 year XPed procedural programmer with a 5 year XPed oo programmer.
In my opinion its also silly to talk about programming regardless what kind of programming you do and regardless what paradigm you use if you have less than 10 years experiance.
That everybody and his dog can programm with Visual Basic does not mean that those are programmers.
I program in C++ and JAVA and C++ gives me a lets say 2 fold boost in effectivity versus JAVA and JAVA gives me nearly a two fold effectivity versus Pascal. I KNOW for my own that OO is the better concept. (I had 10 years Pascal XP before I realy switched to C++ and have now +10 years XP in C++ and about 4 in JAVA)
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
[quote] 1: "Biz things are too dymanic to be modeled via tree taxonomies"
As you have been told time and time again, there is much more to OO techniques than simple implementation inheritance modelling. [end quote]
Show us all code proof!
Besides, you take away trees and tree-driven polymorphism, and OO starts to look an awful lot like procedural.
Besides, some OO fans still insist on tree-based modeling.
[quote] But then again, Java is not the sum of the OO world. Of course, you can't be bothered to learn things like Smalltalk or Python [end quote]
But some of us don't want to move to Ohio to get jobs.
Further, how do they improve things? Code example?
Table-ized A.I.
If you are unable to prove that OO is better, that is NOT my problem. Stop making excuses.
Table-ized A.I.
That article is very funny. First, it presents many alleged myths of OOP. Sure, these are very well myths from 70's, I guess there have once been people with such beliefs.
The author seems to confuse OO with some other programming techniques. What does OOP have to do with garbage collection, multimedia, OODBMS, visual programming, or even taxonomies or modelling the real world? These are all part of what programmers need to deal with, but none of them are OOP. So at minimum, blaming OOP for this is seriously misplaced.
The article also confuses and mixes object oriented _modelling_, object oriented _analysis_ and object oriented _programming_ with implementation mechanisms used commonly in major programming languages (e.g. C++). Look at some differently designed programming languages (e.g. Haskell), and you see that none of the assumptions made in that article are valid.
There is the concept of modelling the real world in object oriented _analysis_ (OOA), but even there, the article fails to reveal any insight on the problems people are having with modelling. In reality, no analysis method currently available does adequate job in modelling the real world. Nor are they intended to attain the impossible.
The concepts that programmers are modelling are more complex than many people think. However, mostly all the analysis machinery is exactly the same whether one uses OO methods or any other modelling technology. All analysis methods focus on finding the relevant pieces of information, and creating a simplified model that reflects it. Different modeling techniques make different simplifications. Then the software is written to assume this idealized reality.
The most common problem with modelling is that there are too many things that are simply *unknown*. Good software designers can identify concepts or constraints that are not well known, and reflect this uncertainty in the model by introducing flexibility. How this flexibility is provided is not important. Polymorphism (and not inheritance) is one tool provided by OO to doing this. Asking for user input for the unknown things is another (non-OO way).
In contrast, the article attacks inheritance because it uses a hierarchy. This is just silly. I was not surprised at the references to communism.
For *really* good information, see: Portland pattern repository, or any bibliography server (e.g. NEC Research index)
-- Esa Pulkkinen
Repetition ad nauseum.
As I said, people who are interested can go read the OO forum. I don't intend on wasting any more time on this subject than I already have over the past few years.
Hopefully this will trigger one of Bryce's "repeat the same word or phrase over and over again in the hopes that his argument will be lent more credence by the act" episodes. Those are always entertaining.
Regards,
-scott
Regards,
-scott
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.
First of all, OOP is just a method for programming. It is not about reducing the size of the code or making programs run faster. It's main purpose is to make programming projects, particularly large ones easier to organize. The website seems to attack object oriented prgramming beacuse other people have attributed non existant quialities to it. Instead of attacking OOP, it should try and explain what OOP is really about, rather than making it seem like a really useless (or stinky) method. OOP is not bad or good it is simply another method of programming. IMHO OOP is my programming method of choice. I find it easier to organize the structure of a program, even small ones, before i program it. This is just my preference and I do use other methods depending on the task at hand. I suggest rather than picking one method over the other, understand a bunch of methods and pick one that best fits your programming task.
People can go on and on about why one is better than the other, but if one is more natural for me to use, it's better for me. And that's what counts.
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.
"We accidentally lost the references."
Regards,
-scott
Regards,
-scott
the original article has its points, but the author is really rejecting the culture of hype which has admittedly grown up around OOP, without really tracing it down to its theoretical roots.
the thing that makes programming hard is that you have to try and reduce a set of ideas in the human mind to a set of operations that can be performed in a Turing-complete computational environment.
that's not easy, because most people don't think in a computationally disciplined manner. . those who did presumably got flattened on my mastodons a few zillion years ago when they experienced the caveman equivalent to a BSOD.
therefore one of the things languages and programming styles do is give programmers ways to keep track of the larger-order logical machinery of their code. . the better a language is at making that logical machinery manageable, the more useful it can be.
structured programming isn't just the programmer's version of brussel's sprouts.. something you have to put up with because people say that it's good for you.. it makes finite automata and pushdown automata immediately visible in your code. . at least, it makes them visible if you know where to look.
here's the trick: every function is a state machine, usually following the pattern:
(acquire data) --> (verify data) --> (calculate new value from data)
with conditionals being there to handle internal branching, like reporting an error when the verification step fails, instead of doing the calculation.
and since each function has its own private scope for data storage, each function can act as a self-contained section of data storage.
when you chain finite automata together, such that one passes a value to the next one, and receives a value in return, you get a pushdown automaton. . therefore, structured programming is really just the art of reducing problems to computational methods that are easily expressed as pushdown automata, and represented as code in which functions with isolated scope pass parameters and return values back and forth.
and that's lovely, but it's not powerful enough to be useful.
pushdown automata have their limits, and there are some problems you just need to handle with a Turing machine.. binary multiplication, for one.
to get around the inherent limits of purely isolated function scopes and parameter/return passing, structured programming languages also support global variables, which make data accessible to any scope, regardless of its connection to the call-return chain of the pushdown automaton.
and that makes structured programming powerful, but it opens up room for all sorts of messes. . the global values that link sections of the program together are harder to keep track of than the calling heirarchy of a structured program, so structured programming isn't quite the best tool for making the logic that holds a program together visible. . then there's the little fact that with two integer counters and a bit of determination, you can implement a fully-functional Turing machine that's all but invisible within the code. . most people don't do that per se, but if you store enough important information in global variables, it becomes difficult *not* to evolve a Turing machine to manage it. . and that Turing machine evolves in a million little corners of the program, none of which seem to have any obvious connection to each other.
OOP makes Turing machines visible, because it gives us the concept of an isolated scope which is larger than a single function, but smaller than the entire program. . other languages have done the same thing.. C's file-scope restrictions, for example.. but OOP is the system that actually puts a name on it and makes it easy to see.
the data structure which forms the visible instantiation of an object can be seen as the tape of a simple Turing machine. . the object's methods manipulate values on that tape, but only those methods have access to that tape. . the rest of the program only communicates with the object (Turing machine) through an i/o interface that doesn't affect the data stored on the tape.
an object-oriented program is a network of Turing machines.
can you fuck that up royally? sure.
can you write well-organized code with other tools? of course.
is one style of programming inherently better than another? hell no.
the reason to care about OOP is that it's convenient.. that's all. . it gives us a nice framework in which to arrange important ideas, so we can get on with the real work of reducing human assumptions to computationally effective logic.
and that's why programmers need to know.. as in 'grok in fullness'.. as many different styles of programming as they get cram in their heads. . each one gives us a convenient way to talk about some other set of important -- and *useful* -- ideas.
[quote] C++ is *NOT* OO! [end quote]
... " 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. [end quote]
I will save you guys time: This usually de-generates into a discussion about whether OO is a philosophy or language features, or degenerates into C++ fans versus Smalltalk fans.
[quote] 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()
Give me more details and I bet I can write a procedural/relational equivalent that is just as simple/small.
If there is only one-level of inheritance, then subroutines can centralize things just as well. If there is more than one level, then I can probably show some "fragile parent" design problems.
You are probably just comparing bad procedural with good OO.
Table-ized A.I.
The important ting for real world programming seems to me to be that the programmer builds what is needed, when it's needed - so the program's language and design style help with smooth and easy rearrangement of code.
What this means in practise:
Go look up "Extreme Programming" for what is IMO the best approach to real world software building.
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.
[quote] Repetition ad nauseum. [end quote]
That is because you repeat your same authoritarian garbage over and over again.
Just prove me wrong with 3 biz examples so we can end this once and for all. Otherwise, I will keep popping up all over the net.
Table-ized A.I.
Yes, this article was not worth to show-up at /.
Absolutely out-of date, everything was said 15 years ago.
There are 2 correct points in this article:
1) OOP requires more skills, so if you don't have money for a good team, don't do it.
2) Each task requres its approach. In some cases, you have to use non-OOP languages like Prolog, Lisp, C, Perl.
All other points in this article are invalid and outdated, IMHO
Andrew
I merely (strongly) suggested they see what has come before, and what has argued before. Before they get into it with you. (Which, in my opinion, follows the same path time and time again...)
:)
:-)
(Searching on Deja for topmind is a good idea too, but largely redundant).
Of course, if you're right, you wouldn't object to them reading those prior arguments, would you?
I'm quite happy to let them draw their own conclusions.
Addison
Well then when, where, or why OO is better should be documented and researched. Also, many OO fans say "it's good for small stuff also".
I disagree with heavy OO modeling for biz apps, large or small. Biz things are too dymanic to be modeled via tree taxonomies. If you disagree, post an example.
By definition, only about 1/3 of all code is for "large projects". What about the other 2/3's?
People who dismiss OO out of hand are making the same mistake as zealots who insist that it must be used for everything by rejecting a useful tool.
I agree with balance, but am not seeing it. You have to suffer thru a lot of junk to do procedural Java, especially if you have more than one file.
My point is that OO is oversold, NOT that is has NO place.
Table-ized A.I.
It was only an illustrative example that actual is only marginally related to OOP. Each approach will have it's own pros and cons.
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,
Well, often the differences do not fall neatly into sub-type taxonomies. Real world things don't chop up nicely into taxonomies for the most part I find (at least not lasting ones). See the Employee example.
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.
A "parameter approach" is only one possible procedural/relational way to do it.
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.
You are talking about shop-specific conventions (method per file), not paradigm differences. I agree that procedural/relational software engineering research has slowed or stopped, but that is because the OO hype sucked away attention and resources. Again, the self-fulfilling prophecy.
(I am starting to document what I consider good procedural/relational modeling. Most of the historical stuff ignored RDBMS.)
You are welcome to supply more examples.
Table-ized A.I.
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."