[Edu-sig] The keyhole problem and learning environments

[Andre Roberge]

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é