Software Engineering Matters

Many people hear that the code browser in Squeak (or any Smalltalk for that matter) is designed for code browsing. In other words, the browser is optimized to help you read code.

However, I have found that reading code in the regular Squeak environment can quickly become a big mess especially if you are trying something out for the first time and need to read multiple implementations in different classes. Usually, when this happens, you end up with a proliferation of browser windows that quickly clutter your screen. I am assuming that veteran Smalltalkers don't find this a problem because:

• they know most of the methods so well that there isn't much need to refer to it
• they have LARGE monitors so 20 open browsers is not a problem
• they are just disorganized and don't give a damn about it

In this article, I am going to show you how to use the OmniBrowser with some new enhancements. The same group that made the OmniBrowser has also created a whole bunch of very nifty tools. I'll try to get to each one in separate articles. But before that, let me divert your attention to this very relevant message:

A Squeak Smalltalk Development Example:

"Most developers who use Squeak would have a plethora of extra tools and utilities installed that make developing a much nicer experience than what you see in this tutorial. Do yourself a favor and start your Squeaking with a real developer’s image loaded with all the proper goodies like the SqueakDev image maintained by Damien Cassou."

So at this moment, I am going to insist that you download one of the excellent images maintained by Damien over at his webpage. Don't even bother using the basic squeak image. The basic image is pretty disheartening and discouraging to any new developer who is trying Squeak for the first time. Since Squeakers are usually developers, I have always found it mind-boggling that the standard Squeak image does not include better support for developers out-of-the-box. Instead, it is cluttered with a lot of stuff that most developers don't care about.

For this tutorial I am using the squeak-web/beta version from here. Don't forget to grab the SqueakV39.sources file from here as well.

Here's our scenario: we want to see how to actually implement the relevant methods so that two objects can be compared to one another for sorting purposes. Here's a step-by-step guide to how I would use the OmniBrowser + enhancements to do it.

Open the SmartGroup Browser
Bring up the World Menu in Squeak and select the SmartGroup Browser.

Type in the '<' selector
In the top pane of the SmartGroup Browser type in '<'. The top pane is called the Mercury Pane and it lets you type in class/selector names and quickly displays it in the current browser for you. For more information about the Mercury Pane see this.

New window showing the implementors of '<'
A new windows pops-up showing the implementors. I think it is OK to have a new window pop-up with the search results. Also notice that this actually shows the classes in a hierarchical manner (by tabs). So you can see that Character is a subclass of Magnitude.

Search for 'Float'
Now back in the SmartGroup Browser, I am going to search for the Float class since I am interested in seeing the definition of the method for it. I am going to enter 'Float' in the Mercury Pane.

Split Panes in the Browser!
By doing a Shift+Click on a class/method you split a new pane with it!

Multiple Split Panes showing all the methods
By repeating the Shift+Click process, we can create as many split panes as we want. Usually it's enough to have about 4 of them. Also, don't forget that you can browse back using the '<<' button.

For comparison, this is what it would look like if we had to use the normal tools from the standard Squeak image. Look at the wasted screen estate and how I don't see any nice hierarchical information between the classes.

This is roughly what it would look like to find the '<' method in Squeak 3.10 without the new tools. We start by trying to look for the '<' selector in the Method Finder and then clicking on each method to see its definition. Notice that there can be no end to the list of new windows!

So I claim that by using the new tools, reading code in Squeak is much more organized. Good organization not only helps the developer focus but also makes it more approachable (and less intimidating) for a new user. Personally, I advocate that any new tutorial about Squeak be written with reference to these new tools. These new tools are hidden gems that need to be exposed to the world! Only by getting more people to use them can we:

• improve existing tools based on user feedback and experience
• actually get new tools to appear for Squeak - after all what's the motivation of creating new tools if everyone is just using the old way?
• change people's perception that Squeak's tools are 20-years outdated compared to more polished tools such as Eclipse
• make it easier for first-time developers to use Squeak. Seaside has already done a fantastic job garnering attention for Squeak and we should take this opportunity to make it easier for developers to get started

