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.

Squeak by Example:

"This book presents the various aspects of Squeak, starting with the basics, and proceeding to more advanced topics. This book will not teach you how to program. The reader should have some familiarity with programming languages. Some background with object-oriented programming would be helpful."

An updated book for Squeak is long overdue and Squeak By Example will fill that void. The book is still work in progress though a beta version of the pdf will be available soon. The Subversion repository of the LaTeX sources is available though and whoever is interested could generate the .pdf from that.

I find this book to be a positive step in introducing people to Squeak. I have commented before that a book is a physical manifestation of the quality and maturity of an open source project. If you dealing with a close source project then the company backing that project up could easily invest money into making documentation or even publishing a book in that technology. However, when dealing with an open source project -- where all documentation is freely available in the form of code as the proponents would claim -- the commitment to create a book shows just how much the community loves the product and want to get other people excited about it too.

A book shows commitment to the project. After all, why waste time writing a book if the project is going to die some time down the road. Now, this does not mean that the project will not die in the future. But it shows that the people behind it are committed enough that they don't foresee this project shutting down anytime soon. In short, the project has enough momentum to sustain itself for some time.

A book shows excitement for the project. And this book practically bubbles with it since it is co-authored by one of the most prominent figures in the Squeak Community, Stephen Ducasse. If a project leader is excited enough about the product to write a book then you can be certain that it's an exciting product.

A book shows the maturity of your project. After all, it's too risky to write a book if things are going to change. Maturity is a sign of stability -- meaning that this product is unlikely to undergo a capricious change in the near future. Thus, if your product depends on Squeak, it is probably not going to suddenly be incompatible in the future.

A book shows that other people are interested. Why write when you don't even have an audience? This is actually a catch-22 since you wouldn't write a book if there is no audience but you wouldn't really have an audience if you don't really have good documentation to inform them adequately in the first place.

In short, I think an updated book is a good sign that the Squeak community is committed and excited about how much quality and maturity Squeak has achieved. I will be looking forward to this book and hopefully be able to incorporate it in the Smalltalk class that I am teaching assistant for.

This post is inspired by the contents of this entry at the Squeak Wiki FAQ. I just added some pictures to make it more clear.

Squeak is an interesting system. All the source code for the system is embedded in the system itself. This means that you can actually go ahead find the code where a certain feature has been implemented rather easily. And if you desire, you can even change that behavior to suit yourself. Of course, before either of that could happen, you need to know how to look for the code first. I am going to show you three methods for locating code in Squeak. As our example, we will be looking at ways to find where the "Save and Quit" functionality is implemented.

The first method requires the use of the Method Finder (or selector Browser). You can drag an instance of the Method Finder from the tools flap in Squeak. Or you can create a new instance from the World Menu. Just as its name implies, you can use the Method Finder to find methods. You just need to enter a fragment of the method name in the search box and look for it. Sometimes this requires guessing the method name. Fortunately the naming convention in Squeak is fairly consistent and most of the time your guess will help you find the method.

Here I am guessing that there must be a method called "saveandquit" so I enter that into the Method Finder (or Selector Browser) and try to find it. The results show that there is indeed such a method and that two classes have it: TheWorldMainDockingBar and TheWorldMenu.

In my previous post I mentioned some useful packages that do not come installed by default in normal distribution of Squeak. There are two ways that you can get hold of those packages in your image.

The first way is to download a specially packaged image that contains most of the developer tools. You can get that image from here. The advantage is that you get all the tools that Squeak developers usually use. The disadvantage is that if this is your first time using Squeak, you might not know all the tools. Hence you end up with an image that contains a lot of things that you will not use. And documentation for tools are usually pretty sparse so it is a good idea to start small and selectively choose the tools that you will use.

Thus, I present the second method to get hold of those tools: installing them as individual packages. For this process, I am going to start with a clean image to show you how it is done. I will install the Shout workspace package which gives you syntax highlighting in the workspace.

Bring up SqueakMap Package loader first.

One way to reduce the clutter in Squeak is to create projects. Contrary to its name, a project is more of a organized view of the image. Every project shares the same code in the image; changes made in one project affect code in another project that reside in the same image. So why would anyone want to do this? Like I mentioned, projects are a nice way to organize the things that you are working on.

A similar analogy is the mksession command in gVim. It allows you to record the current state of your files, which files are opened, etc. Eclipse has a similar feature called working sets but it is not as useful since it does not remember the files that are opened in the editor.

Give the project a name and then hit accept. You can now click on the project to enter it. You can even drag it around. Explore the project... menu to see what else you can do. One quick way to see all the projects and quickly navigate to them is projects... > jump to project...

An easier way if you have the navigator flap open is to select it and click the "NEW" button.

Once you get used to using projects, you will wish that every IDE has this feature. The ability to remember the exact state of all your open windows and their layout is actually pretty useful to get your brain back into the context it was in while working on your code.

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.