Not a lot of new stuff in here, but I am pleased to see that in most respects Coplien's approach is similar to the one used in the course I run. ADTs and abstraction first, only than inheritance and polymorphism. Put the emphasis on interfaces early, and keep hammering it in.
But I don't know that I agree with the author that one should teach "objects" before one teaches "classes". That's like asking whether one should teach data structures prior to teaching programming.
From the article:
The CS department is driven to a large degree by input from an industry board. That board conveys pressing industrial needs, and we respond. We add formal foundation courses to round out the collection of courses. So in the interest of giving students something practical and current, I knew that both Use Cases and CRC cards would figure strongly in the material.
Hear that strange, unearthly squeaking sound? That's E. W. Dijkstra, up there in computer science heaven, grinding his indestructible angel-teeth together.
Coplien's C++ book is very good, and I'd like to hear more about his ethical/methodological differences with academic computer science. Does he feel that "input from an industry board" should be a driving force behind the shaping of courses taught in CS departments? It's widely accepted - to a greater or lesser degree - as a pragmatic necessity; but I guess a lot of people still think of it as a necessary evil...?
Real-life object-oriented systems, Soren Lauesen
Object-oriented systems in real life. Case study details and observations
I don't think the theory vs. practice dichotomy makes sense in CS....What's the old quote: "In theory, theory and practice are the same".
I take it you come from the theory side. Running and ducking for cover. :-)
The line you quoted is most often used by me when I want to criticize theoretical CS...
I completely agree. Generally speaking, I find theoretical CS about as useful as theoretical carpentry. To do their job programmers need tools. Programming languages are just one of those tools and it is a classic mistake by the more theoretically inclined to focus exclusively on languages. In the every day world of programming, IDE痴 (editors, debuggers, profilers, etc), GUI builders, and libraries are every bit as important as the core capabilities of a language. In fact it could be argued that they are of equal importance (though I am not sure that I would argue that).
For what it痴 worth here is my ideal tool set: Common Lisp as the language, VisualWorks (Smalltalk) as the IDE, Flash MX for the GUI, and a set of libraries like Perl痴.
Cheers.