[Edu-sig] More post Summit brainstorming
kirby.urner at gmail.com
Mon Apr 17 17:40:33 CEST 2006
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
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
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).
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
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).
More information about the Edu-sig