Last updated at 12:45 am UTC on 11 September 2004
I'm an enthusiastic Smalltalker since joining Objectory AB in 1994, and discovering that I could become a productive developer using Smalltalk after no previous experience in the language, environment or target application in about 2 days; a serious hacker after about 2 weeks; and really dangerous after six months.
I learned Smalltalk from such excellent mentors as Sten-Erik Bergner, Ingemar Allqvist and Gunnar Blomberg, and was able to get Kent Beck to come over to Sweden in 1995 to give us a talk on his then-work-in-progress on Smalltalk patterns.
What I see as the Smalltalk development style carries through in all software development I do, and I think the mindset that Smalltalk and the Smalltalk community forsters (which involves such things as highly iterative development, focus on developing appropriate abstractions to express problems and solutions, extensive shifting of programming solutions into generic code solutions coupled with data supplying the instantiation for a particular solution) is very powerful.
I have worked on a number of software development tools: Sysware Matrix, Objectory SE and BE, Rational Rose, Rational XDE, IBM Rational Websphere.
I am currently working on a software development platform and scalable server for mobile devices at Sproqit.
Smalltalk is my favorite language and development environment (although Apple's Dylan (footnote) environment gave it a run for the money before it was cancelled), but after using ParcPlace's ObjectWorks and then VisualWorks professionally, I haven't had much chance to use it, except for the occasional hobby project in Squeak.
I'm currently hobbying around using Python, Objective-C, C#, VisualBasic, and sometimes Squeak.
Someday I hope to bring the Smalltalk software development "mindset" as I see it to a wider audience. Whether it will involve actual use of Smalltalk or not remains to be seen.
I think many of the Smalltalk valuables (dynamism, great classes, great tools, block closures) exist or can be replicated in other environments, but I do think Smalltalk environments have the best combination of such valuables.
The top of my wishlist for Smalltalk are:
1) Tools for dealing with components in various ways.
It's way too painful to incorporate new versions of Squeak. I like the way Smalltalk file-outs can inject changes anywhere in the class hierarchy, but the current tools and practices aren't quite good enough. SqueakMap shows promise, but often doesn't work.
I like the way NeXT/Apple allows deployed code to deploy and reference specific versions of code it depends on.
2) Better server competitiveness. I tried using Squeak on a server with no X-Windows installed. I never got it to work properly. Don't get me wrong; I'm not whining or begging anyone to do. It's just a pity that it seems it's easier to put together a solid server solution at this time using Python, PERL or Ruby than it is with Smalltalk. It seems like a sadly (so far) lost opportunity. This may be more of a perception problem than actual technical merit. I don't know.
I think Dylan does have some strengths compared to Smalltalk. Of course, Apple's development environment was beautiful in its simplicity and power, but Smalltalk browsers are on the whole good enough (maybe better).
1) I found it was much easier, as a practical matter, to create data types in Dylan than in Smalltalk. I found myself creating data types in Dylan right away, if there was some cohesion to some values being passed around, for example; while in Smalltalk, I might not create a class for such a beast until I found myself passing 3-4 elements in an array as an argument. There's not a huge difference in the amount of work needed to create the data type or class in Dylan or Smalltalk. I think this is due to subleties in the way the two environments work, and in the way classes are managed in the Smalltalk interface. I should be able to "teach myself" to act the same in the two environments, but it still feel more comfortable doing it in Dylan.
2) Generic functions are a good thing. I've seen way too much copy/paste code in Smalltalk code bases because you only get one chance at decomposition using classes and single inheritance. In Dylan, you can take all that printOn: and stick it in one place, write similar code only once, and request the appropriate dispatching based on any number of arguments, not just the type of the receiving object.
Looking at all the effort that has gone into being able to extend the Dylan language itself through "clean" macros, I really admire the simplicity of block closures in Smalltalk. Other languages use esoteric constructs to do things that are incredibly simple and natural in Smalltalk, such as sending an ensure: message to a BlockContext. This is the same power that is inherent in LISP dialects, the ability to in effect extend the language indefinitely by the simple means of building everything using the same, very few building blocks, such as objects and messages, or lists and functions.