Das ist zwar zutreffend, aber es erklärt nicht, warum Smalltalk diejenigen, die sich damit auseinandersetzen, so schnell begeistern kann. Auch Java oder C# sind objektorientierte Programmiersprachen, haben teils sehr umfangreiche Klassenbibliotheken und interaktive Programmierumgebungen und sind seit einigen Jahren Standard.
Die Stärken von Smalltalk
Die bisher beschriebenen Eigenschaften von Smalltalk als Programmiersprache und -umgebung ergeben in der Praxis einige wichtige Stärken, die für einen Einsatz von Smalltalk sprechen.
Smalltalk erlaubt die einfache und flexible Modellierung von Konzepthierarchien, die dem klassischen Muster der schrittweisen Verfeinerung vom Allgemeinen zum Speziellen folgt. Damit bietet sich Smalltalk geradezu prototypisch für die Modellierung von Geschäftswissen an.
Smalltalk ist ein ausgereiftes, hoch-performantes und skalierbares System, das "write-once-run-everywhere" Ausführung erlaubt und das seit Anfang der 80er Jahre. Die Auswahl der verfügbaren Plattformen hängt vom Anbieter ab und deckt bei VisualWorks von Cincom alle aktuellen Workstations von PC, Mac bis hin zu den diversen Unix/Linux-Varianten ab.
Im Kontext von Smalltalk ist eXtreme Programming entwickelt worden und Smalltalk ist sicherlich die produktivste der XP-Entwicklungsumgebungen.
Smalltalk kann seine Stärken besonders in einem Umfeld mit hoher Änderungshäufigkeit ausspielen. Die integrierte inkrementelle Entwicklungsumgebung zusammen mit der Flexibilität, die sich aus der Reflexivität und der impliziten Typisierung ergibt, erlauben schnelle und jederzeit verifizierbare Modifikationen und schnelle Entwicklungszyklen.
In der Summe all seiner Eigenschaften, von denen wir hier nur eine kleine Menge angeführt haben, empfiehlt sich Smalltalk und speziell Cincom Smalltalk für die Entwicklung komplexer und vielschichtiger Systeme, die fortwährend an eine sich ändernde Welt angepasst werden müssen.
Die Programmiersprache Smalltalk ist rein objektorientiert, reflexiv und implizit getypt. Das bedeutet praktisch, dass Smalltalk eine völlig andere Programmierung ermöglicht als andere, aus prozeduralen Sprachen wie C abgeleitete OO-Sprachen.
Rein objektorientiert bedeutet, dass jeder Wert und jede Datenstruktur ein Objekt ist. Wir kennen in Smalltalk nicht die Unterscheidung von literalen Werten wie Zahlen, Zeichen oder Zeichenketten und Objekten, die zum Beispiel von C++ und seinen Abkömmlingen gemacht wird. Der Ausdruck '23' erzeugt eine Instanz der Klasse SmallInteger, die über eine kurze Hierarchie von der Klasse Object abgeleitet ist. Damit versteht die Zahl 23 alle Nachrichten, die in dieser Hierarchie definiert sind und man kann in der Klasse SmallInteger auch neue Methoden implementieren. Ebenso erzeugt man Arrays nicht durch eine dedizierte Syntax, sondern schlicht durch eine Erzeugungsnachricht an die Klasse Array, z.B. 'Array new: 4'. Reine Objektorientierung vermeidet künstliche Unterscheidungen von Werten und Objekten, die schwer motivierbar sind.
Reflexiv bedeutet, dass Smalltalk in Smalltalk implementiert ist. Die Objekte, die die Sprache Smalltalk definieren, sind selber mit den Mitteln der Sprache beschrieben. Daher sind Klassen und Methoden selber wieder Smalltalk-Objekte und gehen bei der Übersetzung einer Klasse nicht einfach in dem erzeugten Programm auf. Damit wird auch unser obiges Beispiel 'Array new: 4' klarer. Die Klasse Array ist selber ein Objekt, das man unter seinem Namen ansprechen kann und das unter anderem eine Methode 'new:' implementiert. Die Verwendung von Smalltalk Objekten zur Definition des Smalltalk-Systems erlaubt dem Programmierer sowohl die Sprache selbst als auch die Programmierumgebung zu erweitern. In diesem Umfang ist es wohl in keiner anderen konventionellen Umgebung möglich.
Eine implizit getypte Sprache besitzt zwar Typen -- in Smalltalk sind dies die Klassen der Objekte -- aber die Zuordnung der Typen zu Objekten erfolgt zur Laufzeit und muss nicht als Typdeklaration zur Programmierzeit angegeben werden. Damit ist Smalltalk typsicher: es ist unmöglich, ein Programm durch Verwendung einer unverstandenen Nachricht zum Absturz zu bringen. Die Reflexivität von Smalltalk erlaubt es, eine solche illegale Situation zu erkennen und innerhalb von Smalltalk zu behandeln. Das geht sogar so weit, dass man den Fehlerfall durch Programmieren der fehlenden Methode behandeln kann und das 'abgestürzte' Programm danach weiterlaufen kann. Wir wollen hier nicht auf die unlösbare aber dennoch (oder vielleicht deshalb?) mit viel Elan geführte Diskussion pro-contra Typdeklarationen eingehen. Smalltalk funktioniert bestens auch ohne explizit angegebene Typen.
Die Reflexivität von Smalltalk macht aber nicht bei der Sprache Halt. Auch die Klassenbibliothek und die Entwicklungsumgebung sind komplett in Smalltalk realisiert. Compiler, Debugger und das Browsersystem sind Smalltalk-Programme und liegen in der Regel in Quelltexten vor. Der Browser ist gleichzeitig ein integrierter Editor, Sourcecode-Analysator und Refaktorisierungswerkzeug, das in seinen Möglichkeit derzeit unübertroffen ist. Das Fehlen von Typdeklarationen und die Reflexivität hat eine interessante Konsequenz für den klassischen "Edit, Compile, Debug"-Zyklus: es gibt keine unvollständigen Klassendefinitionen und daher kann man Klassen und ihre Methoden voneinander unabhängig übersetzen. In Smalltalk zu programmieren bedeutet, Klassen inkrementell Methode für Methode aufzubauen. Zu jedem Zeitpunkt kann die partielle Klasse verwendet und ausgetestet werden. Dies erlaubt perfekte Möglichkeiten für schnelle "Edit, Compile, Debug"-Zyklen auf Sourcecode Ebene.