Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!rutgers!mcnc!thorin!coggins!coggins From: coggins@coggins.cs.unc.edu (Dr. James Coggins) Newsgroups: comp.lang.c++ Subject: Re: Smalltalk-80 like inheritance in C++ possible ? Message-ID: <7431@thorin.cs.unc.edu> Date: 27 Mar 89 15:08:24 GMT References: <110@honold.UUCP> <5481@rlvd.UUCP> <1411@sw1e.UUCP> <9174@claris.com> <1421@sw1e.UUCP> <1335@blake.acs.washington.edu> Sender: news@thorin.cs.unc.edu Reply-To: coggins@cs.unc.edu (Dr. James Coggins) Organization: University Of North Carolina, Chapel Hill Lines: 105 In article <1335@blake.acs.washington.edu> keffer@blake.acs.washington.edu (Thomas Keffer) writes: > >What to do? It seems to me there are 6 main _PRACTICAL_ problems now > >1) Poor quality compilers. You never know if it's you or cfront. >2) Few gurus. >3) Few "known correct" examples of non-trivial code. >4) Only two books, neither of them very good. >5) Few precanned, bulletproof classes. >6) Steep learning curve, especially to learn writing new classes. Assuming that being a "Computer Scientist" has not become anathema in this community, I'll respond. C++ has caught on so quickly that the community has gotten ahead of the normal language (and environment) development process. Thus, your complaints 1-5. We're working on it. The language is evolving (and in particular, C++ Version 2 is in beta test now, so I hear), so those of us who are computer scientists whose lives are indeed intertwined with this programming language and who could serve as gurus and authors of superior textbooks are frozen -- we can't publish great educational material based on Version 1.2 since it would be obsolete before the first copies came off the press. Nevertheless, I am preparing to release my C++ class library next month, which you will find to be "in regular use, believed mostly correct, highly nontrivial code". And apparently written in an idiom that does not encounter many of the difficulties I keep reading about in this newsgroup. (When people have come to me asking about how to do some weird thing in C++ I usually have found there to be fundamental design idiocies. Correcting them made the weird thing unnecessary.) Stroustrup's book is fine, but its objective was not to serve as a tutorial; it does not address the objective you seek. The other book I have seen was intended to be a tutorial; it is just poor. "Precanned, bulletproof classes" as are commonly practiced (well, attempted) in this community are probably not such a great idea in general, anyway. Application-area-specific sets of class hierarchies aiming at encapsulations of rather large concepts relevant to the application area are probably a better way to build meaningful, reusable classes than the Single Monolithic Hierarchy (like Smalltalk and the NIH classes) and are certainly better than building a house from grains of sand (like building "stack" and "linked list" and "hash table" classes and then applications atop them -- yech). >Of these, 1 through 5 will eventually go away. 6 never will. Ridiculous. Maybe my advantage is that I never learned C before learning C++. The concept of "class" is so intuitively appealing that it improves program design immediately. Maybe you need some more useful examples? Learning C++ with an experienced guide does not take long at all. I have demonstrated this fact by teaching portions of my class hierarchy and its use in three lectures plus several example programs. It was not easy, but we did it. Students were writing programs using the classes in rather sophisticated ways within a week. True, they were not writing new classes themselves, but several asked about how to do it and in fact did it, starting by modifying some of my classes. I think people are looking a learning UNIX/C through rose-colored glasses. I have not found sockets and interprocess communication to be so trivial. Neither have I found SunView or X to be trivial. Neither is the Smalltalk class hierarchy or its environment trivial. C++ is not trivial, but with a careful and correct presentation, it's easier to follow than some of these other systems. Teaching C++ to Pascal programmers is a bit easier than teaching it to C programmers, I think. Pascal programmers have a more well-developed aesthetic sense and resonate better with C++ concepts. Even then, the presentation must be carefully designed so that people think about programs differently and don't just pick up a new hammer (and therefore see the world as a collection of new-age nails). The same kinds of cries arose from software developers in client disciplines when Structured Programming was the rage in the late '70's. "What are those computer scientists doing?" "Why not leave well enough alone?" "I went to one of their meetings and they were arguing about such trivia that I just walked out." "If it ain't broke don't fix it." And the ever popular, "Why should I care about this new development? I can do everything I want to do in FORTRAN." To summarize: We computer science folks are aware of the problems. Many of us are waiting for C++ Version 2.0 before releasing our contributions since they'll all change then anyway. Whether the ideals of "code sharing" should be implemented by a single monolithic hierarchy, a collection of small implementation classes or as hierarchies fitting concepts of the application area (my preference!) is still open for debate. C++ is different, but there is no reason to believe that learning and using C++ will be any more difficult than learning a few new features of UNIX/C. >--- > Dr. Thomas Keffer | Internet: keffer@sperm.ocean.washington.edu --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department UNC-Chapel Hill Old: Algorithms+Data Structures = Programs Chapel Hill, NC 27599-3175 New: Objects+Objects=Objects and NASA Center of Excellence in Space Data and Information Science ---------------------------------------------------------------------