[Edu-sig] Now I went and did it.
Sun, 08 Oct 2000 11:00:49 -0700
>Which is among the reasons I remain devoted to the concept of introducing
>programming via Python - and despite my (considerable) frustrations on the
I appreciate your staying with it.
Thanks again for alerting me about that O'Reilly write-up of my work
Subsequent to my citing it here on edu-sig, I got email from
Shriram Krishnamurthi, one of the chief Schemers (has authored or
co-authored a lot of curriculum writing). She wrote, in part:
I can never tell how to appropriately applaud your work.
In the process of your extremely laudable efforts at
educating people about math, you'll end up miseducating
people about computer science.
But I guess you don't really care about that...
Seems there's still some bitterness about Python making any inroads
at all into education, which has been the focus of TeachScheme! for
much longer (the python.org edu-sig web page has long linked to it 
-- I haven't found any reciprocal links going the other way though).
The "competition" between myself and the Schemers isn't very real
however. TeachScheme isn't trying to interest K-12 math teachers
in using a command line interface (CLI or REPL) to communicate
math concepts. If it were, I'd have seen lots of posts to the
Math Forum, e.g. to k12.ed.math or to math-teach. But there's
nothing. I sense no real overlap in our efforts.
Anyway, I spent some hours since Shriram's email refamiliarizing
myself with Scheme (RScheme to be specific) and going further into
it. I see some commonalities with Python, in particular the
abstraction of thinking of all names as pointers to objects,
including names of functions, which may be passed as parameters
to other functions.
If you master lambda, filter, apply, reduce, zip and map (I may
be forgetting some) in Python, you'll have some transferrable
understanding I think, as these features inherit from the same
"functional programming" background that Scheme does. This ability
to make "function factories" will build procedures using lambda
and passed parameters is something Python can do as well.
So my thinking is learning Python is not going to hurt you when you
later tackle Scheme (if you do). Plus it contains a lot more of
the conventional imperative language structure, plus a lot of OO,
which the various flavors of Schemes don't all implement (having a
class hierarchy with inheritance is different from the 'everything
a referent to an object' abstraction). So Python is a better
waystation to Java (and C++) than is Scheme IMO.
I continue to have the impression (I think it's more than a mere
prejudice, as I've been doing some studying) that Scheme is more
academic and less interested in venturing into the rough and tumble
world of writing to sockets, encryption, XML, unicode, working with
various kinds of GUI widget, than is Python. There's a difference
between being extensible in principle, and actually having all those
libraries ready for download *now*. But I haven't studied the Scheme
Repository in much detail yet, and am willing to have my mind
expanded. The more the merrier.
I am not a huge fan of recursion as the greatest way to do anything
looping. It's cool, but these recursive-wherever-possible languages
feel like one of those situations in which you've taught your dog
to roll over, so now you make your dog roll over and over and over
-- to the exclusion of all other tricks. How impressed should we be?
This is more a prejudice I realize -- shared by many who didn't cut
their programming teeth in the LISPish world, where recursion is god.
So, I hope I haven't started a language war. I'm still of the opinion
that Scheme is a great technology, but that it's not either/or. Scheme
isn't very actively competing in the area I'm looking at, and learning
Python early isn't going to "ruin you for Scheme" if you decide to
tackle that one too, perhaps down the road, when you've decided that
computer science is going to be a central focus ("computer programming
for everybody" or CP4E involves sharing programming savvy with folks
who will _not_ be making that decision).