[Edu-sig] Moving forward an educational Python environment

[Paul D. Fernhout]

Guido-

It's really exciting to see the idea moving forward of Squeak concepts
running on a stable Python base that all was under conventional "free" and
"open source" licenses, and that Squeak-like technology could finally be
in the "free" part of a Debian-based distribution.

I'm certainly willing to throw my hat in the ring (not to discourage
anybody else, though :-); however, see the end for some limitations.
I'm posting this to the edusig list because people might be interested in
commenting on these ideas or working them into their own proposals.

I'm happy to privately send a resume (since we are talking funding here),
but for now instead here are my initial thoughts on how I would approach
this. Obviously, these notions could be refined by talking to other people
(especially Squeakers) at the start. And tactics would also depend on who
else wanted to help. Essentially they cover choice of language and
technologies, and then a sketch of a development plan. The major parts of
the development plan as I see it initially would include roughly in order:
* adding more support for changing Python applications while they are
running,
* getting a Smalltalk-like language on top of Python that uses Python
libraries, (optional, but Squeaker-friendly)
* integrating in a HyperCard/PythonCard derivative,
* stress testing the system by getting one or more major constructivist
educational applications under it (like our Garden Simulator),
* adding eToys and Logo support,
* and finally moving into work on supporting 2D/3D Croquet-like
capabilities (the last item being what would take a very long time, having
future subplans, and so on).

How polished any of those things end up being would be a function of how
much other people get involved; I would see my initial goal to get the
systems working together under Ubuntu and then hope others will see value
in them and help keep them going as I take on a more coordinating role as
time goes by (though I'd rather be coding when I can, especially in such a
neat system.)

=== objective ===

The overall objective would be to capture the excitement Alan Kay conveys
about Squeak Smalltalk, eToys, Croquet and so on, but do that on a stable
and freely licensed Python base. The specific goal would be using Python
to deliver constructivist educational activities, both helping people
create 3D simulations and helping people use a variety of programming
styles (code, icons, HyperCard, etc.). Integrated communications from
multiple users is important in the full system, though perhaps not at
first? The system should both be novice friendly and of interest to experts.

As per my previous comments, overall I'd personally focus more on
supporting constructivist self-education without a teacher's direct
involvement or the need for a specific curriculum (beyond simple
tutorials, etc.). However, I'd concede such a system in use within the
classroom would be better than what schools have now, and it would be nice
to have someone write school curriculum units related to it (though I
personally would not want to make a lot of design concessions for school
as opposed to home use, though I don't expect they are needed much anyway).

=== choice of Python ===

On Python vs. Jython: I'm quite happy to work mainly in Python and not
Jython, despite my earlier (and see below) plugs for Jython. :-)
One can make strong arguments for basing the project in CPython too. :-)

I'd still argue though that if you want a browser plugin then using Jython
somehow is the best way to go, and I would not want to put any effort
myself on plugin support if the project was done in CPython (though would
be still happy to coordinate that if someone pursued that). My thinking is
that if plugin applets really mattered, we'd see  more of them already
with Jython. Once a good system is working, Jython could still be a web
deployment vehicle for some parts of the system (like eToys or stand-alone
simulations, though probably requiring a compatibility layer). I don't see
IronPython as a good candidate because of the patent uncertainty etc.
related to dotnet/Mono issues, especially if GNU/Linux is a first platform.

=== tool philosophy ===

Keeping with the Python philosophy, I would see this as a suite of tools
which each might be supported by different technologies (including
different GUI libraries). To keep this manageable, I would focus first on
something that runs on top of Debian GNU/Linux. Ubuntu is such a platform,
and would be the obvious development platform and test place for packages,
though I currently run plain Debian, so I would have to switch eventually.

However, I would keep in mind Mac and Windows support in a choice of
cross-platform approaches (likely one or more of wxWidgets, SDL, and
OpenGL, though I found the Mozilla idea intriguing too) and perhaps
developing a compatibility layer for some parts of the system. But making
cross-platform support a priority would only come in as others committed
to be at active testers on those platforms. If that is at the start, then
great. From a reliability standpoint, on Windows or the Mac it might make
sense to include an entire local CPython system with the application,
because the difficulty of ensuring prerequisites.

Much as I'd like to drill down through the entire system in Python (or
Smalltalk) I don't see that as a realistic starting goal. After PyPy
matures, and once the rest of the system works, then there might be more
energy to do that (say, by translating wxWidgets code at first to Python).
Some of that capability will also mature through work on HyperCard and
eToys. So, I wouldn't promise the system would look at all Squeak-like
from the start, but some of the tools could evolve that way.
It's hard to explain, but I have a hunch a remote debugging/development
approach through the network will make the suite of applications always
feel more transparent, even if the drill down level often stops at the
widget API.

Incidentally, funky GUIs would be another good reason to use Jython to use
Swing look and feels like napkin:
   http://www.akuaku.org/archives/2004/09/napkin_swing_lo.shtml
if that was really important. Still, in the approach I outline even Jython
based applications could take part in the overall set of networked
applications I reference below as browsers or debuggers of code defining
SDL based applications, for example, or an SDL based debugger
could debug a network-aware Jython application.

=== to do ===

Here is a list of TODO tasks in a rough order.

=== open up communications with Squeakers and Pythonistas ===

Obviously, getting talking with Alan's group as soon as possible is
important, as well as making the project open to the Python community.
This entails getting a mailing list, wiki, and SVN repository going, as
well as probably firing up the latest OpenCroquet for communications with
Alan's group. But there is also a lot to be done before making a major
effort to use their ideas or invite them to use intermediate results.

=== supporting changing Python apps while they run ===

My first focus would be getting Smalltalk-like development environment
capabilities into Python. For the most part that means supporting
modifying actively running Python code and having a classical browser,
inspector, and debugger like Smalltalk offers.

However, the future of Smalltalk is away from all-in-one image systems,
since there are a lot of issues of shooting yourself in the foot when your
development tools share an objectspace or VM with your application (e.g.
making it so all windows can't open themselves), so remote debugging and
image construction is desirable. To support this at first might involve
using a separate thread running in the application, and would initially
use a sort of module or per function reloading approach, but later the
Python VM could be modified to support a debugger socket connection
natively. I already have a crude prototypes of this using C and Python,
though they are tied to representing data as Pointrel triads (don't ask
why. :-)  I would initially base this on a model of both debugged program
and debugger being clients of a single redirecting server on the machine.

Handling source code versions easily is an important part of the Smalltalk
experience, and I could initially use my Pointrel data repository system
for an initial versioning source code system, though integrating with SVN
would be nice too.

As per above, these initial GUI tools might be in wxWidgets, though end
user programs might more likely be in OpenGL or SDL or whatever; I might
take a longer look at whether other existing free Python system could help
support this (e.g. BoaConstructor), but my emphasis here would be on
getting the overall socket communications in place, thinking that better
development tools could always be hooked in as clients. I would try to
ship the objects around as pickled Python objects, but would need to look
hard at current security issues there, otherwise they would end up as some
other format.

I would expect any core changes to Python or existing libraries to be
placed under the Python license, but likely I would want to release the
more standalone toolsets like a debugger client or browser client under
the GPL.

To be clear, what I am going for here is the "feel" of developing in
Smalltalk, where you can point your inspector at an arbitrary application,
not necessarily the specifics of the Squeak experience. In this case, the
Python philosophy of being like glue :-) suggests treating Ubuntu (or any
OS) as analogous to a Squeak VM, and finding a way, sockets in this case,
to make seemingly different things work together.

=== putting a Smalltalk subsystem on top of Python ===

After that was working (and it might be tough to make work with any degree
of reliability and ease of use, as something easier, since I already have
a Smalltalk-like parse written in Python), I'd put a Smalltalk-like
mini-language on top of all this, but calling the Python class library.
That's to give the Squeakers just an early taste of what might be
possible, and also to provide initial hooks for the development tools to
be somewhat syntax neutral. Debugging support for non-Python syntax might
be fairly limited at this point though. The hardest part of that is
handling Smalltalk  blocks; but that could be done as cryptically named
functions for cases where they could not be inlined.

Other languages might be integrated if they were easy -- like Forth,
Scheme, and Logo, but again still using the Python libraries and object
model. However, doing any language beyond Smalltalk would easily be
deferred or delegated. Real users of these languages would be disappointed
since most of the effort in learning a language is learning the library,
and these would use Python's, but I think such an approach would suffice
for self-education purposes.

Still, this entire idea of supporting other languages could be dropped at
the start. But if it was, it would be more likely Python only features
would creep into the system, making it harder to add other later.
It seems though that multi-language integration is an interest of the
Shuttleworth Foundation, and it's something I like too.

=== order could vary ===

The next few activities could run concurrently depending on how much help
I got, but they would likely be done in the order listed otherwise.

=== HyperCard/PythonCard ===

