[Edu-sig] Shuttleworth Summit

[Paul D. Fernhout]

Guido van Rossum wrote:
> I'm not interested in switching to Jython for this purpose; 

It might distract from this discussion, but I'd certainly be curious why. 
Jython 2.1 is a fantastic system, even for something a few years old -- it 
just works. It could easily call 3D graphics APIs from Java, and could 
easily make something that could be an applet which ran in most browsers. 
I'm not pushing hard on this, and I don't want to force you into any 
off-the-cuff public opinions people might weigh too heavily coming from 
you, but Jython is indeed a really cool technology which makes the best of 
a bad situation (that so much effort has gone into an unneeded and poorly 
thought out (i.e. no closures) new language like Java). If one used Jython 
with only GNU Classpath and free JVMs, one is even staying on a very free 
software path avoiding the "Java Trap".
   http://www.gnu.org/philosophy/java-trap.html

Granted, in support of your comment, as I write this, Eclipse with PyDev 
and the JVM running it crash on me literally five times a day or so as I 
write Jython code, and I just live with that. It started recently after a 
recent major system upgrade on my Debian system of several things, and I'm 
not sure where the problem is (Eclipse code, PyDev, JVM, supporting C 
libs, supporting Java libs, etc.). So much of the entire system is opaque 
to the causal user. As I don't have time right now to learn all the things 
I would need to know to try to diagnose it or fix that, assuming it even 
was fixable, I don't even start trying and just live with it for now (with 
a deadline looming, I really don't have the time right now to right this 
email though, either, of course. :-). In a more self-contained 
Smalltalk-like environment, short of a VM problem it would be much easier 
to consider remedying the situation. It's not that I couldn't in theory 
fix this problem or even fairly easily get more out of Eclipse by 
bothering to look at its error reporting squirreled away in a directory 
somewhere -- it's just that the tooling up and debugging overhead, which 
might take many days, especially given who knows what will be next problem 
with a new upgrade, just isn't worth it. So I just hope for a fix with the 
next upgrade.

That is a more and more common problem open source developers face -- 
dealing with the complexity of complex interwoven systems of applications, 
each in its own language with its own development tools and learning 
curve, which may interact in subtle ways leading to seemingly random 
crashes. And it is a crushing problem for beginners. One reason I am all 
for standalone applications (see my other post).

Anyway, that's all a good reason for avoiding Java and its immense set of 
dependencies (and so Jython), so I can see one justification for such a 
decision, but Java/Jython still has a lot of pros to weight against the 
cons, including estimates of where it would be in a few years (e.g. if GNU 
Classpath progresses, if Sun open sources it, if commercial interest in 
Jython picks up as more and more people realize what a bad language Java 
is for most purposes, and so on). I fought Java for years one way or 
another, but now almost a decade later, they finally got most of the bugs 
out, there is some open versions, and it is a reasonable platform for some 
things.

> nor am I
> interested in directly linking to code that's part of Squeak --
> unless, perhaps, there's some low-level code that is independent of
> the rest of the Squeak environment while providing some functionality
> we need. 

You'd also need to watch out for Squeak license issues. I personally would 
not use any of the Squeak code in another project without contacting the 
original authors and getting a more standard open source license for it. 
Most of the lower level code for running on multiple platforms is the work 
of a few individuals, so this is feasible.

But I think it is pretty clear form discussion here that SDL, OpenGL, or 
another crossplatform tool lime wxWidgets is probably a better match for 
Python philosophy than using Squeak code. I mentioned wxWidgets also, 
since one could use wxWidgets and an empty window for a base and write 
your own widgets by just relying on a simple canvas and drawing all your 
own stuff, and the result would run anywhere wxWidgets runs.  You don't 
have to use their widgets. Same with using Swing as a base with Jython; 
you can just use the base canvas. A more Python approach might be to 
improve AnyGUI, or alternatively, to just write on a common graphics layer 
which ran on any of Swing, SDL, OpenGL, wxWindows, GTK, or other widget 
sets. It would not have to be a complex layer -- mostly bitblitting. The 
complexities can get written above that (like Squeak does).

 >  I'm also not interested in making Python an entirely
> self-contained system such as Squeak is -- much of Python's strengths
> come from its capabilities as a glue language, seamlessly integrating
> with other software on many different platforms.

Python will never lose those strength; the community would not allow it.

But, one could think of making a somewhat more self contained development 
system that was more Squeak-like, sort of as a successor to Idle, but with 
a different focus than just plain coding. Something which was 
crossplatform and just good enough for most uses, especially if it 
implemented the remote development / debugging notions I mentioned in 
another post to this thread. A big win for Smalltalk has always been that 
you can modify applications while they are running. This isn't just for 
development; this is one reason some huge commercial applications use 
Smalltalk to be able to debug and then put in hot fixes in a running 
application. Python module reloading has never been the same as that (one 
reason I worked on improving reloading, though the approach I use still 
has limits and bugs). Beginners really benefit from continual rapid 
feedback and modifying a program while it runs is a good way to get that. 
In Smalltalk, a natural way to write your code is in the debugger often 
times -- just write a stub function with a "self halt" and when it fails, 
fill it out, and then add more whenever the system says something is not 
implemented fully.

