Smalltalk to Java - My Learnings

It is difficult to describe a Smalltalk environment to someone who has not experienced Smalltalk. Smalltalk is not just a language, it is a snapshot of a running system at a point in time - this snapshot is referred to as an image. When the image is loaded up, it has everything restored to the point where the image was saved - entire source of the running system - including the IDE, tools, debugger, garbage collector, any application code. Everything is live, any modification of the code will be visible immediately. It atmost takes a days worth of tinkering in a Smalltalk environment like Squeak or Visual Works to become familiar with the basics of Smalltalk.

Unlike the normal programming practice where the code resides in files which needs to be compiled and linked together at runtime, in Smalltalk the code is live at all times, the code does not reside as files but as live objects within the Smalltalk environment.

I started my software career with a Smalltalk project for a client in 1999, around the time when Java in the enterprise world was starting to take off. Smalltalk was the language that I was exposed to after Pascal, Java and it was a pleasant surprise working with the smalltalk IDE which focuses developer attention on 1 class and 1 message at a time(or 1 method/function at a time) and the excellent debugger, the equivalent of which I had not seen for Java(in 1999). I moved onto enterprise Java after 2000 mainly because of the lack of more Smalltalk opportunities. My work with Smalltalk remains very dear to me and I regularly use Squeak Smalltalk for small personal projects.

I got thinking into what differentiates the Smalltalk style development, packaging with current trends in java and these are what I could think of:

Syntax:
Smalltalk:

Smalltalk has a simple, clean syntax. The methods read like English, following are some sample message invocations:
3 squared
'aString' size
map at:1 put:'one'
anAccount transfer:1000 to: anotherAccount


Java:

Java has a C-style syntax
3^2
"aString".length()
map.put("1","one")
anAccount.transfer(1000,anotherAccount);



Tools:
Smalltalk:

Tools are integrated into the language - Advanced Integrated development environment - class browsers, syntax highlighting, debugger, Source control

Java:

Eclipse NOW provides all of these and much more, I personally like the Java Browsing perspective which is closest to the Class Browsers in the Smalltalk environment.


Classpath, Classloading:
Smalltalk:

Every class that is required is loaded up into a smalltalk image. Once loaded, the required class can be browsed in a common Class Browser. Things behave the same way at development as well as deployment time, since the deployment is also as a smalltalk image, there is no need for messing around with different libraries at deployment time. There is no concept of a container and the deployable in the Smalltalk world, the image is the container.

Java:

The dependencies are managed differently at development time and deployment time. The dependencies during development are usually resolved by the IDE but at deployment are packaged as a WAR or an EAR and resolved at runtime by the container based on the Classloading rules.

To conclude, it is very difficult to see Smalltalk grabbing the developer and industry mindshare again - I would love to be wrong though. Java in the enterprise is here to stay, I am happy to see some of the Smalltalk best practices moving to the Java world and enriching the java world - OSGi in my opinion is fairly close to the Smalltalk concept of image, blocks should be a part of a future java spec.