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=0.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 11cae8,b87849933931bc93 X-Google-Attributes: gid11cae8,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: adam@irvine.com (Adam Beneschan) Subject: Re: What is wrong with OO ? Date: 1996/12/17 Message-ID: <5956ll$16d@krusty.irvine.com>#1/1 X-Deja-AN: 204485667 references: <32AA207E.3199@deep.net> <32B3F45C.5140@deep.net> organization: /z/news/newsctl/organization newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.lnag.java,comp.object,comp.software-eng Date: 1996-12-17T00:00:00+00:00 List-Id: In article <32B3F45C.5140@deep.net> tansel@deep.net writes: >First of all, my opinion is, developing systems with procedure oriented >techniques is a dangerous, wasteful and unproductive process. 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. 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. >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. >When I train people, I look at their background. Usually the more >experienced in the traditional techniques they are, the less they >believe the necessity of learning a new technique. In my breakthrough >courses, for the first part, I challenge the traditional ways of systems >development and show that this way of developing systems is a historical >accident, and the more we insist on going that way, the more troubles we >will be in. 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. >Unfortunately, with their slow and wasteful structure, big companies can >absorb huge amounts of losses without blinking. This contributes a lot >to people not realizing how big the crisis is. In fact, even many >succesful systems Today are big money wasters. >Procedural thinking and OO are not complimentary. Procedural thinking >requires a major transformation that affects all our thinking. I know >it, because I was a procedural programming freak, starting programming >with a 6502 board with hex keypad, and being a mad assembler, C and >later C++ person. Even when I was a C, C++ person my productivity was >substantially higher than others, I couldn't make the switch to OO until >I let my strong and enjoyable procedural skills go. Now I only program >with Smalltalk (not a prerequisite to anything, just a choice), and I do >everything in a much higher level previously unimaginable to me. My >productivity increased 5 fold, and I developed a tool to further >increase it another 5 fold. Now I know that the tools and techniques I >use are anywhere from 5 to 25 times better than my old techniques >before. These techniques are pure OO but I am reaching limits of them. >Therefore I expanded my horizons to other techniques that I combine with >OO which will increase my productivity another order of magnitude. 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". 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. -- Adam