Guido van Rossum (on CP4E, in 2000): "... The two major research goals are the development of a prototype of a new programming curriculum and matching prototype software comprising a highly user-friendly programming environment... First, the environment must significantly ease the burden of writing, installing, and debugging new programs..."
...curriculum... user-friendly programming environment ...easy installation... Common themes in the last few days' discussion on edu-sig. Inspired by Paul's post about "The Keyhole Problem" (from which I will quote occasionally below) I'd like to describe another concept which I believe is as important, and which I think of as "smoothing the learning curve". The learning process can be often describe as a series of discontinuous "learning steps" followed by "shallow curves". "Smoothing the learning curve" is an attempt to transform the "learning steps" into gradual inclines. I will try to "encapsulate" my ideas in short snippets, somewhat disjoint, and using concrete examples mostly taken from rur-ple and Crunchy Frog - since I know them better and they are actual concrete representations of those ideas. Paul wrote: > Part of this of course comes from pedagogical philosophy -- restrict what > kids can do at the moment versus point them to interesting things and see > what happens. I guess one could have a system that restricts at first and > gradually unlocks. This is the philosophy that was behind rur-ple. Users starts writing simple programs in the robot world, with very few instructions. However, unlike with Guido van Robot which uses a Python-like syntax, rur-ple uses Python through and through ... thus no "learning step" required when going from the robot world into the full python world. In terms of "unlocking", rur-ple includes a python interpreter (which is the next environment introduced after the robot world) followed by an editor with "quick run" button, allowing more flexibility in writing programs. However, that being said... Paul wrote: > While much of the book seems to be more about specific smaller programming > issues, metaphorically I think that the general metaphor relates to my > concern about promoting web-based development environments for Python > beginners. Especially having seen the alternative as advanced by Smalltalk > development environments thirty-odd years ago, I am concerned that such > efforts may be creating experiences of looking through lots of keyholes > instead of feeling increasing mastery of a powerful development > environment. Use the right tool - not the only tool. I don't like Idle; never had. My favourite Python editor is SPE. Yet, sometimes I would use Idle for a quick look at a python script. Nowadays, I tend to use "lightning compiler" [which I wrote] for quick jobs, or when I want to write a function/method with included doctests, rather than using SPE, as it is much more convenient for this. Two editors, for two different types of jobs - both of which are for programming in Python. conclusion: If I need to use more than one tool, why can I expect to have a single environment that will satisfy the needs of all learners. So, I don't expect rur-ple to be the complete answer... but a good partial one. However, back to rur-ple, there is a significant step (more so on some platforms than others) in adopting rur-ple: one has to install wxPython. This lead me to consider Crunchy Frog, initially as a web-based implementation of rur-ple requiring only Python and a web-browser. (At the moment, it does require also Elementtree as a separate install - but this may change with Python 2.5+) Again, the idea was to "smooth the [installing] curve", removing a barrier to learning. Paul wrote: > I think this also returns to earlier comments on how to design a good > graphical context for Python newbies -- one that just lets you do some > interesting things easily (a keyhole) versus one that makes such things > easy but still gives you power to move beyond that and do general graphics. There are *so many* interesting packages written in Python that it would be presumptuous, imo, to think that any individual or team of individuals could provide a learning environment powerful enough to satisfy all potential users of the various python modules that are available. > For a decade that has always been my indirect goal with > plans for our garden simulator -- to present something complex and > educational, yet open to the user to easily build on, tear down, or just > go further with, and that has been part of what has driven my interest in > Squeak and now Python. Essentially, after the user looks through the > keyhole of the specific simulation running, ideally they can open the door > and walk into the simulation with easy-to-use development tools and start > making changes. This is part of the philosophy behind Crunchy Frog. You/(one) want to learn about pyui? I assume you are not going to do this by poring over the code, line by line. Rather, you will look for documentation/examples as your starting point. Most packages nowadays will have *some* html "tutorial". Now, what if you knew, as a package designer, that just by adding a few extra markup instructions, you could have the tutorial transformed into an interactive one inside a web-browser - thus allowing easy initial exploration of the package. This is what Crunchy Frog allows. Granted, it is still in its infancy and will likely be superseded by something better written by a professional programmer - but I like to think of it as an interesting proof of concept. What we need (and was identified in the CP4E proposal as quoted above) is lots of teaching material. The more material at all levels, the smoother the learning curve. One obstacle, I believe, is the apparent daunting task that this represent as seen by any one potential teacher. However, if there was a repository of Python related teaching material, following a standard format, many people might be interested in contributing. That's my opinion anyway... André _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
