Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!mcnc!thorin!alanine!coggins From: coggins@alanine.cs.unc.edu (Dr. James Coggins) Newsgroups: comp.lang.c++ Subject: Re: Current O-O Languages as Software Engineering Tools Message-ID: <5358@thorin.cs.unc.edu> Date: 16 Nov 88 14:05:46 GMT References: <5155@thorin.cs.unc.edu> <77300015@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: 103 In article <77300015@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > >> > 2. Smalltalk-like languages are better tools for developing small >> > programs because of their massive built-in class libraries and their >> > more flexible (later, dynamic) binding which allows polymorphic types. > >I understood Jim Coggins to be saying that he thought that C++ DID have an >inherent defect that prevented the large class libraries from being created. >I don't really understand what it is about C++ that he thinks causes this, >nor am I convinced that C++ has any fatal errors in this regard, but that >was his claim. Hold it - nobody move! My list of propositions was a summary of an hour-long discussion with someone not on the net primarilyly reflecting my colleague's main points. (I said something like that in the first line of my posting, BTW.) I will see him again in a couple of weeks and I'm hoping you net.experts can tell me how to demolish his argument. We were having a C++ vs. Objective-C debate, and he was claiming that the biggest hindrance to using C++ on large projects was that C++ inherently binds an implementation to your architecture. His claim was that 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. Bjarne Stroustrup gave me lots of ammo to fire at his propositions and his logic. I'm still going through that long paper so I haven't responded yet. I am not aware of any inherent defect in C++ that would prevent C++ from being usable on large projects, but my colleague's logic seems plausible so I posted his ideas to see who shot at them. It drew out the big guns, huh? >My experience is that Smalltalk is better for prototyping a design, but >that once it is finished it doesn't matter that much which language you use. This is the conventional wisdom. Since I like to challenge conventional wisdom, let me offer this counterargument. 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 (if you have strong personal and professional discipline - see my .sig). 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. My colleague thinks that dynamic binding results in an advantage in abstraction that will make Smalltalk-like systems better tools for large projects. I didn't buy it in our discussion then, but I was unable to marshall a good argument. Now I know how to approach the issue. Bjarne once said, "C++ is not Smalltalk." Hear!Hear! >The reason that Smalltalk programming environments are so good is the same >as why Lisp programming environments are so good. Programmers can access >contexts and classes from inside Smalltalk so they can easily write >debuggers and browsers. A similar system for C++ will require a lot of >interaction with the operating system, which will be more complicated and >less portable. Thus, making a nice programming environment for C++ is >a harder job than making one for Smalltalk, so it will take longer. Hey, there's a general rule that applies: interpreters yield better programming environments than the compile-edit-run cycle because they are virtual maching simulators, and you can cause that virtual machine to help you out in any way you can define. So who will be first out with a C++ interpreter? >Smalltalk certainly has some faults when it comes to building large >systems, primarily in its support for mulitperson projects, but I think that >Dr. Coggins was speaking of "Smalltalk-like" languages (whatever that >means) and not Smalltalk itself. Um, I plead guilty to necessary oversimplification. In doing so, I leave to respondents the selection of what more specific aspect they wish to address. Bjarne did exactly that, for which I'm grateful. >My type system for Smalltalk is much more flexible than the one for C++. >I am curious about Dr. Coggins's explanation of why C++ is not as good >for reuse, and wonder how types fit in to it. 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). --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department Working code is EXTREMELY valuable. UNC-Chapel Hill That's why it's hard to throw out Chapel Hill, NC 27514-3175 ditzy prototypes. ---------------------------------------------------------------------