Hi folks. I wish to make a radical proposal:<div><br></div><div>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.</div>
<div><br></div><div>This isn't a problem: it's an opportunity!</div><div><br></div><div>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.</div>
<div><br></div><div>"But these OSes aren't geared for learning!" you might respond. Neither was Linux, until Sugar arrived! Nor was GNOME!</div><div><br></div><div>First, let's take a serious look at where we *actually* are with respect to self-programmability of Sugar.</div>
<div><br></div><div>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!</div><div>Python is a great pedagogic language, but the best tutorials to show how Sugar can be hacked start by teaching kids vi!</div>
<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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!</div>
<div><br></div><div>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 eager to teach HTML and Javascript. Further, Javascript interpreters in 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.</div>
<div><br></div><div>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.</div>
<div> --scott</div><div><br>-- <br> ( <a href="http://cscott.net/">http://cscott.net/</a> )<br>
</div>