Native-looking programs in Smalltalk with WxSqueak
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:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
Compiled versus inrerpteted isn’t really the issue here there’s no reason why a system can’t compile the source code down to machine code (so that it’ll run faster than an inrerpteted system) while still keeping the source code handy so that it can be tinkered with and recompiled on the fly. Plenty of systems do that, including various JavaScript implementations, as well as lots of implementations of other languages like Java and Smalltalk and so on.But you’re right, the standard way to distribute a program written in (for example) C++ is to compile it down to something that has no more connection with the source code. When you run the program on your machine, there’s no way for you to point your mouse at a widget in the running program and say show me the source code for this, because the executable file doesn’t even contain the source code. That’s the thing that I think is sad. As long as the code is under an Open Source license, and as long as there aren’t any technical reasons (like limited storage space) for not wanting to have the source handy, we might as well include the source with the executable, and offer a way for users to easily see how the source is connected to the things they see on the screen.
By Sujatha on Dec 12, 2015
I agree with you, maybe this idea is not taken seriously because of security issues, but I wish there was a simple way to do this using traditional languages such as C++ and Java.
By coliveira on Dec 30, 2015