> But, after encouragement from Alan Kay, I *am* interested in producing
> a Squeak-like environment *on top* of Python. Alan suggested using a
> slightly different starting point than Squeak; modern graphics cards
> have a wealth of functionality that can be accessed directly. I'm no
> graphics expert, but I believe OpenGL and perhaps SVG could be the
> right basis to get started.
> 
> The approach that seems to make the most sense to me (but I'm open for
> alternatives) is to start out by producing a solid low-level graphics
> package like this that can work across platforms (Linux, Windows and
> OSX preferably); once that is settled, we could build an application
> resembling Squeak's UI.

I'm not up to date on the latest, using mostly Python/Jython now, but even 
from what I know, there are a few levels (and versions) to Squeak's UI. 
There are a few different widget tool kits in the system (e.g. MVC, 
Morphic, Balloon 3D or its successor, in Croquet). Then there are several 
major applications or development kits built on top of them (eToys, the 
rest of Croquet, browsers and inspectors, others). So there are a lot of 
pieces to consider, and parts of them might be worth rejecting (i.e. the 
specific look of the halo, which I don't like), and parts worth using 
(some 3D environment notions). Also, both Alice, a 3D environment in Python,
http://www.cs.cmu.edu/~stage3/publications/95/journals/IEEEcomputer/CGandA/paper.html
and LearningWorks (a 3D environment in VIsualWorks Smalltalk, now 
defunct?) predate Croquet and have concepts one might learn from or adapt.
Personally I think a PythonCard/HyperCard like design tool is an important 
thing for beginners to have.

I guess a big part is what your goals are. And on this list, if we are 
talking computer programming for everyone, I would think making the whole 
experience as painless as possible for novices, while still engaging for 
advanced users, would be a good goal. Graphics can help with that, but 
there are many other factors, all of which should come together to make a 
great experience (and that includes base tools like browsers, inspectors, 
debuggers, and so on). I think that is one reason plain old Python on the 
command line doing command line text (and file) processing is still so 
engaging -- it just works, it provides immediate feedback, and it has a 
lot of long term growth potential for expert use.

Anyway it's a big issue to consider what parts of the Squeak vision are 
most compelling in a Python context. I know Alan Kay gives great demos, 
but I've seen what happens afterwards when people download Squeak and fall 
flat on their face with it (over and over). I'm not saying Squeak can't do 
what Alan shows; those are real live demos. Just that it is both rough 
around the edges and I think in need of some other user interface and 
complex management efforts. As I said in another post, Alan Kay says "burn 
the diskpacks" (since innovation often happens when people start over), 
which in this case I would suggest means, don't just try to ape Squeak in 
Python, but, building on Python's (and Squeaks's) strengths, and paying 
attention to the lessons learned from viewing them as experiments, build 
something better. So, part of that means figuring out what the goals worth 
keeping, and what are worth rejecting (and you're doing that with thinking 
about graphics support for modern cards, but it is just one issue).

> There's probably more to it; but typing this email at a busy
> conference my thoughts are a bit distracted.

One thing I might add in the context of education, is that kids seem to 
learn most by constructing things and being engaged intrinsically in what 
they are doing.

It seems to me that some of Mark Shuttleworth's philanthropic efforts into 
education, like his effort to make an open source school administration 
package, while very well intentioned, are somewhat "old school" -- to try 
to make a joke of a serious topic effecting hundreds of millions of 
children's lives (often in a negative way).
   http://www.johntaylorgatto.com/underground/toc1.htm
Specifically, new schooling IMHO is really "unschooling"
   http://www.unschooling.com/
in the sense of helping kids be engages in and learn from the community 
around them. I don't think "schooling" can be fixed; though "free schools" 
certainly are a step in a good direction.
   http://www.albanyfreeschool.com/overview.shtml
Educational efforts that are "Edutainment" or even ones that are simply 
closed web browser applets letting kids play with one things may be nicer 
than dusty chalkboards, but they are at best a small improvement. Perhaps 
that is why people find our garden simulator boring, but they love to 
design their own plants using our PlantStudio software. What Alan Kay or 
Seymour Papert or John Taylor Gatto or John Holt or Grace Llewellyn might 
suggest is that true education happens when adults use their life skills 
to make opportunities available to children to learn -- and then stand out 
of the way (until occasionally asked in). It's a fundamentally different 
philosophy than that taught to "teachers" when they go to teacher training 
schools. So, based on that, I think any software development environment 
that confines itself to a browser applet (to meet school needs) is going 
to short change kids. Yes, it may help in the case of a relative of mine, 
whose school district forced all teachers to sign a document saying they 
would be fired if they installed any software on their machines (but 
presumably Java applets are OK)? But for the larger picture, investing in 
things that makes school administrator's lives easier isn't IMHO the best 
investment of free dollars. Schooling is not the same thing as 
"education". Or in other words, think of public and private schools as 
being like Microsoft, and unschooling (or to a lesser extent 
homeschooling) as being like the open source / free software world. Yes, 
it may make some sense to make life in schools or life using Microsoft 
windows a little less miserable for those trapped in them (as students or 
teachers), but that really does not address the root of the problem of 
both schools and Microsoft as being mainly authoritarian systems that are 
the antitheses of freedom and growth. I'd say, target the unschooler (or 
homeschooler) with the software to be written, and then stand out of the 
way. :-) If that means Shuttleworth is less interested, then so be it; but 
you might gain thousands of other developers from the unschooled ranks.

--Paul Fernhout