From time to time I like to check on the evolution of dynamic languages, just to see what I am missing as a Java/C++ programmer. It is always an interesting travel, and each time I feel that the future will be really far away from the C-like languages that we currently use.

Last week, I spent a few hours taking a look at the progress of Smalltalk. In the Smalltalk camp there are several contenders for the best system, and it is not at all clear what the most productive system is. I have already tried VisualWorks, which is a cool environment. Although it is easy to use, there is the problem that it is closed source. This makes it practical to use VisualWorks only on commercial software, instead of writing open source software.

Even when doing commercial work, most companies will not invest money in an IDE for a language that they don’t know — which makes the barriers to use of a commercial Smalltalk is even bigger. Of course, there are several companies using Smalltalk, but there is always a specific reason for this — if you can’t find that reason you are out of luck.

Squeak

For this reason, I think an open source solution is the best bet for SmallTalk to succeed. And the best open source implementation of Smalltalk is of course Squeak. The only thing that I had against Squeak is the fact that they still insist in using a particular GUI that is completely different from any other UI in use nowadays. In fact, Squeak notion of UI is basically a copy of what a GUI might have looked like in 1980, when SmallTalk was being developed.

In particular, the idea of Squeak practically forcing users to rethink the way they use the mouse is absurd. In Morph, the Squeak GUI, every mouse action depends on a three-button mouse. To add some confusion, buttons are named by colors (instead or right-or-left button), so you need to remember what color is left or right. Many operations also require the middle button (represented by still another color), and if your don’t have a mouse with three buttons you probably need to simulate that one with control/shift combinations.

Imagine if I created a software that remapped the keyboard, and decided that each key would not produce the results that you are used to, but instead the combination of letters that I decided. Of course, you would dislike this program (to say the least). But this is exactly what Squeak requires from the user, who needs to relearn how the mouse works.

Squeak and WxWidgets

Hopefully, Squeak, being written in Smalltalk, is not totally bound to the decisions made by its creators. One thing that can be done is to use a separate UI, and disregard totally the mess of Morph. This was the route taken by the guys that ported WxWidgets to Squeak — resulting WxSqueak. WxSqueak is an extension to Squeak that implements the WxWidgets UI library. WxWidgets is a full featured GUI library that is supported on most platforms, such as Windows, Linux, and Mac OS.

With WxSqueak you can create SmallTalk programs that use the WxWidgets GUI, and therefore have a native look and feel. Thus, you can create a Windows program in Squeak, with native windows, toolbars, and menus. There is no need to program in another GUI such as morph, and make your users learn a new GUI paradigm just to execute your program.

WxWidgets is still in its early stages, but I found it very feature complete. Since it uses WxWidgets, which is a mature library, there is a large number of graphical controls that can be used from your program.

In the next weeks, I will be providing an example of a program written with Squeak and WxSqueak. I be also writing about some of the features of SmallTalk and Squeak that make it so useful for programmers in general. Keep reading, and I will add more details in future posts.

Suggested Reading

Smalltalk Best Practice Patterns, by Kent Beck

Smalltalk 80: The Language (Addison-Wesley Series in Computer Science), by A. Goldberg and D. Robson

Similar Posts: