Ralph Johnson - Blog

The last few weeks I've been looking at Pavel Krivanek's project to break Squeak into smaller modules. Unlike most people, who start at the top and try to carve out pieces, he is starting at the bottom. He has developed several images. KernalImage is a Squeak image without any GUI. It has collections, numbers, classes, the compiler, but little else. It has a text-based UI that can evaluate Smalltalk expressions, and it can load files from disk. Pavel has a fileIn for Monticello, so then you can load any other package, as long as it doesn't have a GUI.

His other image is called MinimalMorphic. He has a Monticello package for it, so you can load it from KernalImage. MinimalMorphic isn't particularly minimal, but it has had some stuff (like eToys) removed and I think he wants to remove more. It is a basic Morphic environment, showing that you can separate MVC from Morphic.

KernalImage is 2.8 megabytes, which is a lot smaller than the 15 megabytes of the 3.9 release.

The really cool part is that all this is generated from a model of Squeak. He has a "bootstrapping" system that has a model of Squeak in Squeak. You can start with the final 3.9 image and fileIn a model of the KernelImage. His system will figure out what needs to be deleted from the image and create a fileIn that deletes everything that shouldn't be there. Then you start with a fresh 3.9 image, fileIn his deletion script, and you get the KernelImage. You can then use Monticello to load MinimalMorphic.

I found it hard to do much with KernalImage except to load MinimalMorphic. Pavel says you can load Seaside and that there is a Seaside app that will let you browse code in the image. But the way I have looked at the classes in KernalImage is to load the bootstrap environment.

Pavel keeps his sources at http://www.comtalk.net/Squeak/98

To get an image with the model of the KernalImage in it, unzip bootstrap-7067.zip

Then, starting with a 3.9 release of Squeak, file in

- mirrors exporting fix

- ChangesOrganizer

- wait2ms

- Bootstrap

- Bootstrap-Tools

- Mirrors

Open a "mirror browser" with MirrowBrowser open, and you can browse the KernalImage classes.

The whole system is undergoing change. But I think it represents the future of Squeak.

Spotted in Blaine Buxton: Positronic Vibrations From Alto Dorado

Blaine's article gave me the idea for a new Smalltalk motto: Smalltalk: See the future!

Do you want to know what software will be like in ten years? In twenty years? Learn Smalltalk.

Spotted in This TAG is Extra

Travis asked a question about the use of exceptions in Smalltalk, and Eric commented that JoelOnSoftware suggests that exceptions are a bad idea and should be avoided. Of course, Joel doesn't know Smalltalk, and his experience with exceptions is in C , Java, and C#. I have no experience with exceptions in C , or with anything in C#, but the problem with exceptions in Java is that they are part of the type system, so you have to know when you are calling a method whether it can raise exceptions. A component that uses exceptions is harder to use than one that doesn't. When I am starting to use a component, I don't want to handle exceptions. I am happy for the debugger to handle them for me. I gradually add exception handling. It is harder to do this in Java than in Smalltalk.

Of course, this flexibility comes at a price. Smalltalk makes it easy to start using a component, but harder to build an air-tight application that uses it because it is not easy to discover all the exceptions that you ought to handle. It would be useful to have a tool that would let you browse all the exceptions raised in a package. You can do this now by looking at all senders, but there are a lot of messages for raising exceptions (though some aren't used much) and sometimes components don't raise exceptions directly but instead send messages like error: that raise them.

The problem that Travis pointed out was that sometimes people make a subclass of Error and sometimes they just use Error. He wanted to know which was best. My answer is that when I am making a class, II usually start by just using error: to report errors and then I later convert them to subclasses of Error when I want to make it easier to handle them. Some errors need to be handled, others don't. In general, if you don't know what to do about an error then it is pointless to handle it. So, use error: when you don't expect people to handle the exception, and make a subclass of Error and raise it when you do expect people to handle the exception.

The difficulty with this answer, of course, is that we change our minds. The person who wrote the class might not think that anybody would want to handle the exception, but the person using it wants to handle it anyway. So, we need better ways of refactoring exceptions. This is obviously related to the tool for browsing exceptions that I mentioned earlier. It is non-trivial to discover all the exceptions that a message-send might raise. It is non-trivial to find all the places that a an exception might be handled. We need to know the first to make programs bullet-proof, and we need the latter to refactor an exception from a use of Error to a use of a subclass of Error.

Spotted in Blaine Buxton: Positronic Vibrations From Alto Dorado

Kyma is a music composition system that gives you control over every bit of the soundwaves. It is popular with people who create far-out music. It was used for sound effects in some of the latest Star Wars movies. It is the fastest real-time synthesizer that doesn't rely on canned algorithms but gives you total control over waveforms. And it is programmed in Smalltalk.

Actually, only part of it is programmed in Smalltalk. The music is generated by an array of digital signal processors. The UI is written in Smalltalk and generates code that runs on the DSPs. So, the actual code that produces the music is produced by Smalltalk, but isn't Smalltalk. Nevertheless, it is an impressive system.

It is produced by Symbolic Sound, a small company in Champaign, Illinois. The principles are Kurt Heeble and Carla Scaletti, who have PhDs in electrical engineering and music, respectively. Kurt learned Smalltalk first, and suggested that Carla take my object-oriented programming class to learn it. She already had the vision for Kyma when she took the course, and I got to see the first versions of it. Kurt had built a DSP for his MS project, and she used it for the first version of Kyma. After looking for computer music jobs in academia and not finding them, they decided to start a company and commercialize Kyma. They are some of the few computer musicians who make a living in the industry. Of course, part of the reason that they are able to come out with new products regularly in spite of the small size of their company is because they use Smalltalk.

I noticed that James Robertson is reading Eric Sink. I've known Eric for a long time. He took an operating systems course from me 15 years or so ago and has been making guest lectures in my senior project course for three or four years. It might not be obvious, but he lives in Champaign-Urbana, like I do.

Eric is on a kick talking about marketing for software people. Java taught me the importance of good marketing. Eric makes snide comments about Java marketing, but Sun actually did a good job persuading big companies to adapt Java. Unfortunately, there aren't any big companies pushing Smalltalk, so it has to be done by smaller companies and users. Eric runs a small company, and he is talking to small companies.

Eric said:

Don't try to create a "better" product. That strategy is too vague. Instead, try to create a product which is better for a specific group of people with specific problems that are not being solved very well by others. That specific group of people will perceive your product as the best.

Programming languages are general tools, and can be used for all kinds of problems. Therefore, it is hard to apply this advice to Smalltalk. When Smalltalk was first commercialized, it was used to build unusual user interfaces, such as ones that used windows and mice. As windows and mice got old hat, Smalltalkers discovered tht it was good for client/server computing. ParkPlace and IBM were so focused on client/server computing that they missed the start of the internet. Now Cincom has refocused on the internet, and the product is good, but few people who do not already know and love Smalltalk find it compelling? How can any Smalltalk, including VisualWorks, be best for some specific group of people with specific problems?

What is the elevator pitch for Smalltalk?

A group of six good Smalltalkers can do in two years what twenty good Java programmers could do in three.

Is this convincing? Defensible? We think it is true, but why hasn't the world been convinced? Or is this not the important issue?

Michael Lucas-Smith discussed the problem of sandboxing in VisualWorks. The problem is the same in most of the Smalltalks. Brian Foote and I have been talking about this off and on for years.

It would be possible to make a crippled VM and do all the security checking in the VM. This is what Java does. However, I (like most Smalltalkers) would like to have an image that is running my application be able to import code without worrying about whether it is secure. What sort of bad things could imported code do?

The main bad thing that could happen is that imported code could change existing code. Smalltalk makes it easy to change code. "Obect compiledMethods removeKey: #copy" will remove the copy method from class Object. It would be very bad if imported code could do this to a running application. We also want to prevent programs from acting like a debugger and changing the value of temporary variables on the stack. In general, we can divide objects into sandbox objects and real objects. Classes and contexts (the objects that hold the temporary variables) are real objects. We do not want sandbox objects to access the full interface of real objects. Sandbox objects can't send instVarAt:put: to a real object, though it is OK for them to send it other sandbox objects. We need to have a way to restrict the messages that an real object will accept from a sandbox object.

The solution is proxies. The sandbox should never refer directly to a real object, but should always refer to an object (the proxy) that refers to the real object. This is what Les Spoon does, though he doesn't describe it this way. He describes an implementation for Squeak.

There are two parts to this problem; the mechanism and the policy. The mechanism is that part that makes sure that a sandbox object never refers directly to a real object, but that all messages go through a proxy. The policy is that part that decides which messages should be passed on by the proxy, and which should be blocked. These are both hard problems. However, one way to make the mechanism easier is to actually run the code in a different image, i.e. a different address space. I started off by saying that I didn't want the sandbox to run on a crippled VM, but I wanted to run it in my main image. Why? A system that forces everything to run through proxies is just as much work as a distributed system. If we made a separate image for the sandbox then bugs in the mechanism would let too little information get through, instead of too much. We'd still have to worry about getting the policy right, but at least the dangerous bugs would be in the policy, not the mechanism.