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] _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
