[Edu-sig] Python in Education Advocacy Article

[Michael Tobis]

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