Path: utzoo!attcan!uunet!husc6!rutgers!mcnc!thorin!coggins!coggins From: coggins@coggins.cs.unc.edu (Dr. James Coggins) Newsgroups: comp.lang.c++ Subject: Re: Current O-O Languages as Software Engineering Tools Message-ID: <5439@thorin.cs.unc.edu> Date: 20 Nov 88 03:53:26 GMT References: <5155@thorin.cs.unc.edu> <77300016@p.cs.uiuc.edu> Sender: news@thorin.cs.unc.edu Reply-To: coggins@cs.unc.edu (Dr. James Coggins) Organization: University Of North Carolina, Chapel Hill Lines: 126 In article <77300016@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu raises lots of interesting points that are worth responding to in spite of the resulting length of this posting. >Claim: (by a colleague of Dr. Coggins) > dynamic binding at run time allowed architecture and implementation > to be more independent of each other in practice, therefore the Smalltalk > model would be better for large-system development than the Simula model. johnson@p.cs.uiuc.edu says... >I agree with the first part of the statement, but C++ provides dynamic >binding at run time, so the last half is a non sequitur. I reply, Well, the semantic sloppiness of fairly casual conversation makes this a point of debate, but not a particularly enlightening one. Is C++ dynamic or not? Yes and no. My colleague was claiming that the more dynamic environment of Smalltalk impacts large-scale software engineering. My summary at the end (I'll *** it below) perhaps expresses the real issue more clearly. I wrote... >>If you prototype using Smalltalk, you adopt the Smalltalk object hierarchy >>as your architectural tools/metaphors/thought patterns. You also adopt >>the underlying implementations, but they can be thrown out or redone >>later. By adopting the Smalltalk environment, you might be >>starting off your architectural design effort by putting on a >>straitjacket and blindfold. Anything works for small projects. For >>large projects the fit of mental models, architecture, and language >>abstractions needs to be tighter in order to manage and control the >>project. I believe that this fit can be made tighter by designing >>abstractions (classes) to fit the project, not twisting the mental >>model to fit a predefined hierarchy. This is the '80's version of the >>top-down heuristic: >> Let the implementation conform to the conception. > johnson@p.cs.uiuc.edu commented... >There seem to be several misunderstandings of Smalltalk here. Smalltalk >certainly does not force anyone to use existing classes. People use them >because they are well designed. I (the establishment iconoclast) respond... That's a correct Party Line response that is meaningless in practice. This is exactly the kind of conventional wisdom that should be examined more carefully. Each of these classes in the Smalltalk architecture comes with an implementation bound up with it. Part of the price you pay for using Smalltalk is the tacit adoption of those implementations along with the nice architecture. johnson@p.cs.uiuc.edu commented... >It seems to me that you are arguing against reuse. [Who, me?] I find that hard to >believe. [Me too.] It is very hard to write reusable code, and trying to reuse >code that is not reusable is no fun. However, it is possible for code >to be reusable, and Smalltalk is an example. Smalltalk programmers reuse >code because that is the easiest way to develop a high-quality product. My argument is not against reuse but against the proposition that the mechanisms we currently have available (even in Smalltalk) are sufficient to support any meaningful code reuse - enough to make a lead bullet if not a silver one [see Brooks' IEEE Computer cover article, April 1987]. Instead, the existing mechanisms require the reuser to adopt conventions and implementation assumptions that may or may not conform to the reuser's conception of the task at hand. We have basically no mechanism other than complete rewrite for exchanging implementations within an architecture. (Unless you want to try to bring in "executable specifications", perhaps.) To enter Silver Bullet country we are going to require mechanisms that are foreshadowed by OOP but that allow a yet-higher level of abstraction. [and I have no axe of my own to grind - this is not my principal research area] >I claim that no good >designer is going to find a class hierarchy a straight-jacket, because if >it is not working then it will be changed. I am a good designer (only a fair implementer, though), and I found the Smalltalk hierarchy restricting when I needed to implement large objects like images and 3-D graphics models. I wasted time trying to fit what I needed into what Smalltalk provided. This may shock some people, but here it is... Smalltalk is NOT the Ultimate Software Engineering Environment! >In a couple of years C++ will have just as large a class library as >Smalltalk, maybe larger. Lots of companies are already developing their >own. Nobody will force you to use them, but the high-quality libraries >will have lots of users. You must be at a university, too. A more hard-nosed business attitude would hold back on the enthusiasm until mechanisms appear for USING what somebody claims to be "good" classes. The C++ folks are working on the problem (and good luck to them!). >There should be much, much, much more reuse in software systems. We don't >keep inventing new abstractions for arithmetic, why should we be doing it >for everything else? Because there is no "implementation" for arithmetic, of course! Computer stuff is bound to implementations requiring engineering decisions concerning tradeoffs of time/space, compilation effort/run-time support effort, etc. **************************************************************** >>The question is whether the flexibility in the type system afforded by >>late dynamic binding is ultimately an advantage (by virtue of its >>additional support for abstracting architectures independent of >>implementations) or ultimately a disadvantage (by delaying detection >>of errors and in fact not detecting as errors some things that in fact >>are errors). **************************************************************** >One of the purpose of a type system is to detect errors at compile-time. >A type system for an object-oriented language, for example, should >prevent any "message not understood" errors at run-time. I don't see >why late binding itself prevents the detection of errors. As I said >earlier, C++ virtual functions provide late binding, and the type system >for C++ ensures that an object understands the messages sent to it. Smalltalk people tend to think that this characterization of late-binding is itself a straitjacket! --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department Old: Algorithms + Data Structures = Programs UNC-Chapel Hill New: Objects + Objects = Objects Chapel Hill, NC 27514-3175 ---------------------------------------------------------------------