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 > <[EMAIL PROTECTED]> Date: Apr 22, 2006 8:56 AM Subject: Re: Moving > forward the educational Python code development To: Guido van Rossum > <[EMAIL PROTECTED]> Cc: Kirby Urner <[EMAIL PROTECTED]>, [...] > > > Guido van Rossum wrote: > >> After Kirby's posts and mine on the Python mailing list for the >> education Special Interest Group ([email protected]), 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 > [email protected] http://mail.Python.org/mailman/listinfo/edu-sig _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