I also hope that people will be less close-minded about enhancing Smalltalk as evident from some of the comments in the following posts:

• Extending Smalltalk Syntax
• How Should We View Methods?

Of course, changes should be implemented judiciously but without an open-minded attitude toward change, nothing will change.

BOFs or Birds of a Feather Sessions allow people with common interests to gather and just talk about anything and/or everything about their common interest! This time I went for three BOFs, all of them focused around Squeak and Smalltalk.

The first one was on Tuesday evening and it featured several short talks by various people. I have to say that the highlight of that BOF was about the by-now-well-known XO laptop (formerly known as the OLPC laptop). We even had two demo units available for us to try out if we wanted. The XO laptop is a marvelously piece of technology for its price. Undeniably, it is built to withstand all the harsh conditions that it might suffer through. However, as mentioned by the presenters the biggest roadblock for this project might not be technology but the lack of actual educational contents to put onto the device itself. Right now, there are no official educational materials that will be installed onto the machines yet. And for a machine that is supposed to function as the all-in-one textbook replacement, this is a major predicament. In fact, it might be a serious blow toward the success of this system. And no one knows what is the best solution to this problem.

There were also two presentations on language tools for Squeak: OMeta and CAT. OMeta is a project by Alessandro Warth and is already available from SqueakMap. It's pretty compact and has some nice features for parsing languages. Alessandro has actually implemented a Javascript interpreter on top of it but the source is not yet available. CAT is another tool for language recognition by Jamie Douglas. It has more features compared to OMeta -- can support PEG and CFG, has better error messages, automatic AST generation and some AST rewriting. It's currently not released yet but from what I have seen during the BOF demo it is as good as ANTLR and I will definitely be looking into it. It might be fun and useful to create a simple IDE for CAT in Squeak like what AntlrWorks does.

At another BOF that I attended, Dan Ingalls did a presentation of the Lively Kernel project at Sun. Basically the project shows an implementation of a Squeak-like system in Javascript. Since Javascript is supposed to be cross-platform and runs on all modern web browsers, it is one of the best choices to implement this project in. And by taking advantage of the latest SVG features in new web browsers, one can actually create a lot of graphics without all the overhead of loading images. The demo for the Lively Kernel project is available from its website and runs fine on the Safari 3.0 and above.

The final BOF I attended was the Seaside BOF organized by Roger Whitney who is currently on sabbatical at UIUC. Unfortunately I arrived late for this BOF since I thought I have misplaced my keys and had to go to the lost-and-found office to check on that. I must have arrived more than halfway through the BOF since they were already going into the QA session. The attendees had very different backgrounds: there were some newbies like myself who have read about Seaside but have never used it and there were clearly some veterans who have worked extensively on Seaside. It would have been good if a quick walkthrough demo could have been done to introduce the newbies to Seaside development. Some attendees did raise some interesting questions. For instance, how many projects were using Seaside; what is needed to set it up quickly; which databases did it work with; what hosting options were available (besides hosting it yourself). Fortunately there is an up-to-date website, appropriately named seaside.st, that addresses those questions. I must say based on the short demo that web development with Seaside certainly has a different feel. It requires the developer to use all the tools from Squeak (or some other Smalltalk version). However, like Rails, once you have accepted the philosophy of Seaside, web development is certainly better than what it used to be.

There are lots of excellent introductions and tutorials on Squeak on there so this is not an attempt at another tutorial. Instead, this will hopefully be a condensed version of the information I would have liked to know the first time I use something like Squeak.

When you first start Squeak, your initial reaction might be something along the lines of: What is this thing!? You are probably in a state of shock and disbelief especially if you have been programming with text editors and the command line or use some nifty IDE. Squeak 3.9 actually has a more appealing interface compared to prior versions of Squeak.

