Which is among the reasons I remain devoted to the concept of introducing programming via Python - and despite my (considerable) frustrations on the EDU-SIG list.
ART
I appreciate your staying with it. Thanks again for alerting me about that O'Reilly write-up of my work at http://www.oreillynet.com/pub/a/python/2000/10/04/pythonnews.html 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: Gee, great. 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 [1] -- 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). Kirby [1] http://www.python.org/sigs/edu-sig/