On 5/7/06, Paul D. Fernhout <[EMAIL PROTECTED]> 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 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
