At 12:00 PM 10/10/2000 -0500, Matthias Felleisen wrote:

Kirby ..

The goals of TeachScheme and your goals are similar, not the same. We want to bring programming to mathematics and (here is the diff) "mathematics" to programming. (Watch the quotes before you flame. They mean something.) If you succeed, I am happy. It's an improvement over what we have in schools. Indeed, if you succeed, we don't need Scheme.

Under no circumstances would I want my success to mean "we don't need Scheme". That whole branch of the language family embodies a valuable a meme pool (lots of good ideas) and needs to keep evolving. As for bringing "mathematics" to programming, I assume you mean the uncompromising, logical core of Scheme. That's partly what makes the learning curve a bit steep, at least initially (I've seen some of your excellent teaching materials, accessible to kids, but inevitably some will want to skip over cons, car and cdr before diving in). Likewise, some teachers will inevitably be scared off by prefix notation and the heavy use of recursion, or, if not scared, will simply choose not to go there initially. Python may be presented in such a way as to keep those doors open. It can serve as a stepping stone to Java, certainly, but also to LISP, Scheme or even Haskell (and of course it's also an end in itself, not just a way station, like any mature-enough language).

You also write:

...

and that's knowledge you can intelligently build on, not dismiss as irrelevant or (worse) incapacitating.

I don't know what this means. I didn't dismiss Python and your idea of teaching in middle schools. We have done it and I wrote a note on our experience.

This was more in in response Shririam's feedback, after that positive review of my curriculum writing at the O'Reilly website:[1] 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...

I believe that TeachScheme is a better vehicle but I wish you luck.

-- Matthias

It's not really an either/or proposition in my book. In any case, I'm interested in designing for interoperability. Kirby [1] http://www.oreillynet.com/pub/a/python/2000/10/04/pythonnews.html

Scheme will stay around, don't worry. I meant Scheme in middle schools.

Glad to hear it. But even in this narrow scope, it don't see it as an either/or proposition. Schools should continue to evolve multiple approaches. If Python makes more inroads, this is not necessarily at Scheme's expense.

I am happy to see that you have read some of our material. But if you had read it far enough you would see

- that car and cdr never occur in the book

The book I mean is one you wrote, where you have two columns, with the answer on the right (you cover it with your hand or a piece of paper, and answer questions mentally, before sliding the paper down and checking your answer). I was pretty sure car and cdr were covered in that book. If not, I'm surprised that memory fails me. Also, I'd think you'd _want_ to cover car and cdr when approaching programming in Scheme (one reason I provided "emulations" of those functions in recent posts -- essentially the same as Python's List[0] and List[1:], although of course we're not talking about proper vs. improper lists as formed from cons pairs (that's an abstraction more specific to the LISP family)).

- that recursion is explained as the control structure that matches data def

I recall something about a dog chasing it's own tail, but maybe that was a different book. Here's something else from private email (a judgement call, when to share more publicly, I realize -- I try to be constructive and keep the conversation rolling). This from a teacher at a nearby high school (he has a fair amount of programming experience, though not with Scheme -- nor any with Python): I was hoping that Scheme would be a good intro to other Languages, mainly JAVA. Since I am moving through the material with the kids, we are all somewhat impatient at having no looping mechanism yet. I am all for recursion, but not to the exclusion of every type of looping mechanism. Again, I stepped into Scheme blindly, having faith in the promise of the promo. I'm not ready to quit yet, but I keep getting blindsided as I ask kids to do things that I think are simple, like counting. This teacher is just using what's freely downloadable from the web (from your website). Although I realize you have workshops, to a great extent we simply have to rely on osmosis for these languages to filter outward. In my opinion, learning Scheme requires more hand-holding i.e. more trained people such as yourself are required to back it up and keep the ball rolling. In the case of Python, my expectation is CP4E is more a self-fulfilling prophecy (will require less push). Python is a snowball, or, like Tim Berners-Lee talks about the World Wide Web: a bobsled you need to push only in the beginning -- then you jump on and try steer (what he's been doing at W3C).

- that models and views are radically separated so that middle school kids don't have to bother with mind-numbing memorizations about view (i/o) stuff. Otherwise we're like biology.

My "math through programming" approach is to build on terminology already evolved in ordinary math classes. I personally like talking about models and views and would like to see more of this phased in. In the meantime, what we already teach about are functions, relations, compositions of functions, domain, range, sets, intersection, union... the standard math topics, found in most text books the last 10-15 years. This is what math teachers like to see -- familiar terms. Neither "model" nor "view" is a prevalent term in that knowledge domain (again, I think this should change).

;; ---

This was more in in response Shririam's feedback, after that positive review of my curriculum writing at the O'Reilly website:[1]

If you cite from private email, I can't comment. That's between him and you.

-- Matthias

If you say so. When I get a letter from a partner in a law firm, I get a clue by looking at the stationery as to whether she speaks for the company. In email world, we don't usually have "letterhead" per se, and so the scope (local? more global?) is not always so clear. Thanks for the clarification. Kirby

Also, I'd think you'd _want_ to cover car and cdr when approaching programming in Scheme

Why? That would be silly. Teaching in middle school and even high school our objectives are to produce thinking kids who can use some programming tool not finished Python/Scheme programmers.

I'll have to look at those docs again. Seems to me that using recursion as your primary means of looping means you're very often writing stuff like: (define (Reduce procedure mylist) (cond [(= (length mylist) 1)(car mylist)] [(procedure (car mylist)(Reduce procedure (cdr mylist)))] )) Usage:

(Reduce + '(1 2 3 4)) 10 (Reduce * '(1 2 3 4)) 24

In Python: def Reduce(proc, mylist): if len(mylist)==1: return mylist[0] else: return apply(proc, (mylist[0], Reduce(proc, mylist[1:]))) Usage:

...

...

import operator Reduce(operator.add,(1,2,3,4)) 10 Reduce(operator.mul,(1,2,3,4)) 24

(Note: for illustration purposes only -- Python has a built-in reduce function that already does the above). ... just back from the docs. Looks like you're using 'first' and 'rest' in place of 'car' and 'cdr'. That's good. 'car' and 'crd' are silly names. But I'm not finding where 'first' and 'rest' get defined. They're not MzScheme primitives i.e. I get an error message when I try using either one. Anyway, not to worry, I'll find this missing puzzle piece eventually.

Absolutely. Model and view is for us who know that Model is about functions, relations, compositions, domain, range, sets, ... (see TLL). View is about the stupid i/o crap that most languages impose on kids.

-- Matthias

Yeah, we don't want to start off on the wrong foot with a lot of stupid i/o crap, I agree. Thanks for the dialog. Sounds like we're not in any serious disagreement at this point. Kirby