Thanks. Kirby's is an interesting response with which I basically agree. Those of us who learned programming when the model was close to the machine model (Fortran, C) have had a hard time wrapping our heads around objects.
A good friend whom I very much admire has argued (this was per-Python so I am not sure whether he stands by this) that OOP is for experts and shouldn't be foisted on beginners at all. I have seen the consequences of premature stress on OOP; supposedly professional programmers writing gobs of Fortran-like code in Java; great hulking monstrosities of procedural code wrapped in "public static void main" for bureaucratic reasons, to convince javac to allow the fortranlike code through. The blame goes to the instructor who did not manage to understand what advantages the object model brings to the table at all. The resulting Java code provides the worst of both worlds: all the overhead of OOP and Java with none of the advantages. Python's gentle introduction to objects makes the distinction between procedural and OO approaches visible gradually. You don't have to **explain** the concept, which is very difficult lacking the experience. The usual examples of a car is-a vehicle and a car has-a motor seem utterly pointless, and yet abstractions which actually add substantial value are not easily seen by people who haven't felt the need for them. With Python you aren't left in a position of trying to explain the benefits of OOP after people have developed non-objecty habits and ways of thinking, nor before they have a need for the abstractions that you enforce. The veil is lifted gradually, at the right time and in the right measure. This is a remarkable feature. It strikes me that this ties in with something Ian Bicking once blogged: "This is often how I feel about object-oriented programming, and somewhere where I think Python's imperative approach is a real feature. Starting on an application by building objects (or doing "whole design") is a bad idea, unless you know the domain well. It's better to get it doing what you need to do, and think about objects along the way. Somewhere you'll notice you keep passing around the same value(s) to a set of functions -- those set of values are "self", and those functions are methods. You'll find ways to split things into modules, etc. Designing objects and modules too early and you'll have lots of circular dependencies and poor metaphors. Of course, you can fix all those, but it's easier to add structure to a naive project than to reshape and restructure a misdeveloped project." The similarity between these arguments is striking, even though they are aimed at very different groups of code developers. Which leads to another argument in Python's favor; the continuity of approach between very small and very large projects, and between very simple and very complex goals. The fact that we can offer a language to beginners which has some traction as vocational training is something of a mixed blessing if we think computer programming is "for everybody", but the fact that Python is not a "training wheel" language. Without compromise, itt supports the entire range of activity from casual dabbling all the way to the most sophisticated abstractions. This, I think, is unique. mt _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
