[IAEP] For Sugar Everywhere, Google-ize!
C. Scott Ananian
cscott at cscott.net
Wed Feb 16 14:09:00 EST 2011
Hi folks. I wish to make a radical proposal:
Sugar's days on OLPC hardware are numbered. Sugar as presently written is
not developing quickly enough, and hasn't made significant progress towards
supporting the new touchscreen devices coming down the pike.
This isn't a problem: it's an opportunity!
I believe that SugarLabs should radically embrace "Sugar Everywhere". In my
opinion, this means attempting to target Android or ChromeOS with Sugar
activities as quickly as possible.
"But these OSes aren't geared for learning!" you might respond. Neither was
Linux, until Sugar arrived! Nor was GNOME!
First, let's take a serious look at where we *actually* are with respect to
self-programmability of Sugar.
There isn't a serious IDE. None of the Sugar software is accessible via the
Journal. Much of it is actually writable only by root!
Python is a great pedagogic language, but the best tutorials to show how
Sugar can be hacked start by teaching kids vi!
Viewed dispassionately, we have fallen very short of the 'view source'
ideals, and activities like Scratch or Etoys provide a much better pedagogic
introduction to programming than attempting to read through the python
sources of Sugar does.
If Sugar were to rebase on Android, one of the first tasks would be to
figure out how to run as many of the existing activities in Android as
possible. This can be done via projects like Jython, which implement Python
in Java, and by reimplementing some of the underlying Sugar collaboration
and storage services. The activities are the most important part of Sugar!
We don't need to reimplement the frame, or activity management, or
networking configuration (at first) -- take advantage of the hardware
support of Android and build on its OS services, and concentrate SugarLab's
limited energies on the activities.
In addition to getting Scratch/Etoys/Speak/Pippy to run on Android, the
Sugar community can contribute a simple Java compiler to make Android
more-fully self-hosting. Perhaps some small hacks to Android are needed to
allow it to install apps from its own filesystem. Android is open source,
go for it! The result may be a slightly tweaked android, but
Sugar-on-Android will be portable to hundreds of different low-cost phones
and tablets from any number of different manufacturers. Sugar everywhere!
Or perhaps consider rebasing Sugar on ChromeOS. Existing Sugar applications
could run in a plugin, or as a Chrome extension. In addition, new Sugar
activities could be written in *web standard languages*. In my travels in
South America, Python is still an oddball out-lyer. But universities are
browsers are many times faster than Python, and getting faster all the time.
Consider also that the "Chrome Debugger" is already a *much* better IDE
than Pippy, and already fulfills the most important goal of the "view
source" manifesto -- you can click on *any visible thing* on the webpage,
and see immediately what code produced it. We're still a very long way from
that goal in Sugar/Python. Again, we can build on the system support of
Chrome OS (starting apps, configuring networking, preferences, etc) and
build activities as web applications (which can use a special chrome
extension for additional services, including collaboration and the journal)
which can again run on a large number of different devices.
Portable devices are the future. Lots of manufacturers are already spending
enormous amounts of effort on hardware porting and all the UI and network
and system management tasks for their devices. Sugar shouldn't need to
reproduce this work, or be tied to particular hardware. By capitalizing on
the existing work done for Android or ChromeOS, SugarLabs can concentrate on
what makes Sugar great: strong support by educators, excellent activities,
and a focus on making the system introspectable and hackable.
( http://cscott.net/ )
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IAEP