SugarLabs "evolved" from OLPC with a wider goal to provide an instructionist GIU and computer learning environment for elementary school age kids all over the world.
It's engineering goals call for a (Linux) OS and hardware-agnostic platform, with transparent, free and readily accessible and modifiable code that can be also easily shared among users. The normal user has absolute control over the Sugar part but the core system remains secure from malicious activities.
One aspect that was explicitly stated in the OLPC project but is not even suggested by SugarLabs is environmental concern and energy (code) efficiency. The other aspect that was not addressed either by OLPC or SugarLabs is if free and accessible implies "as long as you do it a certain way".
With SugarLabs maturing and Sugar approaching its 1.0 version I think it worths taking a look at some of these trying to minimize prerequisites and established practices, and see a) if all these are feasible b) if the implemented approaches can achieve them and c) at what cost.
I'm obviously not offering an expert opinion, but rather trying to bring up some issues for (re)consideration. Experience shows that evolutions of goals and ideas tend to curry a lot of the previous practices and components that can actually trouble your progress down the road. I'm not necessarily suggesting to redesign Sugar, but rather (in Linux terms) to (re)define the tree and do an extensive garbage collection.
One GUI?
Although the age-target group of Sugar is not rigidly defined and is ranging for 6 to 16, let's stay with the Uruguay paradigm and say elementary school kids. So the first obvious question is if ANY GUI can be equally appropriate for a 1st grader that can not read and hardly have the motor skills to use a computer and a 6th grader that may blind-type and use keyboard shortcuts because the mouse slows him/her down?
The second obvious question is, given the diversity in kids development/aptitude, if for any given age/class there is a minimal common ability denominator to be based on? If yes, is this "common denominator" sufficient to build a GUI around and is this "common denominator"-based GUI will actually be any good to anyone?
And the third obvious question is how any given GUI can be cross-caltural without imposing a "cultural imperialism"?
Linux is trying to address these issues in the adult world by providing a multiple of highly configurable desktop environments. OLPC on the other hand provides both Sugar and GNOME trying to satisfy both young and older kids.
Sugar must become more configurable too. From plane icons and no text to two-level deep drop-down menus and everything in between if possible. Maybe in a fashion similar to the frame delay selection or the universal access mode. This would allow different user abilities and preferences to be implemented/accommodated.
It is not reasonable to believe that "one size can fits all" and if you do also to believe that this is going to be looking good on anyone too! But how do you decide which one is the best for any given age/ability group? There is only one way. Test with the given target groups!
Also decide what is you "user satisfaction goal" for your given effort/abilities. Going for 100% may end up in a monster structure. I believe that 51% is a good initial goal. Anything above that should be considered on a cost/benefit base.
Talking about garbage collection, may want to reconsider some OLPC XO-1 relics (eg low specs) like the luck of color. Children above all, should not live in a "grey world".
However, for all these to be successfully implemented I guess that the GUI itself should be build in a modular and easily configurable way. Similar to the activities. Components should be added and removed without affecting the remaining parts. I do not know how feasible this may be but modularity and customization are going hand to hand.
The additional benefit of modularity is that it may be adapted to a wider hardware abilities and satisfy user choices like responsiveness over features. I can appreciate that this may generate a havoc with activity building, but to the extend that clear APIs and instructions are there, you can only hope that developers will follow suit. The alternative is "one size-fits-all" and even worse, every change breaks compatibility with pervious builds/apps and introduces a cycle of debugging/rebuilding.
Only (one) Interpreted Language(s)?
From the beginning OLPC and later SugarLabs made one fundamental choice. Sugar code should be _readily_ available to and modifiable by the user. This was translated to "try to do everything in python" that was taken a step further, I guess also because of the XO-1 space limitations, to "do not use/keep python compiled binaries" (the .pyc files).
Python may be great but the specific implementation introduced a major burden in lowspecs hardware, increased energy consumption (CPU cycles), wasted time (multiply few minutes of waiting per day with millions of users) and frustration (patient is not a characteristic of young age).
The argument is that this option increases programming literacy and freedom. However, if nothing else Sugar already has plenty of programming applications including Python. If the need for seeing and modifying application code arises (not the most common need for 7-12 year old) you can have source code provided with all apps.
The issue of limited storage space could be taken care by the School server or the internet that could keep and distribute source code files on demand. Will be some delay and the (non functioning) "view source" button will not work, but comparing to the overall delays introduced by the current scheme the choice should be clear.
But python has run-time code evaluation, someone will argue. True, but this is a convenience for the developers mostly (if not only). Them doing their work faster/easier and everybody else paying the bloat/delay price can hardly be an "educational" justification. But python looks like real spoken language. True, but other languages do it and some without the bloat. What about gnome's newer addition, Genie? Python-like syntax, no VM under, no 10 layers to get to processor, use of existing libraries, C-like performance. Should it be "banned" from Sugar?
The multiple programming language/binary packages approach on the other hand will:
- allow the most appropriate language to be implemented for any given task,
- attract/utilize developers with different programming skills,
- allow easier use/adaptation of existing apps without reinventing the wheel for everything
- increase program execution speed and efficiency
- allow exposure/teaching of multiple programming language instead of just one
- teach a mainstream programing skill eg compile/debug apps from source
- improve compatibility/distribution with other linux distros.
I certainly do not suggest to rewrite Sugar from scratch. It could start with always keeping and using the .pyc files (as it is done for some core elements and indeed many activities lately in Sugar 0.84+) and open the door to other language and the binary/source code scheme. Allow the use of non-python languages (maybe with a python wrapper if needed) for now and encourage more energy efficient languages for the future.
I can imagine that this may create other technical/operating problems but this approach is something that has been used and solved in most of the standard linux distributions (including the Fedora core mostly used by SugarLabs) that utilize packages written in all sort of languages.
Mavrothal as this question first on OLPC News Forum
Know what's happening with Sugar - subscribe to OLPC News via RSS Feed, Email or Twitter
.
So far the most successful use of Sugar used for learning, OLE Nepal's, depends on nothing uglier than Flash. Thus absolutely no real opportunity to modify the source code, etc. But it works where it counts, i.e., for children to use the XO as an actual tool for learning, to support areas where their teachers are not very skilled, etc.
Bottom line, let's .pyc, if that works to get the XO to be nimbler. Better code and better practice, lower costs, is better than bloat. Excellent article, Mavrothal, thanks.
"...start with always keeping and using the .pyc files ... more energy efficient languages ...
I can imagine that this may create other technical/operating problems ..."
Mavrothal raises some interesting questions and challenges in his article. However there is an undertone of cynicism about the motivations of the Sugar community. He suggests that community has "banned" efforts to support the diversification he is advocating. On the contrary, to quote community member David Farning, "Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants."
In regard to some of the specifics:
(1) Thanks to the efforts of Tomeu Vizoso, View Source has worked universally since Sugar v0.82. I don't know what Mavrothal refers to when he suggests it is a "non-functioning" feature.
(2) Thanks to the efforts of Bert Freudenberg, Sugar supports Smalltalk development (e.g., Etoys) and that environment is being used by many activity developers. Bert has been very supportive in irc and on the lists for those who have been interested in developing bindings for other languages.
(3) Speak of which, Yama is correct in saying that there is a great deal of Flash being used in Nepal, but the major development push in Nepal is around Javascript development, with support from the Sugar community. We have also been working closely with Rob Savoye and the Gnash team to make Free implementation of Flash available within Sugar. One advantage of Rob's tools is that they include facilities for authoring, not just consuming of someone else's content.
From Mavrthal's list:
1. allow the most appropriate language to be implemented for any given task
See #2 and 3 above.
2. attract/utilize developers with different programming skills
Any help you can offer in this regard would be greatly appreciated. We've been trying to reach out to the GNU/Linux communities at forums such as LCA and the Desktop Summit. We just held a joint "camp" with the GNOME Ziegiest team. (Going into the camp, they were as misinformed about Sugar as Mavrthal seems to be, so clearly we are not doing as good of a job as necessary getting the word out.)
3. allow easier use/adaptation of existing apps without reinventing the wheel for everything
Not sure what you mean here. Some specifics would be helpful.
4. increase program execution speed and efficiency
Tomeu has been working on Python introspection, which should help. We are also looking at alternatives, such as Qt, for a rebase on small platforms. This is hard work and takes dedicated people. Interested in helping?
5. allow exposure/teaching of multiple programming language instead of just one
In addition to Python, Javascript, Logo, and Smalltalk, Csound is now shipped with Sugar. On the OLPC XO, there is also a Forth environment shipped with every machine. And yum install gcc is always available.
6. teach a mainstream programing skill eg compile/debug apps from source
To whom? Elementary school children? Actually, for the older children, I'd take it a step further and introduce them to tools such as git.
7. improve compatibility/distribution with other linux distros.
Thanks to community efforts (Aleksey Lim, Jonas Smedegaard, Sascha Silbe, Rubén Rodríguez Pérez et al.) Sugar is now packaged with most of the mainstream GNU/Linux distributions: Debian, Ubuntu, Trisquel, Mandriva, Caixa Magica, openSUSE, Gentoo, AltLinux, and of course, Fedora. Not sure what "other" distros you have in mind.
Again, you raise many important points. It is time to write some code.
Kind of you to respond.
I do not intent to get into any long discussion. Just some clarifications.
Regarding the "the non-functioning view source button" is referring to the XO button.
Regarding python's exclusivity. It is true (and indicative) that some major Sugar _activities_ have just a Python wrapper (Etoys, Browse) and is also true that even this wrapper is a source of problems (for both). However, this was a necessity rather than choice and I can point to a number of dev posts that the comment (some of them by you) on adapting/developing an activity for Sugar is "(re-)write it in python".
Regarding Flash (and now HTML5/Javascript in Karma) and OLE Nepal, these are server-side applications. In Sugar they just use the Browser.
Regarding TV's (and of the entire python community I might add) efforts to speed up python is just a testament of what size a hog it actually is...
Regarding compatibility with distros I'm referring to Python (again) 2.6 and Debian, a/the major linux distro.
I'm glad to hear that alternatives are entertained and hopefully will not remain lip-service, but the fact is that python is the ONLY Sugar development language as of today.
In any case, is not clear to me if your position is that python was/is a well thought-out educational choice or a circumstantial/convenience one.
(BTW I'm really curious to know how the original OLPC/Sugar team decided to use Python in an energy conscious machine).
I don't understand the complaint about Python exclusivity. Sugar teaches programming in Turtle Art (directly in tree structures, rather than text), Python, Smalltalk, Scratch, and Logo, and offers FORTH (currently without lessons, but some of us are working on that). You are welcome to provide other languages, and materials to teach them.
The only limitation that I am aware of is the limited memory and storage capacity of the XO-1. This limitation will go away within a few years in accordance with Moore's Law.
I do not "complain" about the available languages for teaching. I "complain" about the available/allowable languages for _development_ for a number of reasons mentioned in the text.
But you in particular among all people (as an Earth Treasury founder), I would think you would be more sensitive to the energy waste that Python brings.
Just add a bare minimum of an additional 1Wh/day/user and multiply by the target audience... Then consider the target countries to exaggerate the impact!
And Moor's law does not change things. Additional CPU cycles will always demand additional energy.
I have a natural inclination to poo-poo Python for low-end hardware; I write software for low-end ARM-based hardware myself and it's tough enough to get the performance I need, even in C++. The 400 MHz chip I develop for is typically 20 to 30 times slower than the same code running on my desktop PC at 2.13 GHz.
However, as a programming language for children, Python is very good. An interactive immediately-executing interpreter is really handy, and interpreted languages tend to "keep simple things simple": you don't have to write lots of boilerplate like "#include", "using", "classes", "namespaces" or "public static void Main".
I wish there were some language that had performance at least as good as Java (via static typing and JIT) with an easy syntax, code that can be modified at run-time, and an "eval" function (the latter, of course, is unavoidably slow, but still a good thing to have). Boo is okay, but the language is not optimized enough, and I don't think it has eval.
So there just isn't a good candidate that is both user-friendly and efficient.
Mono with IronPython might be an enticing possibility, since any time performance (or low power consumption) is important you could write the speed-sensitive module in C# and seamlessly call that code in Python, without writing any extra code to bind the two together. But with Linux lovers being allergic to anything MS-related, an approach like this doesn't seem likely to take hold.
By the way, can't pre-compiled modules like pyc files be kept around yet? Memory has become much cheaper since XO-1 came out.