Smalltalk versus Java

Als Entwickler im Umfeld von Geschäftsapplikationen mit Smalltalk und Java Erfahrung möchte ich hier einen kleinen Vergleich zwischen den beiden Sprachen bzw. Plattformen machen.

Die Geschichte von Smalltalk beginnt irgendwann in den 70er Jahren, wobei es erst in den 80er und 90er Jahren vermehrt Verbreitung fand, um dann mit dem Aufstieg von Java wieder Marktanteile zu verlieren. Heute sind Smalltalk-Projekte (zumindest in der Schweiz) ziemlich selten geworden.

Hier noch ein Zitat zu den Ursprüngen von Java:

Java. The elegant simplicity of C++. The blazing speed of Smalltalk.
http://c2.com/cgi/wiki?SmalltalkMinusMinus

Zum beginnen einige Gemeinsamkeiten von Smalltalk und Java, quer über Sprache und Plattform:

• Beide sind Objekt-Orientiert
• Beide haben eine grosse Klassenbibliothek z.Bsp. für Collections
• Beide laufen in einer Virtual Machine und verwenden ein Garbage Collector
• Viele Smalltalk VM's laufen wie die JVM auf mehreren Betriebssystemen

Und hier einige Unterschiede:

• Smalltalk verwendet keine statische Typisierung
• Smalltalk hat nur sechs Key-Wörter, alles andere wird über Klassen, Objekte, Methoden und Blöcke (entspricht in etwa den Closures in Java 8) abgebildet
• Smalltalk verwendet sogenannte Images anstatt Dateien
• In Smalltalk bilden Sprache, Runtime und IDE eine stärkere Einheit. Dafür gibt es nicht wirklich einen Hersteller übergreifenden Standard, ein Wechsel der IDE ist praktisch nicht möglich

In der täglichen Arbeit wirken sich diese Unterschiede mal weniger, mal mehr aus.

Statische versus Dynamische Typisierung

Als Nachteil von dynamischer Typisierung wird häufig angeführt, dass dadurch zur Laufzeit ein falsches Objekt verwendet werden könnte. In der praktischen Arbeit kommen solche Fehler aber extrem selten vor, wenn überhaupt. Viel häufiger tretten aber auch in Smalltalk folgende Probleme auf: Null Pointer Exceptions.

Umbenennen von Klassen oder Methoden geht in Java etwas einfacher (vorausgesetzt die ganzen Verweise liegen im Projekt oder Workspace vor), weil beim Compilieren Fehler auftreten. Dafür spart man in Smalltalk einiges an Zeit weil es keine merkbaren Compilierzeiten gibt.

Sprache und Klassenbibliothek

Was einem als Smalltalk Entwickler beim Einstieg in Java vermutlich als erstes auffällt, ist der grosse Aufwand den es zu Beginn braucht um nur einmal sämtliche Schlüsselwörter und Konstrukte der Java Sprache zu erlernen. Während sich ein Java Entwickler also noch mit der Sprache herumschlägt, kann sich ein Smalltalk Entwickler bereits in die Klassenbibliothekt einarbeiten. Bzw. er muss, da in Smalltalk nun mal sämtliche Konstrukte wie IF-Statements und Loops in Form von Klassen und Methoden vorliegen. Ansonsten finden sich praktisch alle Klassen in Smalltalk auch in Java wieder oder umgekehrt, hier als Beispiel ein Auszug aus den Collections-Klassen:

Smalltalk	Java
Dictionary	Map
IdentityDictionary	HashMap
Collection	List
OrderedCollection	ArrayList
Array	(primitive Arrays)
Set	Set
IdentitySet	HashSet
usw.

Tools und IDE

In Smalltalk findet der grösste Teil der Entwicklung im Class-Browser statt. Im Gegensatz zu Java IDEs wie Eclipse, wo Editierung und Browsing getrennt sind, bildet dies in Smalltalk immer eine Einheit. Die Klassen werden nicht primär in einzelnen Dateien gespeichert sondern in einem gemeinsamen Image. Dies macht die Entwicklung mit Smalltalk sehr effizient.

Im Gegensatz dazu ist es in keiner mir bekannten Smalltalk Umgebung möglich, verschiedene Arten von Resourcen oder gar Sprachen über die gleiche IDE zu editieren.

Class-Browser in VisualWorks - Browsen und Editieren gleichzeitig

Smalltalk oder ...?

Die Sprache Smalltalk ist einfacher als Java aber trotzdem sehr mächtig ist und wirkt dank der konsequenten Umsetzung der Konzepte immer noch modern. Im direkten Vergleich zu Smalltalk (oder auch C#) wirkt Java (die Sprache) für mich eher schwerfällig und veraltet. Alternative Sprachen bringen zwar einige der Vorteile dynamischer Sprachen auch auf die Java Plattform, die IDE Unterstützung scheint mir aber bei Smalltalk immer noch einiges komfortabler zu sein.

OO-Konzepte, Exception-Handling und die Klassenbibliotheken sind ein weiten Teilen vergleichbar.

Das grösste Problem im Smalltalk Umfeld ist die sehr kleine Community, die eher beschränkten Resourcen (Entwickler) seitens der Smalltalk Hersteller und dass es kein wirklicher Standard gibt und nur sehr wenige Hersteller übergreifende Frameworks. Diese Punkte dürften schlussendlich doch für Java sprechen.

Es ist zu hoffen, dass sich noch einige der Ideen und Konzepte von Smalltalk in die Java oder andere Plattformen retten können und dann vielleicht irgendwann zu Mainstream-Technologien werden. Ich bin aber ziemlich sicher, dass dies noch einige Jahr(zehnt)e dauern wird.

http://www.cincomsmalltalk.com
http://www.instantiations.com/
http://www.object-arts.com/