Xref: utzoo comp.object:458 comp.lang.c++:5604 Path: utzoo!attcan!uunet!mailrus!shadooby!egrunix!nucleus!dar From: dar@nucleus.UUCP (Dario Alcocer) Newsgroups: comp.object,comp.lang.c++ Subject: Re: Guthery slams OOP in latest DDJ Summary: Scott makes some good points... Message-ID: <5489@nucleus.UUCP> Date: 21 Nov 89 19:45:22 GMT References: <2664@bingvaxu.cc.binghamton.edu> Organization: The Nucleus Public Access Unix, Clarkston, MI Lines: 100 In article <2664@bingvaxu.cc.binghamton.edu>, cjoslyn@bingvaxu.cc.binghamton.edu (Cliff Joslyn) writes: > > 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. > > [text deleted -- d.a.] > > And more: "...the programmer is invited to pass the cost of expedience > onto the user of the system. This wholesale sacrificing of runtime > efficiency to programmer's convenience, this emphasis on the ease with > which code is generated to the exclusion of the quality, usability, and > maintainability of that code, is not found in any production programming > environment with which I am familiar. Let's not forget the Intel > 432...which was OOP in silicon, and it failed because it was just too > slow. If we couldn't make OOP efficient in hardware, why do we think we > can make it efficient when we emulate it in software?" > > And the conclusion: "OOP runs counter to much prevailing programming > practice and experience: in allocating and controlling software costs, > in modularity, in persistent state, in reuse, in interoperability, and > in the separation of data and program. Running counter to the > prevailing wisdom does not, of course, automatically make an innovation > suspect but neither does it automatically recommend it. To date, in my > opinion, advocates of OOP have not provided us with either the > qualitative arguments or the quantitative evidence we need to discard > the lessons painfully learned during the first 40 years of programming". > > Any comments? > > O-------------------------------------------------------------------------> > | Cliff Joslyn, Cybernetician at Large, cjoslyn@bingvaxu.cc.binghamton.edu > | Systems Science, SUNY Binghamton, Binghamton NY 13901 > V All the world is biscuit shaped. . . After reading the article, I initially thought that the article was a slam against OOP, but after I thought about what Scott said, it seems to me after some reflection that much of his critism concerned the current _implementations_ of OOP. What I liked about the article was that it took a critical look at OOP, and hopefully now some the drawbacks to current implementations of OOP can be addressed, remebering that OOP should not be a panacea but used when appropriate. I did have some observations about what he said about object heirarchies: "The unit of reuse in object-oriented programming is the heirarchy. It is the heirarchy and not the object that is the indivisible whole. Unlike a subroutine library where you can just take what you need and no more, in object oriented programming you get the whole gorilla even if you just wanted the banana." -- Scott Guthery I think this could definitely be the case under some implementations, where the link stip is static, done before run-time. In this case, unused methods are still included, even though during run-time you may not use them. People have seen this happen, I believe that the 'linker' that comes with Turbo Pascal 5.5 tries to strip unneeded methods while making the binary executable. However, I think a better approach is already possible. Provided module granularity is sufficiently fine to increase performance, unused methods could be kept on disk, being paged in as needed, and if their use during run-time decreases, could be paged out. This can be done today in OS/2, Windows, and any other OS that does paging at run-time. However, it seems to me (correct me if wrong) that this paging will have to OOP sensitive to be effective, and I don't know enough if this mechanism could co-exist with preexisting software that is not OOP-developed. It is being looked into, witness the anouncement of a new memory-management sytem developed for Quattro Pro by Borland, called VROOMM (Virtual Real-time Object Oriented Memory Manager) that uses an LRU algorithm to keep most frequently used objects in RAM. Related to this, Scott also had some observations about performance-tuning OOP systems, where he related the ineffiency of OOP systems to that of the Intel 432 project. I think there is one difference between software and and firmware; firmware is usually needs to be pretty static, while software has the necessary environment to be more dynamic in its use of primary and auxiliary memory. I think the key here and debugging OOP-based systems is that our run-time environment will have to change in order to actively support OOP systems. In terms of debugging, the OS will have more flexible in the handling of run-time errors, and will have to give the developer more information about the state not only of the machine, but of the OOP system as well; its like the next logical progression from assembly-level debugging to source-level debugging, to (now) object-level debugging. In summary, I think that the OS, or operating environment, will have to change to allow OOP to be used effectively. What we have seen now is really only a change in languages and development tools; what we need now are operating environments that actively support OOP systems, while providing the performance user demand and the control developers need. Hasta... Dario +===============================+==================================+ | Dario Alcocer (San Diego, CA) | Internet......dar@nucleus.mi.org | | via Nucleus | phone...............619-450-1667 | +===============================+==================================+