Developers SIG
February 3, 2004


At the February 3 meeting of the Developer's SIG we will continue our exploration of programming languages that has already included Python and Lisp and visit Smalltalk with Keith Alcock as our guide. Smalltalk is often credited as being the first object-oriented programming language and has roots going back to the 1970s. The Smalltalk environment is a system for creating, exploring, classifying, manipulating, and otherwise playing with objects and has influenced the design of many newer languages including Java, C#, Objective-C, and Ruby and current best practices of unit testing and refactoring. It is simple (and fun) enough for children to use, and is something that should be part of every programmer's background knowledge. Keith will provide an overview of the language and a detailed look at one implementation, Dolphin Smalltalk, including as much hands-on experimentation as time allows. We will then look at some specific applications that Keith has written in Smalltalk for the language technology domain. These will include one for detecting spelling errors in a rare, morphologically productive, agglutinative language, and another for correcting errors in more familiar languages.


Keith Alcock is a software developer with a wide range of experience and with a special interest in language technology, an area in which he consults. He often uses Smalltalk to prototype (and sometimes even deploy) solutions to interesting linguistic problems.


We didn't come close to covering all the material I had prepared, so please look through the HTML version of the PowerPoint presentation entitled Smalltalk for interesting topics that we skipped and ask me about them. The Smalltalk code is contained in an RTF file for review. Classes are called hidden this and hidden that because they are the backup versions for use in case building them from scratch didn't work out.


We did some profiling of the two FizzBuzz implementations with results like these:

fizzbuzz1 := HiddenFizzBuzz1 new.
Time millisecondsToRun: [ 1000000 timesRepeat: [ fizzbuzz1 next ] ]15
fizzbuzz2 := HiddenFizzBuzz2 new.
Time millisecondsToRun: [ 1000000 timesRepeat: [ fizzbuzz2 next ] ]36

The baseline version does 1,000,000 iterations in 15 milliseconds while the "optimized" version takes over twice as long!

It turns out that the modulo arithmetic in the baseline version is not performed in the next method, but instead in the displayString method. In the optimized version, the arithmetic is performed in next. So, the comparison is not valid unless both methods are invoked. New measurements are as follows:

Time millisecondsToRun: [ 1000000 timesRepeat: [ fizzbuzz1 next. fizzbuzz1 displayString. ] ]205
Time millisecondsToRun: [ 1000000 timesRepeat: [ fizzbuzz2 next. fizzbuzz2 displayString. ] ]137

This shows the baseline version taking 205 milliseconds and the optimized version taking only 137. The optimization was successfull after all.