kirby urner wrote: >> 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 think "typing" is the wrong thing to look at. A young child shouldn't have to hunt and peck -- too many things to keep track of at once. And they shouldn't have to form grammatically correct code, which doesn't mean anything to them when they are starting. But that doesn't make typing as a whole bad. So a typical entry into a Logo environment involves a kid using the arrow keys to define a shape. They get some output, they don't have to hunt and peck, they have a constrained environment. None of which is necessarily *better* than a graphically composable program. But it's certainly a lot easier to create ;) Where perhaps it becomes more interesting is using these things as a path to full grammar. For instance, you hit some arrows, and you have a very very crude paint program. Not that fun. But if you turn that into language, then you have something more interesting. E.g., they hit some keys, they have a "shape", but the shape is actually represented as programming text, like: [F F F R F F R F R R L L F ...] That's the most simple representation, just the keys they hit. You could even use glyphs instead of letters. But it introduces the idea, and starts to open up areas for further abstraction. In the geometric world of turtles, it gives you a basic and nontrivial building block (well, nontrivial depending on the age -- but you could also adjust this accordingly). It also lets the student learn from immitation -- in this case, immitating the code created by the constrained interface. Unlike much-reviled code generators seen elsewhere, the constrained interfaces would create human-editable code, and would not be a "complete" environment (like no editing built into them). Another kind of graphical environment that seems interesting to me is representing lexical structure graphically (i.e., modules, classes, functions, for/while loops, if statements). I think this is a much more conservative approach than drag-and-drop programming, but offers some real advantages, particularly for some of the students who won't naturally catch on to programming. Rich literals is another similar idea; e.g., given the right environment you could represent a color as a literal, with the color inlined into the code and editable with a color selector. Both of these fit in fairly well to the Python programming model, just not into the typical toolset (including Python's most basic tools, like the loading of modules). With the AST branch merged in Python 2.5, maybe introducing different parsers would be more feasible than previously. > 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). Re: Logos, I haven't looked for a while, but last I looked just a couple implementations stood out. TurtleTracks in Java was one. UCBLogo was architected for the days of DOS, with very limited computer resources; there's been some recent work to improve it, but I personally don't think Logo is so hard to implement that it's worth starting from there. NetLogo and StarLogo are Logo, but also feel different than the average Logo. There's a Mono Logo that looks pretty good: http://liogo.sourceforge.net/ and Elica is another nice Windows-only Logo, that's not open source but is free, and I think at least deserves some attention if you are thinking about approachable projects for a 3D environment (like VPython). An interesting exercise might be translating some parts of Computer Science Logo Style (http://www.cs.berkeley.edu/~bh/logo.html) into Python, to get a feel for how much of a text like that is related to the language, and how much to the environment. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
