Xref: utzoo comp.lang.c++:8880 comp.software-eng:4038 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!dali.cs.montana.edu!rpi!image.soe.clarkson.edu!news From: cline@cheetah.ece.clarkson.edu (Marshall Cline) Newsgroups: comp.lang.c++,comp.software-eng Subject: Re: Project experience with C++ Message-ID: Date: 8 Aug 90 21:01:25 GMT References: <812@agcsun.UUCP> <222.26a42b7d@astro.pc.ab.com> <13038@yunexus.YorkU.CA> <294.26b56ac2@astro.pc.ab.com> <1030@pi19.pnfi.forestry.ca> <350.26bd5757@astro.pc.ab.com> Sender: news@sun.soe.clarkson.edu Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline) Organization: (I don't speak for the) ECE Dept, Clarkson Univ, Potsdam, NY Lines: 61 In-reply-to: klimas@astro.pc.ab.com's message of 6 Aug 90 16:41:11 GMT In article <350.26bd5757@astro.pc.ab.com> klimas@astro.pc.ab.com writes: >The >Smalltalk class library provides a good library of examples of how the >C++ classes might be organized for a particular function. The best C++ >programmers I know learned OOP from Smalltalk initially and then >transfered their experiences to C++. Unfortunately I must disagree with both statements. [1] ``Smalltalk class library provides good library of exampoles of how the C++ classes might be organized'' The Smalltalk class library was designed for Smalltalk. It is entirely runtime typed (which is appropriate for Smalltalk), uses inheritance as an implementation mechanism sometimes at the expense of type conformance (again, ok for Smalltalk, lousy for C++), and it is a singly rooted tree (necessary for Smalltalk but introducing unconstrained polymorphism into the container classes which weakens or destroys type safety in C++). Although the NIHCL (C++) is a successful product, using it requires pointer coersions (which I believe to be the OOP moral equivalent of a `goto'), and it suffers from some of the above problems as well. For example, it is impossible for anything to `be-a' Set without containing a hash-table (this is another non-issue in Smalltalk where you can totally change the type and/or function of inherited member objects). [2] ``The best C++ programmers I know learned OOP from Smalltalk initially'' I've heard this marketing hype too (from companies that specialize in Smalltalk training). I've found that Smalltalk programmers have just as hard a time adjusting to C++ as do Pascal programmers. Their struggles are entirely different (Smalltalk programmers have to get used to strong typing, for example), but Smalltalk programmers have certain initial concepts which are entirely wrong for C++. The purpose of inheritance in C++ is different than in Smalltalk (C++ provides both private [mechanism_only] inheritance and public inheritance [mechanism + type_conformance]; Smalltalk has only one form [would muddy type-conformance in C++], plus Smalltalk doesn't even require you to inherit mechanism, in the sense that you can change the superclass). ------ Before I step into my flame retardant suit, let me mention that I'm not down on Smalltalk or its library *AT* *ALL*!! I just believe the supposed easy transition from Smalltalk to C++ is a myth. I've recently had to rescue a fairly large C++ project (over 14 million of lines of code in the previous language) from the mentality that you can squeeze Smalltalk methodology into C++. For them (and for anyone programming-in-the-large, I believe), type safety is essential. Marshall Cline -- ============================================================================== Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600 Career search in progress; ECE faculty; research oriented; will send vita. PS: If your company is interested in on-site C++/OOD training, drop me a line! ==============================================================================