[Edu-sig] The keyhole problem and learning environments

[Paul D. Fernhout]

Andre Roberge wrote:
 > 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.

Thanks for the thoughtful reply with many good points.

I'll agree you have a good point I need to think more on from an 
educational point of view seeing Python as a broad platform and as people 
learn more about it they move from using one sort of library to another 
(or one sort of editing environment to another). It's a coherent way to 
look at Python and learning (both about Python itself and about things 
Python helps you simulate). Thanks for outlining it.

Having said that, I still think there is a tension between two approaches. 
One is getting people to invest a modicum of effort up from to learn a 
small set of good tools like Smalltalk had even 30 years ago (browser, 
inspector, debugger and transcript being the core ones) to give a 
consistent experience to working with a well thought out core library. The 
other approach is learning one simple tool, and then another fancier one, 
and then another, etc, each perhaps easy to learn as a next step but 
missing some essential feature, and moving from simple libraries to more 
complex libraries as needs change.

I don't want to sound too complaining, but perhaps there are a lot of 
Python libraries or tools sometimes because they are *all* missing 
essential features or built with limited time and attention and 
experience? Obviously, one hopes the reason is instead that they are all 
good for different things or they are coming at a problem from different 
points of view. :-) Most likely, it is a mix of both reasons.

Still, in the case of Python development tools, and not having sampled 
them *all* myself, of the ones I've tried (Eclipse & PyDev, Eclipse & 
RedRobin, Idle, Boa Constructor, Scite, and a couple others) they do lack 
core features that any Smalltalker takes for granted -- for example always 
having an integrated restartable debugger available during development, or 
there usually being two levels of naming for methods and classes (i.e. an 
organization "protocol" or "category" level above the actual object or 
method level; almost all Smalltalks support this). And there are several 
other core missing features. Not to say Python doesn't have its own 
advantages, but the commercial Smalltalk libraries I've seen for all sorts 
of core things are just more complete than Python's (for example, all the 
stuff you can do with streams).  [Python may win on breadth of free stuff, 
especially web related.] Granted there are also drawbacks to some of 
Smalltalk's approaches to things, and some of the libraries can require 
abstract thinking to use them, but, when working on large projects, in my 
mind there is little comparison, a good Smalltalk like VisualWorks (though 
maybe not always Squeak) wins over Python (for large projects) because it 
is easier to manage complexity in it usign those features. There may be 
lots of good reasons for using Python anyway, including being 
free-as-in-freedom, or being easy to learn for C programmers, but one 
should be realistic about its relative weaknesses so one knows where 
improvement can be done.

So, does that mean a beginner should be overwhelmed by all this at the 
start (either tools or libraries)? Are "keyholes" sometimes good then? 
That's an interesting question. And Smalltalk has always suffered from a 
steep initial learning curve -- although I think webcasts like Francois 
Schnell did for PataPata (thanks again) could help a lot with that. So, 
one can still try to make an argument that a simple editor with a small 
program is enough to learn the syntax and core library of a language (as 
with a web based tool), and from then they can more onto other tools. I'm 
still not sure I buy that argument, :-) but I'm just trying to make 
explicit the assumptions underling it versus an alternative more 
monolithic conventional Smalltalk approach.

I think part of this also depends whether you learn a system on your own 
(prhaps from a book or on the web) versus whether you learn it in a 
computer lab or through video demonstrations. Again, I've now seen from 
Francois' webcast and now others as I look around at, say, ShowMeDo,
   http://showmedo.com/
that watching even a five minute webcast  may potentially make more 
complex GUIs much more accessible to novices (or at least, motivate them 
enough to push past the learning curve). Having mentored people learning 
Smalltalk in industry and taught C to Bio majors at a university, I know 
Smalltalk is the sort of thing most people do much better with when given 
a little hand holding up front -- much more so that something like VB or 
C++ (those those also benefit some of course). I think the difference is 
that in Smalltalk so much of a typical system is accessible within the 
environment (rarely meeting a compiled library brick wall) that helping 
people come to see that is much more important than in other systems 
(including sometimes Python) where one does rely on the documentation much 
more than the code. (Actually in Smalltalk, one usually relies on finding 
a real *example* of usage of an class of interest within the system...)