After overcoming your initial shock, you are now ready to begin dwelling into Squeak. You should read all the initial documents that pop up when you first start Squeak. They contain useful information on how to get started. You should also be prepared to use a three-button mouse; while you can emulate the three buttons, having direct access to the buttons on your mouse makes you more productive. Squeak windows behave differently compared to normal windows in your operating system. You will need to click on the window using the right-mouse button to gain access to some of the window manipulation tools. Hover your mouse over each icon to get a description of what each does.

Here is what a typical development session in Squeak might look like. There will be a bunch of windows open as you develop in Squeak.

The main thing you should realize is programming in Smalltalk is very different from languages such as Java, Ruby, C#, etc. Programming in Smalltalk entails using its own system. You do not use an external editor, you do not really have a compile/execute phase, and you do not fire up FireFox to read documentation on the web! You even get some primitive form of source control without using CVS or Subversion! Everything for developing in Smalltalk in built-in. So when people refer to Smalltalk, they usually refer to the whole package. And yes, this does mean that you do not really have much of a choice if you would really like to use your favorite text editor.

I assume that you have done some of the basic built-in tutorials in Squeak and are familiar with how to navigate in Squeak. In the next few paragraphs, I am going to tell you more about the Squeak image and what you can do with it. I think this is fairly useful and will help you in case you did something wrong in your initial fiddling with Squeak and would like to find out what you can do to rectify it.

Everything you do in Smalltalk will eventually be saved in the image. The image is the file that you is named like Squeak3.9-final-7067.image. Accompanying the image are two very important files: the .changes file and the .sources file. Under no circumstance should you attempt to delete them (as I had in the past!) no matter how large they grow. I will explain one way to condense the .changes file in another post but for now leave it alone. For a short description of the purpose of those files, refer to here.

This image is actually a very useful. The closest thing that I can think of that is similar to a Smalltalk image is the image file that you use in VMWare. Even then there are subtle differences. Everything you do in VMWare is recorded directly into the image whereas in Squeak you have the option to just quit without saving the image. Note: This is a useful feature. If you think you have messed something up, you should always quit without saving. And when you restart the image, it reverts to the last time you actually saved it (where everything was hopefuly working).

What if you forget to save the image before quitting and you have just done a whole bunch of work? Does this mean that all your work is gone?! Fortunately it does not. Squeak stores everything that you have done in the .changes file. So you can always start with the last image that you have saved and then use the .changes file to get your stuff back in. This is a pretty cool feature and there is a video showing this in a different version of Smalltalk. To get the same features in Squeak, just left-click on the desktop, select changes..., select recently logged changes... and you have a similar menu where you can see the previous changes that you made.

What if you want to revert back to a previous version of the image after saving it? This is similar to version control and I will post more on that later. In a nutshell, there are two main ways to do version control: the changeset and Monticello. If you are new to Squeak, I suggest you just skip the changesets and take a look at Monticello. It is buit-in to Squeak 3.9 and most new packages that you might install are already using the Monticello format.

When you are just starting to get familiar with Squeak, it is always a good idea to keep a backup copy of the .image, .change and .source files. Even though there are tools that can help you restore the image, you might accidentally screw it up so bad that it is simply easier to just restore from a backup first and then try to apply your changes again.

Over the next couple of days, I will be explaining how to get hold of some tools that will make developing in Squeak more convenient for you. If you cannot wait, you can always try installing them on your own:

• eCompletion - Enables smart auto completion to the squeak system
• Shout - Enables syntax highlighting as you type in the code browser
• Shout workspace - A workspace that syntax highlights using Shout
• SVI - A text editor for Squeak that supports dozens of VIM and Emacs commands and modes. Useful when you really do not feel like picking up the mouse
• Whisker Browser - A browser that allows you to view/read/compare source code more intuitively

There is also a set of excellent screencasts for VisualWorks (another distribution of Smalltalk) available here. While the screencasts revolve around VisualWorks, there are similarities that make it pertain to Squeak as well.