Hey, this has all been useful grist for the mill I'd say. Many thank yous to the active contributors.
There's a big distinction that needs making: GUI-based programming as a productivity aid (Laura: positioning widgets is mindlessly boring) and as an introduction to the whole idea of what it means to computer program (pedagogical aid). I'm much less conflicted about the former use (productivity), while I'm rather averse to babying/coddling, meanwhile letting uber-geeks maintain private understanding of file trees, OS kernel, device drivers and the world of a low level text based command line. I'm not saying 10 year olds need to be whipped through some harrowing keyboard-intensive training in the bash shell. I'm saying more adult curiousity, a symptom of puberty, should be both cultivated and respected. We share this in the spirit of teaching "how things work". How is your city sewer system set up, what's the municipal water supply, where is the electricity coming from, and what's going on in these computers, at the network level, and inside the box. We have many stories to share, explorations to undertake. As long as the command line world is relevant *to anyone* active on the current computing scene (i.e. we're not talking legacy skillsets, of interest mainly to historians), kids should get the low down. At the police station (HPD -- see archives), we went straight to bash and vi, not to develop all the conditioned reflexes (takes lots of practice, no time), but as tour guides, to show geekworld up close and personal. And don't pretend we don't know that GUIs are for sissies, even still, if by GUI we mean something that candifies, sugar coats, insulates, in a WYSIWYG IDE. That's just fine as a productivity tool, which is how I use 'em, almost daily (see above), but it's NOT the primo landscape when giving newbies the lay of the land -- not *exclusively* in any case. Put another way: what I want for South African kids is a reading knowledge of Python. I don't much care how that's gussied up on a bltblt canvas, what bells and whistles get used. At the heart of it, Python is simply ASCII source code that we know how to read, or don't. The target fluency we're working to cultivate is at that level, not at the level of which mouse buttons to click, which dialog boxes to open (good discussion with Alan Kay about "modal windows" over beers @ JurysDoyle). Navigating the interface isn't irrelevant (gotta learn that too) but it's not a core language in and of itself. The focus is more Scheme than DrScheme, admirable though that packaging may be (I find it admirable). Likewise, I want Squeak to be about, among other things, developing a reading knowledge of SmallTalk. It's not like you have to make a career out of being a SmallTalk programmer. It's more like we're ploughing through Shakespeare, learning what a different English was like, developing backward compatibility -- or Cervantes or whatever. Alice in Wonderland. Or if the "tank language" is Python (embedded in some imaginary world, ala Squeak or ToonTalk, complete with hypercard, turtle and robots), same diff: we want to dive deep into the concepts, through mastery of a true pre-visual computer language. The toons are a means to that end, not an end in themselves, enjoyable as playing with them may be (I'm all for enjoyment). So... What this means for me is I'll be doing austere textual Python with Saturday Academy kids (starting this next weekend), going back and forth between traditional mathematical symbolization and the dot notated version. Here is a "rational number" (typical squiggles) here it is again in Python (lots of operator overloading). GCD, LCM, primes, composites, field properties, edges from those nodes, computer language at the elbow (or front and center, as the case may be). We'll get into ray tracing and other graphical tools, sure, but with a sense of text files driving the whole works, not the other way around. And this is field testing for Shuttleworth, likewise, on the understanding that our testing venue is but one of many. Plus I'm going back to my "rich data structures" idea. What we need is a pipeline into Shuttleworth HQ that provides Pythonic recordings of rich, real world data that might be fun to work with as raw material: bones in the body as a kind of tree (perhaps embedded dictionaries with lists-for-leaves), a periodic table with atomic numbers, data about our solar system (examples already in archives). We've already got a stash of such data, but explicitly adding to this stash for Edubuntu branding and distribution (i.e. as a part of the default /site-packages/datamine/ or whatever) will give the Tux Labs beefier content, adding to lesson plan possibilities (even minus any broadband). Per my whitepaper at the Summit page (wiki), the joules/calories theme will be especially strong (food values, power consumption specs, the generic idea of energy flows). Kirby _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
