Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!acw!guthery From: guthery@acw.UUCP (Scott Guthery) Newsgroups: comp.object Subject: The Emperor Strikes Lethe Message-ID: <43.UUL1.3#913@acw.UUCP> Date: 7 Apr 91 16:56:40 GMT Organization: Austin Code Works Lines: 135 It's been about a year since I published "Are the Emperor's New Clothes Object Oriented?" in Dr. Dobbs Journal. In that article I posed nine questions that I felt had to be answered in the process of determining if OOP was ready to be used in an engineering or product-development setting. Here's my assessment of the current answers to these questions based on a light reading of the OOP literature since then together with following the various newsgroups on the subject. 1) Where's the evidence? Some is starting to come in. OOP seems to make writing code a little easier. It certainly gives us the opportunity once again to rewrite everything and this means job security for programmers. About every 10 years in programming we have to change syntax and OOP is the change for the 90's. OOP does seem to be harder to debug, harder to test, and harder to maintain when the maintainers are not the developers. 2) What is an object? There seems to be general agreement on what object classes and instances ought to be in theory but practice is something else as witness the debate over my definition of an object. There are still a lot of new words being invented for old ideas. An object class is a coding form or an 029 keypunch control card and an object instance is a tab card. And, yes Virginia, tab cards did inheritance. (What? You don't remember the 029?) 3) What's the cost of OOP code reuse? We still don't know mainly because we're seeing about the same style and level of reuse of OOP code as we do with non-OOP code. Everybody and his dog has done a C++ string class. After 10 years of Objective-C there are still just two Objective-C IC Packs. We still mostly copy source code, hack and go. Unfortunately, there is still enough slop in the definition of the most widely used OO language, C++, that getting one C++ compiler to accept what another will pass is a large problem so even classical reuse is harder in OOP land. 4) How does one combine object heirarchies? One big hierarchy is still the only way to get objects to communicate within the rules of the game since the whole point of hidden internal structure is to make communication with "outsiders" impossible. On the other hand, there are a growing number of practical work-arounds ... friend objects, neighbor objects, significant other objects, passing acquaintance objects, etc. 5) How does one tune an OO program? Well, the way you tune any other program. The program structure itself has to absorb information about how it is being used. Since OO programs are bigger and slower because so much of the development scaffolding is left in the runtime image more of this usage information has to be put into the program. Thus, the complexity of the program increases due to programmer laziness. Of course, since increased complexity means more programmers and job security for existing programmers the reward for this laziness is continued employment. Nice scam. 6) How does one manage an OOP development team? Very carefully and very closely. Since adding new code to an OO system can change the behavior of (i.e. break) old code every programmer essentially needs to know the whole system in order to add code to it. This is particularly the case if polymorphism is used since each programmer has to understand and build on the puns being perpetrated by all the others. 7) Do OO programs coexist? Nope ... C++ objects can't inherit from Eiffel objects; Loops objects can't inherit from Smalltalk objects. Each OO technology is a programing bunker world unto itself. This is true in practice only, of course. In theory the world is always exactly as we wish it to be. 8) What are the consequences of persistent state? Mostly it makes testing a lot harder and a lot more unreliable since every possible combination of retained state must be checked. But then, heck, an object-oriented program is so clean and clear that we don't really need to test it so who cares how hard it is, right? Have you heard of the Parnas test? 9) Can you get the development system out of the production system? Nope. The uniform response of the OO community to the runtime overhead problem is "buy a bigger machine" or, in translation, "the hardware guys will have to save our butts again". It seems to come as a shock to OO programmers that the folks buying these machines expect to be the beneficiaries of the hardware curve not the programmers ... afterall it's their money. People who buy cmoputer to solve their problems don't expect the curve to be eaten up (and then some!) by having to constantly slog through leftover development-time scaffolding. (Do you know what happens to surgeons who leave the tools of their trade inside their patients?) OOP imposes a runtime tax that end-users aren't interested in paying even with weak excuse that the tax pays for more frequent updates since it makes maintenance easier. End-users don't want more frequent updates; they want it right in the first place. The OO community will be forced to discover that software consumers won't pay development-time taxes at runtime the same way the Lisp community did. If you write your product in some OO language, I'll come out with a competing product in written C or maybe even assembler, give all those cycles back to the customer, and whip you in the marketplace. I might thank you for defining the product and opening the market which I understand you did by using OO technology. But a thank you and a cloud of dust is all you'll get. In closing, I note that a non-upward compatible version of the most popular OO language, C++, is due out "real soon now". After 11 years of trying C++ still doesn't have a stable semantics. This, more than anything else, convinces me that OOP still isn't ready for production use ... unless, of course, your boss still thinks paying her programmers for constantly changing the syntax of her code is progress. There is very little really new in OOP. As I indicated above, classes, instances, and inheritance go back to tab card decks of the 1940's. Lexical scoping was used in Algol in the 1950's. Polymorphism is found in Fortran 0. Even decomposition by type, which Piercarlo Grandi says is the basic idea of OO, can be found in the programming language, database, and graphics literature of the 1960's. The question we really have to ask ourselves is why are we constantly reinventing the wheel? Why do we imagine that making up new names for old problems is progress? Why don't we get tired of reading the same dreary articles and going to the same windy conferences? Why is the collective memory of applied computer science so short? Only when we can answer this question will programming start to make some real progress. Cheers, Scott +*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+ NET Domain: guthery@uunet.uu.net Post: 11100 Leafwood Lane COM Domain: guthery@acw.com Austin, Texas 78750-3464 USA US Domain: guthery@acw.austin.tx.us FAX: +1 (512) 258-1342 Usenet: {uunet}!acw!guthery Voice: +1 (512) 258-0785 CompuServe: 70240,221 Fidonet: 1:382/12 Packet: N5MDE @ KB5PM Prodigy: BCDG83A +*+*+*+*+*+*+*+*+*+*+*+*+* The Source of C +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+