From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_05,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: Tansel Ersavas Subject: Re: What is wrong with OO ? Date: 1996/12/17 Message-ID: <32B758D7.61EF@deep.net> X-Deja-AN: 204625619 references: <32AA207E.3199@deep.net> <32B3F45C.5140@deep.net> <5956ll$16d@krusty.irvine.com> content-type: text/plain; charset=us-ascii organization: RASE Inc. mime-version: 1.0 reply-to: tansel@deep.net newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; U) Date: 1996-12-17T00:00:00+00:00 List-Id: Adam Beneschan wrote: > > OO techniques are a relatively recent development. Major software has > been developed for the last several decades. If the above statement > were true as written, one would have to draw the conclusion that > software developers, whose best tool was "procedure-oriented > techniques", were unable to produce ANY good software, and the > software they did produce was dangerous. OO techniques are not a relatively recent development. OO has been around since SIMULA (1965-1967). > > Clearly, that isn't the case--a lot of good software has been produced > over the last 30-40 years. Procedure-oriented programming has its > limitations, and OO pioneers must be credited with exposing its flaws > and, more importantly, developing a viable alternative. This hardly > makes procedure-oriented techniques dangerous or wasteful or > unproductive. This is true, depending on the criteria that you are using. There are a lot of procedure oriented systems that I developed or was the architect of, and are considered very good. Individual success stories don't change the following facts though: a) Software industry is in a crisis. b) The application gap is still growing c) Every year abandoned software costs the world economy unmentionable billions of dollars. d) Even many so called successful projects Today are big money drains e) The approach we use for systems development influence a, b, c and d How can we justify massive collapses of big systems with hundreds of millions of dollars down the drain with a cool face? If we don't call this a failure, what are we going to call? If it not waste, I would like to learn your definition of waste. And, dangerous, yes, because it creates a false sense of security once people get used to it. > >So far OO > >couldn't show a quantum leap of difference, but it is not mature yet. > > Another reason there isn't a quantum leap is that procedure-oriented > programming is not the demonic evil you make it out to be. I never said procedure oriented programming was the demonic evil. I just said, wasteful, dangerous, and unproductive. I must admit, when I was developing procedure oriented systems, I would enjoy developing them. Something can be dangerous, but still enjoyable; take motorcycle riding. It is very enjoyable, and the bikes are beautiful, but it doesn't change the fact that they are a few times more dangerous that cars. How can I say that motorcycle riding is evil? But it doesn't stop me from pointing out dangers to myself and others. Or take guinea pigs, they are lovely pets, but they are wasteful, and unproductive IF you have all females (males tend to fight, and male-female combinations are extremely productive) but they just are, they make cute pets and we enjoy them. Things just are. We simply observe them, and put out our comments from our perspective. We don't want to sort things out as good or evil. Potential dangers should be noted though. I.e. it is a nice idea to mark quicksand as dangerous, especially if you saw some people drowning. > I'd hardly call it a "historical accident". Procedure-oriented > ("structured programming") techniques were a huge improvement over > what was done before, which was to write code haphazardly and > completely unstructured. Whether we had the know-how at the time to > develop OO techniques instead of procedural techniques, I don't know. > Probably not. I suspect that the structured-programming "revolution" > was a necessary step in the evolution of software engineering > techniques that is now leading us to OO techniques and will probably > lead to something completely different a couple decades hence. In > other words, our experiences with structured programming have taught > us a lot of the things we needed to know in order to develop OO > techniques--things we wouldn't have found out if the evolutionary step > you call a "historical accident" had never taken place. In fact, you are right. I shouldn't have called it a historical accident. It is actually a series of historical accidents. I'll put some of these historically important milestones to somewhere in my site, so that it can be visited like a museum, for people have tendency to quickly forget. As an example would you like to tell me say, how and why one of the most popular languages "C" was developed to prove your point that the language which is very widely used now and enjoyed by many (which includes me) is not a historical accident? And yes, there are undeniably a few moments in recent history which were carefully planned attempts to solve problems, but they are more exception than the norm. Also, I would like to clarify that structured programming is NOT procedure orientation. Writing code haphazardly is also procedure orientation. Procedure oriented programming is the technique we apply when we write code directly for a von Neumann machine. I don't deny that structured programming, structured design and structured analysis are all big improvements over unstructured procedural approach, and all of them are procedural as much as a spaghetti code, they are only more structured. I have explained in a few of my previous postings, and I get many requests to repost them, but, I feel that people are already getting sick, I'll organize this information and present it in our web site: http://www.rase.com/ after the new year break. So if you want to know what I mean by "historical accidents", and other information that I present, along with the proper references. Please browse after the new year's eve, and if you have any questions or problems I'll be happy to discuss either publicly or via e-mail. > The rest of this post, which I didn't quote, runs along the same > lines. To be honest, if I was in a management position and needed OO > training, I wouldn't consider using your training services, since I > can't tell whether you're turning out good software engineers or > engineers who go around chanting "Four legs good, two legs bad" . . . > er, "OO good, Procedural bad". Again, something, I couldn't possibly have told, or taught without reason. On the other hand, as a trainer (which I am occasionally, only because I enjoy it so much), If I were to be able to help you, I'm sure both of us would benefit. I feel that sharing what I know is a duty. I am not sentimental. It wouldn't bother me if you wouldn't come to me Today, but in 5 years, things may change, and if you come to me then, I'll do my best to accommodate training your people. And a guarantee, nobody will be chanting anything without solidly supporting these ideas with figures and references. Why is it difficult to accept any questions, comments and criticisms about procedure orientation? If you accept the premise that procedure orientation was as good as you say it is, how do you explain a big failure rate in complex software, and lost billions? > Come on. OO is a better mousetrap, not a knight on a white horse come > to save the world from the evil oppression of procedural thinking. > Thinking about it in such a polarized manner is not going to produce > engineers who understand software engineering issues realistically. OO can be a mousetrap, yes, but guess for whom? It is clearly a knight for some. Remember, only the princess who kissed the frog got a prince, to some other, it was just a frog. Coming to the issue of engineers that understand software engineering issues realistically, If we don't change things right now, Tomorrow will be the same. Many people rightly pointed out that as long as the university curriculums don't change, engineers of Tomorrow will not be so much different to engineers of Today. All I want to do is to start changing things Today, so that I can tell my children that I have done what I could. > -- Adam Tansel ----------------------------------------------------------------------- RASE Inc. Clark NJ USA Voice: (908) 396 7145 mailto:tansel@rase.com Fax: (908) 382 1383 http://www.rase.com/ ----Sufficiently advanced technology is indistinguishable from magic--- A.C. Clarke -----------------------------------------------------------------------