johnson@p.cs.uiuc.edu (03/29/89)
I'd like to argue with James Coggins. I've been building systems in Smalltalk for 4 years and in C++ for 3, so I can talk about both. >"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). Smalltalk does not provide a Single Monolithic Hierarchy. It is true that all classes are subclasses of Object, but that is not saying much. The Smalltalk class library provides a bunch of hierarchies, such as Number, Collection, Stream, View, Controller, and DisplayObject. Programmers build their own, application specific hierarchies. There is absolutely no doubt that application specific sets of class hierarchies are more valuable to those who need them. For one thing, application independent abstractions are pretty rare. However, most companies won't want to share their application specific class hierarchies, while they are more likely to share the application independent ones, so we are more likely to see those. Also, computer scientists often have the mistaken belief that applications are beneath their dignity. B-trees have more prestige than a framework for accounting. Thus, people are more likely to work on the more general abstractions. However, the big money is going to be made with application specific class libraries. These libraries are going to encode design knowledge that companies can use to teach their next generation of designers. They will enable companies to build systems largely out of existing, tested, well-understood components. I agree with James Coggins that object-oriented programming is not that difficult to teach. I teach it using either C++ or Smalltalk. Large class libraries take a long time to teach, but object-oriented programming itself does not. The operating systems course here uses C++ in the labs, and we have classes for that various parts of an operating system. Students pretty much learn to read the code on their own. They modify classes, but don't ever need to design a class library themselves. The course works well. All programming is hard. I'm teaching FORTRAN to engineering students this semester, so I am being reminded of that. It is easy to learn a new language that is isomorphic to one you already know, but it can be hard to learn a new programming style. I can remember the shock I had when I first learned functional programming. It took me almost two months to figure things out, and I was used to learning a new language in a week or two. Object-oriented programming is different from conventional programming, but it isn't harder to learn than any of the other styles. I've found that graduate students who know several different styles (i.e. Pascal, Scheme, Prolog) can pick up Smalltalk in a couple of weeks, while those who only know Pascal/C/FORTRAN have a bit more of a culture shock. Ralph Johnson