[Edu-sig] The keyhole problem and learning environments

[Paul D. Fernhout]

While looking around the web looking at issues related to Squeak and 
Python and 3D GUI issues(*), I came across this:
   "The Keyhole Problem".
   http://www.aristeia.com/TKP/
 From there: "This is the web page for my current book project, The 
Keyhole Problem. The book explains how some kinds of constraints in 
software systems decrease the quality of those systems in many ways. It 
proposes practical steps programmers can take to avoid these constraints. 
I call the constraints I'm interested in keyholes: arbitrary restrictions 
on your ability to see or express something. The name is motivated by the 
analogy of looking at a room through a keyhole in the door. I'm especially 
interested in keyholes that programmers can easily avoid, i.e., on 
gratuitous keyholes. The book defines a number of such keyhole types, 
gives a variety of examples of how they manifest themselves, explains why 
they are harmful, and describes how they can be avoided or mitigated. "

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. Maybe this is also a spin on what Kirby uses other language 
to describe related to when people try to hide the guts of GNU/Linux.
Now, that doesn't mean that it is not worth making web tools, just that 
this is a concern, to be weighed against the advantages of getting people 
doing any programming at all or having an easy way to deploy educational 
Python simulations, and I think it worth reflecting on to see if one can 
both get the cake of people using Pythonic simulations easily and eat it 
too by letting them change those simulations in unexpected ways.

Consider again my previous mention of "transient" versus "sovereign"
   http://www.cooper.com/articles/art_your_programs_posture.htm
applications. I accept the idea that when you want to know something 
specific it may be nice to find a canned simulation about it on, say, a 
Wikipedia page. But, what I want is a way for people. when they wish, to 
go further, and turn that "transient" experience of interacting with a 
canned simulation into an ongoing expandable experience using "sovereign" 
development tools. 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. For the web systems, I would have less problems with the 
concept if it was easy to easily point your large development tool at the 
web page, download the code, and then keep modifying it (and republish it).

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.

Thinking about a 3D turtle vs. 2D turtle in that context, then maybe a 
same idea would be to have a turtle that does 2D by default with a simple 
API but also supports complete 3D operations in an extended API for people 
who suddenly have an interest in going further.

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. Games are often structured this way as you proceed 
across levels or acquire new abilities. While that is looking at it from a 
pedagogical point of view, this issue pops up in lots of contexts. For 
example, emacs has tons of key bindings, and it is easy for a beginner to 
press one by accident and instead of getting a "beep" they get some 
completely unexpected behavior which they may not be able to back out of 
easily. It might be nice if for beginners only some of the key bindings 
worked, and they could be gradually added as needed in an easy way. 
Similarly, a criticism leveled in the link below on Squeak is that it is 
very easy to just break Squeak in various ways from the advanced shooting 
yourself in the foot by making a base class change that causes an error 
window to open when opening a window :-) to simple things like tearing off 
a window's close box in Morphic. PataPata has variations of the same 
failure modes too, so it isn't specifically bas about Squeak, just a 
general class of problems that are not always easy to solve. Somehow one 
want to lock certain features, or hide certain things, but still make them 
unlockable under certain situations. LearningWorks (based on VisualWorks 
Smalltalk) also addressed some of these issues hiding frames in the 
debugger related to internal operations from beginners.

Anyway, just pointing out that "The Keyhole Problem" is perhaps another 
metaphor to use in thinking about how to design software which is both 
easy to learn and also worth learning and using for itself over the long 
term. :-)

--Paul Fernhout
(*)Some random snapshot links along my thought path leading to that:
http://pyui.sourceforge.net/ [Just started a 3D PataPata version and am 
thinking about using this]
http://twistedmatrix.com/users/glyph/rant/sqcr.html [5 years out of date, 
but echoes my own similar frustrations with Squeak; came across as I need 
twisted or another API if I can get a Tkinter process to inspect the 3D 
OpenGL GLUT world I just started]
http://www.twistedmatrix.com/users/glyph/rant/python-vs-java.html [For 
comparison to Squeak, six year old negatives about Java, but they have 
been mostly resolved technically (though license issues remain).]
http://patricklogan.blogspot.com/2003/12/game-programming-with-python-and-pyui.html
[when looking to see comments on PyUI]
http://patricklogan.blogspot.com/2003/10/craving-rich-gui.html [Which 
mentions the Keyhole Problem]