I would proceed to add a simple HyperCard like system, possibly drawing
heavily on or possibly merging with the PythonCard project. This activity
might eventually drift into supporting prototype-based Morphic-like
Python-drawn widgets as it iterates down the road. It would involve
settling on a good cross-platform widget approach. I think wxWidgets is
still the strongest candidate here for a variety of reasons I could
discuss later, including choice by the Open Source Applications Foundation
for Chandler, and especially as it can run alongside OpenGL.
   http://www.wxwidgets.org/opengl.htm
But I definitely would need to look at Mozilla widgets more based on
discussions here. Defining resizing rules is always a big issue in
dynamically placing components, especially if you want the results to be
cross-platform; I would probably ignore that at the start.

=== stress testing by porting a constructivist application ===

After basic Hypercard compatibility, and widget choice, I could then
stress test the system by porting to it at least one (and preferably all
three) of our educational applications written in Delphi -- our Garden
Simulator, PlantStudio Software, and our StoryHarp software (which would
be under the GPL). I already have a Delphi->Python translator that did
much of the heavy lifting on that, and have lots of Python code, but I
still need to tie them to a specific Python widget set. Adding some more
polish to this translator and releasing it might also hope make the
framework of interest to Delphi developers. These applications could
all be used either for unschooling or as part of school curriculum. Two of
them are graphics intensive and use a 3D turtle, which as a unit could be
broken out separately under the Python license, and would later form the
basis for supporting Logo like capabilities and simple 3D graphics
projects (though Logo language support would come later). This phase might
really be more about tweaking the browser, debugger, inspector and related
socket code than doing anything GUI related; wxWidgets would probably be
used extensively if the system is relying on CPython. But it is an
important one to make the system as bulletproof as possible.

=== eToys and Logo -- 2D ===

Once there was basic HyperCard-like support, and at least one full
educational applications was working, then it would make sense to expand
the system by making lots of eToys-like ideas. This would also be a
natural time to build in Logo type support, programmable by either code or
icons. I would see this as providing a rough 2D world support, more proof
of concept, with hope it would develop further later.

=== OpenCroquet -- 3D & networking ===

After that, there would be moving more into more complex 2D and 3D worlds,
inspired by Squeak, Croquet, LearningWorks, and Alice. At this point
things would be pretty open ended. Sometimes, I could adopt a "burn the
disk" packs approach of trying to learn from the best of these ideas
though perhaps not necessarily using any existing code. For something
like eToys, that's probably a reasonable idea. But obviously Croquet is
likely a different beast. Where Squeakland could offer core Croquet code
or other neat things as packages I could integrate and support, I might
just translate it to Python (probably with a tool) or alternatively
support it on a Smalltalk layer instead. OpenGL would be used extensively
here, again perhaps on wxWidgets. How this part would proceed would depend
a lot on what level of collaboration has been built with different groups,
especially Squeakland. I would have my own pet projects to build on this
level too (mostly simulations related to sustainable development and
manufacturing, self-replicating space habitats, and so on). Overall, this
last item is the biggest chunk of effort, and has the most uncertainty,
and the least detail, but I think most of the other projects make sense to
do first as steps to this because they would provide a solid educational
platform that Squeakers would respect. :-) On the other hand, in terms of
collaboration between Squeakland and Python, it makes sense to push this
part up to the first item, and try to do it concurrently with the other tasks.

=== schedule ===

No promises as to schedules; it would all ship when it was ready for
feedback. :-) But if it wasn't somewhat impressive by the end of this
year, and at least all but the last section weren't working somewhat well,
then I'd be disappointed (even if I was doing all the work myself).
Obviously, the last item would develop over the course of at least a
couple years.

=== project naming ===

I think an appropriate name for the system might be "PataPata", the name
of a South African song my family likes "just about dancing, singing and
having a great time":
   http://songsforteaching.homestead.com/PWM2PataPata.html
PATA could mean "Python Advanced Technology Applications"? But there might
be trademark issues with that; it's common. Variants of "Constructivist"
or "PyConstructivist" are other naming option. But I'm sure others could
have good naming ideas; Michael Tobis used "Squeathon", for example.

=== issues ===

To be frank, putting some money on the table would make it easier to get
my wife to let me to fully commit to this long term, though I myself would
rather pay for the privilege. :-) I'm mostly busy to mid-May. After that I
could put 1/2 to 3/4 time into it, if everything else made sense. It's a
lot of work, and a big commitment, so if someone else is raring to go and
wants to put even more effort into it, and knows more about both
platforms, or is a better match in some other way to both communities, go
for it. I do think I'm a somewhat good match -- with a knowledge of both
systems and communities (though rusty on the Squeak side these days); also
the project brings together a lot of loose threads in my life as a
software developer, so that motivates me to want to do it. My biggest
drawback is probably long emails when I get excited about something. :-)

