Developers SIG
February 3, 2004
Announcement
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.
Biography
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.
Presentation
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.
Follow-up
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.