Xref: utzoo comp.object:475 comp.lang.c++:5633 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!xanth!mcnc!rti!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.object,comp.lang.c++ Subject: Re: Guthery slams OOP in latest DDJ Summary: well, he takes a swipe, but spends most energy shredding straw men Message-ID: <0220@sheol.UUCP> Date: 22 Nov 89 21:48:47 GMT References: <2664@bingvaxu.cc.binghamton.edu> <2666@bingvaxu.cc.binghamton.edu> Lines: 139 > cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) > I'm not an OOP programmer, but I read a real convincing argument in the > latest Doctor Dobb's Journal #158, "Are the Emporer's New Clothes Object > Oriented?", pp. 80-86 by Scott Guthrey. [...] > Any comments? > [... rebuttals omitted ...] > Well, this seems to be a consensus. Does *anyone* support *anything* > Guthrie says? Sort of. He makes a couple of good points addressed towards current *implementations* of OOPLs, but has trouble even coming close towards the broader side of the barn, that is addressing the general notion of object-oriented program construction as an abstract method. I'll address his points as laid out in the sections of the article: - Where's the Evidence? [..for productivity increase..] Guthery piles up some assumptions and points to some studies showing little or no gain in productivity. Yet I've seen dozens of measurements showing that OOPLs result in equivalent functionality with fewer lines of code, and with shorter debugging times. I made such a small study myself (though admitedly, my OOPL wasn't really one, lacking inheritence... nevertheless). OOPLs aren't the silver bullet, but I'd say there's plenty of evidence that they aren't chopped liver, either. - What is an Object? Guthery's explanation of what an object is "stripped of all the jargon" is so far away from accuracy that it is hard to point out just where his analogy IS accurate. Mainly, it is accurate in code locality and the association of multiple names for operations. The analogy he presents fails in most else, and yet these other points are what he associates with OOPLs, and condemns them for. MOST bogus. One of these, the "persistence" point, is addressed in more detail later by Guthery, so I'll address it in more detail there also. Here I'll just say that characterizing the specification of the operations available on an object as "multiple entry points" is as blatantly misleading as anything I've ever heard. And I've heard some doozies. - What's the Cost of OOP Code Reuse? Having claimed that things in OOPland haven't been measured in the "Where's the Evidence?" section, Guthery nevertheless ploughs ahead and makes bald unsupported statements such as "Your system will be bigger, run slower, and cost more to maintain than with subroutine- style reuse." Where is the evidence of this, other than Guthery's handwaving? It runs counter to my experience. - How to Combine Object Heirarchies Breifly, the examples he gives of this are bogus, and are better represented as objects containing other objects as part of their state rather than of examples inheritence. So the answer to the question of "how to combine object heirarchies" is "certainly not the way Guthery recommends or imagines it to be done". - How to Tune an Object-Oriented Program? Here the issue of monitoring and debugging OOPLs is butchered. It is true that some OOPLs are worse off than some procedural languages as far as debugging and monitoring tools, C++ in particular having debugging problems. But this problem is not universal, and many of the performance problems Guthery attributes to OOP methods are in fact generic code re-use problems. For example, "the performance problem may be in the code of a class you didn't implement", which is the same as objecting to the use of the standard C libraries because they might contain some slow routines that could be bettered. If a given class from a library is too slow, fix it (if you own or control the owner of the library), negotiate to get it fixed (if you can negotiate with the owner), or create your own class with equivalent interface. These are the same options open to somebody who finds that (say) qsort(3) is a bubble sort in some unfortunate instance of the C library. So, while C++ may be somewhat hard to debug and monitor, this is primarily because the most common C++ compiler (cfront) produces no persistent debugging database for any debugger or monitor to use. In cases where this problem doesn't exist (eg: G++ and gdb, or SmallTalk systems), debugging and monitoring facilities are excellent. And of course, the side-issue of the Intel 432 is NOT a slam on OOP methods. I've seen many convincing analyses of why the 432 was slow, and it was NOT because of OOP. - Do Object Oriented Programs Coexist? Here Guthery makes one of his near-approaches to sense. OOPLs, because they hide their data representations, can make it arbitrarily hard to co-exist with other OOPLs or even other procedural languages. Yet these problems aren't problems of an OOPL, they are problems of ALL languages where the language system takes extreme pains to keep control of data formats and releive the user of housekeeping chores. For examples Lisp systems (or in general, systems with extreme garbage collection). Yet even in these systems, it is not universal that they cannot deal with foreign language systems (DG Lisp for AOS/VS is the case I'm most familiar with in this regard). And, of course, C++ can deal with foreign code quite well. - What are the Consequences of Persistent State? The argument here is silly. Objects have state no more persistent than primitive datatypes. Guthery's argument is like complaining that a record type representing a symbol-table node is an evil thing, because it contains persistent state. The state is no more persistent than the object itself, and might well be automatic, and well scoped indeed. As mentioned above, this whole argument is based on the idea that objects are "really" groups of functions with a single instance of shared data of process persistence. This is simply not the case. - Can You Get the Development System Out of the Production System? Here Guthery makes the nearest approach to sense that he manages. But again, this is not a problem with OOPLs, but with all languages with extensive and interdependant libraries. Lisp systems are particularly vulnerable to this, because references to parts of the system can easily be discovered only as late as runtime. SNOBOL systems also. So again, the problem of "applications delivery" as I've heard it called is simply not a problem of OOPLs in general, (for example, it isn't much of a problem in C++, really). It is more of a problem of systems that blur the distinction between compile-time and run-time (that is, interpretive systems). So, to sum up, Guthery is simply missing the point most of the time. His faulty analogy has led him on a wild goose chase after purported problems with OOP with are really problems either with his mistaken analogy, or with some (but not all) OOPLs. So, put it this way. The Baby: OOP as a method of design and implementation. The Bathwater: Some insular or immature OOPLs. It just doesn't make sense to throw out the former while changing the latter. -- Wayne Throop !mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org