[Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak

[kirby urner]

On 5/7/06, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
> It is funny how we can all accept that learning to play a musical
> instrument like the flute might take years of concentrated study to even
> get a good "tone" out of it, but we expect computers to be engaging on a
> minute by minute basis. Or, we just accept that learning to touch type
> takes days of practice. But computer IDEs? Do they really need to be like
> video games, engaging and addictive from the first quarter?

This question defines a long-running theme here on edu-sig and I think
you phrase it beautifully.

I just don't see getting away from the intricate syntax of Latinate
computer languages any time soon.  They're intrinsic to the mix. 
However, we may have higher level simulation languages, where just
dragging some ideogram or hieroglyph into a scene causes all these
emergent behaviors, thanks to algorithms encoded using lexical tokens.

Sometimes the knowledge domain we're hoping to model simply demands a
high end animation engine running in the background.  The users of
this model don't participate in the source coding all that directly,
and have a more graphical IDE within which to set up their energy,
data, or currency flows.  ESRI's use of embedded Python is a good
example:  to the end user, it's drag and drop, but under the hood,
you're writing a Python script.

The trend in modern OSs is to provide 3D geometry capability through a
shared API in principle available to any hosted application.  OpenGL,
Direct3D, Xgl...  I'm thinking that education applications in the
"world" genre (like Squeak, like Uru, like ActiveWorlds) do well to
take advantage of this existing machinery and not reinvent these
wheels.  But the glue layer, where the rubber meets the road, is still
lexical in nature.  I don't care how pretty your canvas is, or what
kind of textured tube it came from (pneumatic, from Brazil?), it's
still Python or C# or SmallTalk or some Latinate doohinky under the
hood.

Which isn't to say we couldn't also go with Tibetan, Cherokee, Arabic,
Cyrillic or other unicode glyph language when committing lexical
tokens to a parser.  In principle, source code doesn't have to be
Romanji.  It just happens that's what most of it is so far, at this
point in world history, and it's working out pretty well.  And as I've
said, it might be that the Kanji make more sense at a higher level
anyway, when we start with the graphical simulations and need ways of
counterbalancing various energies or whatever.

Kirby