So -- a lot of variables in choosing how to present Python programming to 
"everybody". How much hand holding is available? Do the learners have 
access to video presentations or other ways of seeing complex tools being 
used as in a classroom or computer lab? How motivated are the learners? Or 
how much are they willing to invest of their time relative to what 
benefits they expect?  Or, from another perspective, how much time are the 
learners willing to "risk" before they see a payoff? Conventional 
Smalltalk tools often require you to be willing to risk a higher amount of 
time before seeing any significant payoff, whereas you can type
" print 'hello' " on the Python command line and you are going. (Strictly 
speaking that isn't quite a fair comparison because in Smalltalk you can 
type something like  " Transcript show: 'hello' " in almost any text pane 
and click "do it" from a menu, but most Smalltalkers don't consider that 
programming, which may be a flaw in how Smalltalk is typically taught. :-)

And, obviously, the Squeak Team led by Alan Kay has been moving more in a 
simplified interface direction. They now have eToys, and beyond that 
Croquet with some other tools, plus there were predecessors also in 
Squeak. Now there is LogoWiki. So, they have made several attempts to put 
simpler (or different) interfaces on top of Squeak or, for LogoWiki, in 
front of people on the web (Squeak powered or not). Or in effect, creating 
"keyholes" in front of Smalltalk. (Although, Smalltalk always remains 
easily available at least in the Squeak powered examples). So that is a 
vote even by the inventors of Smalltalk for such simpler interfaces. 
Personally, I remain uneasy about those directions. While I am all for 
tools to help making programming easier or even sometimes doing some of it 
graphically, I think (as Kirby perhaps does?) that something big is 
missing if there is no textual representation, or if the text 
representation, as in eToys, is somehow, how to say this, somewhat 
fragmented? And I can wonder if the eToys and such are really as easy to 
use (for novices) as they look in demos (or even webcasts :-). I know from 
the history of Smalltalk that young kids, when given some hand holding, 
really can do stuff with textual Smalltalk representations.  I presume 
that extends to Python, even though Python is a harder language to learn 
and use in some ways than Smalltalk -- if you don't already know C or 
something like it.

Anyway, I'm mainly trying to think through some of these issues for 
myself, including for how PataPata proceeds, so thanks again for your 
comment (and thanks to Kirby for his too). Perhaps ultimately there is 
just a cultural issue (influenced perhaps by technological choices). With 
excellent modules from the start, and always being free and originating at 
a university, Python has a modular culture with quite a bit of diversity, 
and that is reflected in the philosophy you outline of learning how to 
navigate within that community with all its choices. Smalltalk, on the 
other hand, even though supposedly made for kids, was born in chains in 
the heart of Silicon Valley, inspiring the Macintosh, and (unfortunately?) 
aspiring later for a while to be the successor to COBOL in the financial 
world, and was highly polished for decades by a relatively larger team of 
well paid technologists some of whom went on to create publicly traded 
companies around it, and that shows a very different cultural legacy -- 
more monolithic, less focus on modularity, a requirement applications be 
packages without the compiler/interpreter, and until Squeak (and a few 
lesser known others) the language had little of the scent of freedom 
around it. So, some big cultural divides are there historically in how the 
communities and technologies were created and evolved -- each with some 
good points and bad points. So, one could also argue that your stepping 
stone approach (or "learning steps" and "shallow curves") is also as much 
an introduction to a Python community and related philosophies of freedom 
underlying the diversity of tools and libraries as it is learning to 
program. :-)

Still, I still don't want to let Python off the hook for missing some good 
features Smalltalk had thirty years ago (though I've made some small 
efforts at adding some such things to Python. :-)

[Well, need to wind this down and I'll be traveling for a week, so maybe 
not much more follow up, sorry.]

--Paul Fernhout