Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: adaworks on 15 Jun 2005 15:03 "Robert C. Martin" <unclebob(a)objectmentor.com> wrote in message news:k0rda1haskdjl53ujmo1uk37j5cpsqc44f(a)4ax.com... > > Polymorphism is a tool, not a solution. Topmind rails against the > tool because there are cases where it doesn't work well. I, for one, > am glad I have the tool. > Yes. There seem to be so many people who look at a tool and see only where it does not work, not where it does. For some reason, they are inclined to notice only the limitations, not the benefits. Then again, there are the "true believers" who, having learned a new tool, language, method, or concept, seem predisposed to blindly and uncritically adopt it, even in the absence of all evidence of its limitations. There has to be some happy medium between being a "true believer" and a confirmed naysayer. I am convinced that, 100 years from now, those engaged in some practice that evolves from what we now think of as software, will look back on our feeble attempts with the same admiration we give to mathematicians in the time of Charelemagne. All the languages we use will be gone. Most of the methods we enjoy today will have been replaced. The notations we revere will be completely gone. Current software practice is crippled by our inability to truly deal with the complexities that are inherent in it. The Von Neumann model, while useful in the past, will eventually be regarded with the same regard we now give to pre-Copernican cosmology. Still, it is in our interest, as software practitioners, to seek ways to solve problems, not to continually focus on finding problems. It is easy to find fault with someone's software solutions. It is much more difficult to discover how to use those solutions to build dependable, maintainable, long-lived software. I commend you, Robert, on your ability to see the positive benefits of different languages, tools, methods, and concepts rather than simply denounce them because they don't conform to the way you have been doing things. Richard Riehle
From: Leif Roar Moldskred on 15 Jun 2005 15:24 <adaworks(a)sbcglobal.net> writes: > I am convinced that, 100 years from now, those engaged in some practice > that evolves from what we now think of as software, will look back on our > feeble attempts with the same admiration we give to mathematicians in the > time of Charelemagne. All the languages we use will be gone. Most > of the methods we enjoy today will have been replaced. The notations > we revere will be completely gone. Well, I don't know. 100 years isn't _that_ long. After all, COBOL is already 45 years old, and is _still_ being used to develope software with. -- Leif Roar Moldskred Y10K, anyone?
From: adaworks on 15 Jun 2005 15:24 "topmind" <topmind(a)technologist.com> wrote in message news:1118377338.459992.37190(a)g44g2000cwa.googlegroups.com... > > What about something like an airline reservation > system, a student grade tracking system, > and inventory system, a finance estimating system, > etc. Maybe they are not glamorous or fun, but THAT > is the kind of thing that most developers work on. > I can mention, but am not free to name the client, an airline frequent flyer program that is programmed using OOP complete with multiple inheritance, polymorphism, dynamic binding, generic templates, type safety, and graphical user interfaces. It also includes a database that seems to work quite well. There are plenty of applications that have been designed using OOP. Some of these are in C++, others in Ada, others in Java, and more recently, in C#. Eiffel and Smalltalk applications, while not as abundant, also demonstrate the value of OOP. I don't have direct experience with Ruby, but I understand that has some successes. As to device drivers, that is the last place I would expect to use OOP, at least in my own domain. Far more appropriate are the large-scale applications. Admittedly, polymorphism and dynamic binding are sometimes not appropriate where one is concerned with a high degree of determinism, such as safety-critical software. However, for GUI applications, all the features of OOP seem to have proven their benefit, at least in my domain. Not all OOP applications are good. Some are quite messy, and would be messy even if developed using other approaches. Of course, I have no illusions that anything I have said will persuade you. It seems you have already made up your mind, and the old adage, "He convinced against his will is of the same opinion still," seems to apply, even when you are shown direct evidence contradictory to your view. "What evidence?" you protest. Exactly my point. This is why I long ago stopped wasting my time trying to explain anything to you. Today, I have, for some odd reason, reached some limit of patience and wonder why you even bother to participate in this forum since you clearly have no interest in topic beyond harping on what you see as the failures of OOP. I admire and appreciate critical thinking, skepticism, and a willingness to question the common wisdom. I agree with you that some of the silliness that passes for good software practice needs to be challenged. I do, however, find it tiring when you have no other song to sing than the "show me" tune. It is time for you to publish are well-reasoned paper demonstrating the inadequacies of OOP. Do the experiments. Do the research. Do the work of getting the paper accepted at a referred journal. Otherwise, in the absence of such rigorous critique, your comments are not worth a whole lot to those who are finding value in object technology as an approach to solving real problems on a day-to-day basis. Richard Riehle
From: topmind on 15 Jun 2005 17:55 > > > > What about something like an airline reservation > > system, a student grade tracking system, > > and inventory system, a finance estimating system, > > etc. Maybe they are not glamorous or fun, but THAT > > is the kind of thing that most developers work on. > > > I can mention, but am not free to name the client, an airline > frequent flyer program that is programmed using OOP > complete with multiple inheritance, polymorphism, dynamic > binding, generic templates, type safety, and graphical > user interfaces. It also includes a database that seems to > work quite well. > > There are plenty of applications that have been designed using > OOP. In this case, I am requesting an example of allegedly good OO that many people can publicly disect and analyze. You seem to think I am implying that OOP programs won't run, which is NOT the case. OOP is Turing Complete so that it can produce the correct answers just like any other TC technique, including assembler language. But mere running is not the issue here. > Some of these are in C++, others in Ada, others in > Java, and more recently, in C#. Eiffel and Smalltalk applications, > while not as abundant, also demonstrate the value of > OOP. I don't have direct experience with Ruby, but I understand > that has some successes. > > As to device drivers, that is the last place I would expect to use OOP, > at least in my own domain. Far more appropriate are the large-scale > applications. Admittedly, polymorphism and dynamic binding are > sometimes not appropriate where one is concerned with a high degree > of determinism, such as safety-critical software. However, for GUI > applications, all the features of OOP seem to have proven their > benefit, at least in my domain. Well, I question the way many GUI engines are designed. For one, they unnecessarily tend to be hardwired to *one* particular language, and this is in part a fault of OOP and one of the reasons for the success of HTML and CGI, dispite their clunkiness. It is illogical to reinvent GUI engines for each language. A GUI engine needs to be more declarative to be language-neutral. In general, declarative techniques tend to be more language-neutral, and this is part of why I prefer data-centric techniques. GUI design is a huge topic that is interesting, but let's save that for another day. OOP GUI's were the "best solution at the time", and that is why they were popular. However, that does not mean they are the best possible. But writing GUI engines is one specific domain. Most developers don't write GUI engines for a living. The implication is that OO's benfits are cross-domain, and thus good for "business modeling". I question that. > > Not all OOP applications are good. Some are quite messy, and > would be messy even if developed using other approaches. > > Of course, I have no illusions that anything I have said will persuade you. > It seems you have already made up your mind, and the old adage, "He > convinced against his will is of the same opinion still," seems to apply, > even when you are shown direct evidence contradictory to your view. You *show* me concrete comparative evidence outside of systems software, and I promise to give it a fair hearing. > > "What evidence?" you protest. Exactly my point. This is why I long > ago stopped wasting my time trying to explain anything to you. Today, > I have, for some odd reason, reached some limit of patience and > wonder why you even bother to participate in this forum since you > clearly have no interest in topic beyond harping on what you see as > the failures of OOP. Did OOP help you read my mind so that you know "clearly" I have no interest in such? Now there is a new OO bragging point. If I reject solid evidence, you are allowed to question my motivation. Until then I take offense. > > I admire and appreciate critical thinking, skepticism, and a willingness > to question the common wisdom. I agree with you that some of the > silliness that passes for good software practice needs to be challenged. > I do, however, find it tiring when you have no other song to sing than > the "show me" tune. Damned those skeptics and scientists, always asking for concrete evidence of claims. Spank 'em all! Back to the Dark Ages when annocdotes and nepotism was good enough for truth finding. > It is time for you to publish are well-reasoned > paper demonstrating the inadequacies of OOP. Do the experiments. > Do the research. Do the work of getting the paper accepted at a > referred journal. Otherwise, in the absence of such rigorous critique, > your comments are not worth a whole lot to those who are finding > value in object technology as an approach to solving real problems > on a day-to-day basis. In the age of the web, we don't need journals. They are too stodgey for our biz. Thus, I have a web-site. Plus, my main thrust is challenging OO claimers rather than so much defend alternatives. I don't even claim my favorite techniques are objectively better. There is a huge psychology element to software engineering, but OO braggers make it all sound cut-and-dry. If you say OO reduces the number of lines of code, I will ask you to demonstrate. If you say OO reduces the amount of code that has to change down the road, I will ask you to present your code and a representative set of change scenarios (and might add my own). And you have to describe why you think the alternatives will fail. That to me seems perfectly fair and reasonable. If not, then I guess I am just delusional. The domain-neutral evidence-to-claim ratio seems very very low to me. If it is really high, then I am just plain [bleeped] in the head and seeing the world all wrong. > > Richard Riehle -T-
From: topmind on 15 Jun 2005 18:56
> However, the amount of problems that require a non-hierarchical > classification are rare Now this I disagree with. Trivial structures are fairly easy to make into a tree, but complex structures usually are not. And again, if it is trivial, then it does not matter which paradigm or technique is used; the differences are minor. Thus, we need should focus on non-trivial classifications. I have seen trees fall apart many times. I used to be a tree-fan because a professor once pumped us up with the idea. Over time I discovered the hard way that he was wrong. There are few, if any "natural" forces in the biz world that keep classifications as a nice tree. There are no Tree Cops. I find sets far more natural to real-world classifications as they change and grow. True, sets are probably a "useful lie", but far more useful than trees. Trees are a half-useful lie. It is true that one can *force* any structure into a tree (or set of trees) with enough work, but it will get ugly and hard-to-maintain after a while. Trees are popular because they are easy for most people to relate to. However, being easy to relate to and better fitting actual classifications and actual changes are two very different things. In short: TREES ARE A CRUTCH (In the real world, crutches are trees, unless you go aluminum :-) -T- |