> Very good point. The way I see it would be that this would be a > tool to teach beginners about control statements and program > flow *for relatively simple programs*. Something like a "guess > the number" or your the word substitution program (mad lib?) > that you talked about previously. The idea is to have something > complementary to other tools (like turtle graphics, etc.). > At least, that's _my_ take on it :-) > > André
Yes, that's a reasonable interpretation. But from my point of view it'd be overkill. A few diagrams of the traditional flowchart type should get the point across, then move into nongraphical coding. But this brings up an interesting point: should we try to assemble Pythonic tools that go into graphical hand-holding down to such a level, e.g. for very young children? Alan Kay strongly believes a young child shouldn't have to type to experience programming, i.e. some kind of drag and drop or other non-typing interface should facilitate programming. I have no problem with that if (a) we accept that typing will become important later and (b) don't insist that core Python has any responsibility to pander to non-typers. I do agree with Arthur that Python shouldn't pander. It was originally designed as a kind of teaching language, user friendly for newbies, but not newbie children, rather newbie adults with a professional need to program for some reason (e.g. telescopy experts, biologists, chemists or whathaveyou). That's the heritage and I don't see any reason to pretend otherwise. Python was never premised on being "kid friendly" in the way Squeak was. So if other environments e.g. Squeak or Lego Mindstorms, already have ways to accomplish this "almost no typing goal" is there any reason to commit the resources of the Python community in this direction? In other words, is there any reason to try pushing "snake language" into this ecological niche, and in what sense would it even be ostensibly Python any more, if we did? If it's just the implementation language, then it'd be somewhat hidden -- so then why not use something faster? I keep coming back to the notion that heterogeny is a good thing. One exercise we did at this Shuttleworth Summit was stand on a line according to how much we agreed with the statement: if we *could* implement a 10 year long curriculum around one language only, we should, at least for testing purposes, i.e. to see how well it worked. I stood fairly far at the other end as I recall (disagreeing with the statement): it's a curriculum *goal* to not get mired in one and only one language. We *want* diversity and making Python do the whole thing would be a bad idea in principle. But that's NOT to say we shouldn't have turtles, robots or other kid-friendly stuff in Python. It's more to say that it's being implemented in Python is not the chief advantageous feature (as if we expect kids that age to dig into the source code). The pedagogical advantages should be around the quality of the lessons and experiences, regardless of the implementation language, no? That being said, if one turtle or robot environment is free and open source, while another is closed source, proprietary, and possibly expensive, that *is* a feature to advertise as advantageous. However, Pythonic products needn't be free or open source, we already know. Pythonic is not synonymous with FOSS, even if the language itself is FOSS. Just thinking out loud here. One of our Shuttleworth Summit attenders was going back to Cape Town with Imagine Logo, a somewhat expensive commercial Logo aimed at the kid market (I guess that's redundant: Logo is by definition aimed at kids, no?). If we're to support the tentative Shuttleworth approach of using Logo with the youngest kids (then Squeak, then Python), we'd need something free and open source, and probably cross platform. There's no budget for expensive software in this picture. We need to start assembling candidate packages that'd run in a Tux Lab on Edubuntu I guess. What Logos? Squeak already works. Do we need to include wx in that distro? Is it included already? How about VPython (required for Pygeo, among other packages). I'll have to poke around more when I get back to Portland, where Derek has it installed in his test bed. Kirby in London PS: hope OK I'm replying to the list; your previous came to me only but doesn't appear confidential in any way. _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
