Because it's powerful.
Even with XO laptops readily available now there are quite a lot of reasons why one would want to emulate it on another machine. One being to hook up a projector. Unfortunately there are quite a number of hoops (*) one has to jump through to make it work. Anyway, I made a virtual machine that allows me to emulate the XO in VMWare on my Mac, running Sugar in the XO's native 1200x900 resolution, scaled down to a nice physical size in a window on my regular screen (fullscreen works, too). Sound works (even Tam Tam), Browse works (so networking is good), and after setting a working Jabber server I do see other XOs in the neighborhood view (Chat worked fine). Camera and mic are half working (Measure crashes, Record shows blank picture, but reportedly does record video), and a "Sugar restart" does not actually restart Sugar, but apart from that it seems fully functional, and much nicer than the emulations I had used to date. Click to see actual screenshots (calibrated to mat...
Comments
I'm also interested in ways in which Smalltalk is not powerful, in order to see what can be done to improve things. As with your comments on profiling, I like to be able to measure stuff. One way I like to measure the power of a programming language is to measure the cost (in lines of code) of making a change. This raises two issues in my mind:
1. In the Crqouet code that I've seen, a lot of code is duplicated between classes. Initialize methods do a lot. Operational methods in analogous but non-inheriting classes end up repeating the same (or nearly the same) code. So making a simple change often requires making the same kind of change in multiple places. The bigger the code base, the more often I have to do this. It's just cut and paste, but it's a lot of cust and paste. I hate cut and paste. It offends me. The way this is avoided in my former favorite language is with multiple inheritance. (Including multiple overridable inheritance of initialization methods.) I understand that there are people who have issues with multiple-inheritance -- or ANY form of class inheritance. OK. Maybe that's not the answer. But I would like to address the problem in some way. Any thoughts? I find myself drawn to delegation techniques, but I don't have much experience with them.
2. There's a fair amount of setup and boilerplate that have to do with getting related objects to cooperate and initialize themselves properly. In my formerly favorite language, this was addressed with macros. Instead of writing application-specific stuff directly in the language, you typically create a domain-specific language using a few macros that you write once, and then use that language to create the application code. When issues arise for performance or interfaces to external systems, we change the macros rather than the boilerplate that is distributed throughout the code. Again, any thoughts?
I like to see the cost of making a change be proportional to the the application-domain scope of the change. (I don't have a good way of measuring the application-domain scope of the change. All I have is a subjective feel. But the general idea is that "easy" things should be easy.) In both of the situations I describe, the cost of making a change ends up being proportional to the size of the code base.