[Edu-sig] Shuttleworth Summit
Paul D. Fernhout
pdfernhout at kurtz-fernhout.com
Fri Apr 21 23:48:17 CEST 2006
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
More information about the Edu-sig
mailing list