Skip navigation

Monthly Archives: December 2010

So this semester I took CS322 Principles Of Programming with one John Sarkela, who was there at Xerox Parc in the days when object-oriented programming and the graphical user interface were being invented. We studied Forth and Scheme before the final section of the class where we learned Smalltalk. Smalltalk is Mr. Sarkela’s area of expertise, so I was enthused to be learning the basics from someone so well versed in the idioms of the language and community.

One of the first things I noticed was how much I liked the environment. Those who know will tell you that Smalltalk was where most of the fancy development tools we use today originated. Things like refactoring, IDE code intelligence, class browsing and builtin debugging were firsts when Smalltalk introduced them, and they are in excellent form.

Since Smalltalk is an image-based system, all code and objects live literally forever, until you lose or delete the image which contains them. You can use a workspace to assign a variable an object, save the image and exit, and when you start it up later, the object will be waiting for you, just as you left it. With a system like this, the environment can let you do strange things like modify the structure of a user interface on the fly. Also, since code is just another object in the system, the source code is carried around with it, and each image could have vastly different implementations of the system APIs or indeed any code in the system. This is very, very useful for molding the system libraries and frameworks to do exactly what you need, without having to maintain the housekeeping details like you would with other languages (ie, a branch in DVCS or the directory structure where you keep your modified libraries).

So the image-based nature of Smalltalk does great things for the system as a development environment, as these inclinations tend to allow the programmer to organize his/her environment in just the way they want. But the disparity between “the image” and the “the executable” has become, in my opinion, one of the biggest stumbling blocks for teaching the virtues of message-oriented objects to programmers trained with Java/C# and C++.