There are certainly others who might be better at it (Cees de Groot is one
such person) but it's a matter of interest and availability.

--Paul Fernhout

Guido van Rossum wrote:
> I'm looking for someone to "own" the development of a Squeak-like 
> environment for Python. I can help by getting you in touch with Alan 
> Kay and other Squeak folks. But I just can't be managing this project 
> myself -- I need to focus on Python 3000, which has quite a different 
> set of goals (not incompatible, just different, and enough to keep me 
> very busy in the next two years).
> 
> To provide some background, here is (with permission, and slightly 
> edited) a forwarded message from Mark Shuttleworth in response to 
> something I sent him this morning.
> 
> --Guido
> 
> ---------- Forwarded message ---------- From: Mark Shuttleworth 
> <mark at canonical.com> Date: Apr 22, 2006 8:56 AM Subject: Re: Moving 
> forward the educational Python code development To: Guido van Rossum 
> <guido at Python.org> Cc: Kirby Urner <urnerk at qwest.net>, [...]
> 
> 
> Guido van Rossum wrote:
> 
>> After Kirby's posts and mine on the Python mailing list for the 
>> education Special Interest Group (edu-sig at Python.org), several 
>> threads have spun up showing that there is a lot of interest in the 
>> topic of making Python more "Squeak-like", however you might want to
>>  define this.
> 
> 
> This is great news.
> 
> My sense is that it will take three or more years to get a Squeak-like
>  environment built up in the Python world. It will take a lot of work,
>  more raw development work than TSF is willing to fund. Our project 
> deliverable is the curriculum and the training program for teachers to
>  teach it, we don't want to be responsible for delivering the unified 
> development environment  through we recognise that having a unified 
> environment is beneficial to the project.
> 
> The only way the unified development environment will actually happen 
> is if the SqueakLand community, with Alan's leadership, makes this 
> their goal, and figures out how to work with the Python community. It's
>  the SqueakLand folks who understand what that environment needs to 
> "feel" like. They have the strong vision as to what the tools should 
> do. At the same time, the Python community will need some people to 
> step up and welcome that effort, contributing to it over time, because
>  the SqueakLand folks are used to Squeak and they will need to learn
> how best to execute their vision in Python.
> 
> TSF can provide some limited funding, but we're not setup to lead 
> development efforts (we learned the hard way with SchoolTool which is 
> now in good shape). Most of the TSF funding will go towards actual 
> curriculum development that USES the tools available. We will initially
>  use Logo, Squeak and Python as-is, because they are there right now, 
> and will develop the curriculum using what's currently available with a
>  view to consolidating it all around Python as Python gains the ability
>  to deliver Logo-like and Squeak-like environments.
> 
> 
> 
>> I believe now is the time to delegate to someone other than me the 
>> task of researching the course of action; what exactly is needed, 
>> which toolkit to use (e.g. Mozilla, pygame, OpenGL, or something 
>> else?), and to manage the development. Unfortunately I don't have the
>>  time to do this myself. Does the Shuttleworth Foundation have 
>> resources to pick up this project, now that there's momentum building
>>  up?
> 
> 
>> This could take the form of an existing Shuttleworth employee jumping
>>  in, or some Foundation money to get one of the interested 
>> contributors (perhaps ) to put in their time (part-time). I don't see
>>  this happening (at the time scale envisioned) on a purely volunteer
>>  basis. I'm sure we can get volunteers to do coding for the project;
>>  but managing it, researching the possible options, and making 
>> decisions probably requires someone dedicated to this task.
> 
> 
> Yes, agreed, and we can contribute some funding towards the leadership
>  of the effort. I'm not keen to fund "part time work with no clear 
> deliverables" because its hard to get predictable results that way. I 
> guess what we need are you and Alan to figure out between you who will
>  make the most effective leader, bringing together the SqueakLand
> vision in a Python execution, and we would step up to fund portion of
> that person's time.
> 
> [...]
> 
> I think the leadership of this effort needs to be decided after 
> discussion with Alan too, so that whoever is the funded driving force 
> has buy in from both communities. If you'd like to forward this message
>  to other folks in the community as a statement of the parts TSF is 
> able to contribute to, please do.
> 
> Mark ---------- End forwarded message ----------
> 
> -- --Guido van Rossum (home page: http://www.Python.org/~guido/) 
> _______________________________________________ Edu-sig mailing list 
> Edu-sig at Python.org http://mail.Python.org/mailman/listinfo/edu-sig