Java architect with UST Global Biju has posted 5 posts at DZone. View Full User Profile

Smalltalk to Java - My Learnings

07.20.2008
| 5133 views |
  • submit to reddit

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.

Published at DZone with permission of its author, Biju Kunjummen.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Piero Sartini replied on Mon, 2008/07/21 - 8:11am

Just to note, it is possible to do something like this:

anAccount.transfer(1000).to(anotherAccount);

Just return the object itself in every method. It is not that common, and not really "the Java way". But after playing with SmallTalk, I like these kind of things :)

Andrew McVeigh replied on Mon, 2008/07/21 - 11:35am in response to: Piero Sartini

 Just return the object itself in every method. It is not that common, and not really "the Java way". But after playing with SmallTalk, I like these kind of things :)

So-called fluent interfaces are making a comeback in Java/C# and other similar languages: http://martinfowler.com/bliki/FluentInterface.html

As with most "discoveries" they are really just a rediscovery.

Andrew

Kasper Graversen replied on Mon, 2008/07/21 - 12:54pm

Heheh funny you should mention the fluint interfaces, as they originate from Smalltalk! :-) In smalltalk "void" isn't part of the language, hence a method that does not return anything in Smalltalk simply returns itself.

 See more on fluint method chaining at http://firstclassthoughts.co.uk/java/method_chaining.html

 ps. 3 squared in Java IS NOT 3^2 as "^" is a bit-operator

 

-kasper

 

Bruce Fancher replied on Mon, 2008/07/21 - 1:15pm

Smalltalk has a simple, clean syntax. The methods read like English, following are some sample message invocations:

Yes!  One of the stupidest things about Java is that they adopted the C/C++ syntax instead of the Smalltalk syntax.  I guess they figured that using the Smalltalk syntax hadn't worked out so well for Objective-C, which lost out in the marketplace to the vastly inferior C++.  Still, there's no good technical reason for it.  Named method arguments, as in Smalltalk and Objective-C, make code vastly more readable than positional method arguments.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.