Smalltalk wurde ursprünglich im Rahmen eines Projektes am XeroxParc entwickelt, bei dem es darum ging, Lösungen für eine möglichst menschenfreundliche Kommunikation zwischen Mensch und Computer zu finden. Auch der Typ grafischer Benutzeroberflächen wie sie heute allgemein üblich sind, war ein Ergebnis dieses Projekts. Smalltalk war als Sprache für End-Anwender gedacht. Siehe: [[Link]Design Principles Behind Smalltalk[Url= http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html]], The Xerox "Star": A Retrospective

== Besonderheiten typischer Entwicklungsumgebungen = * Smalltalk Code befindet sich normalerweise nicht in Textdateien, sondern in einer Art Datenbank, die in die Entwicklungsumgebung integriert ist, und deren Daten in Form einer großen Binärdatei abgespeichert werden. Diese Datei wird Image genannt, weil sie ein Abbild des Zustandes der gesamten Entwicklungsumgebung ist. Das beinhaltet die Standardbibliothek, Anwendungen und den Zustand der Benutzeroberfläche. Es ist traditionell nicht unüblich zur Entwicklung einer Anwendung dem System nicht nur Klassen hinzuzufügen, sondern auch Methoden zu bestehenden Klassen, was den Einsatz von über übliche VersionsKontrolle a la CVS hinausgehende Code-Verwaltung unabdingbar macht. (Letzteres ist dann natürlich auch in die Entwicklungsumgebung integriert.) In einigen neueren Entwicklungsumgebungen wurde Smalltalk um Namespaces erweitert. (Allgemeines zum Thema Entwicklungsumgebungen siehe IDE, siehe auch MartinFowlers Artikel über Repository Based Code).

Freie Implementierungen * SqueakSmalltalk ( http://www.squeak.org/) * GnuSmalltalk * #Smalltalk (SharpSmalltalk, .NET) Kommerzielle Implementationen * VisualAge Smalltalk (IBM, http://www.software.ibm.com/ad/smalltalk) (nicht-kommerzielle Version umsonst) * VisualWorksSmalltalk (nicht-kommerzielle Version ist umsonst) * ObjectStudioSmalltalk * PocketSmalltalk * DolphinSmalltalk * SmalltalkX (lizenzfrei) * S# (Smallscript, .NET) * ... Community

• SmalltalkResourcen
• /Geschichte
• /Vorurteile
• /Portabilität
• SmalltalkDialekte
• /Neuigkeiten

Besonderheiten der Sprache

• Pure OO-Sprache. Alles ist ein Objekt.
• Sehr einfache Syntax. Kontrollstrukturen sind nicht teil der Syntax, sondern Methoden, d.h. können vom Programmierer selbst definiert werden. (Dazu sind - im Gegensatz zu Lisp - keine Makros nötig; siehe auch DynamicClosures.)
• Die Sprache ist entscheidend durch die umfangreiche Klassenbibliothek geprägt.
• Durch Übernahme von einigen Konzepten aus der funktionalen (applikativen) Programmierung können häufig explizite Schleifen durch kürzere und übersichtlichere Lösungen ersetzt werden.

Besonderheiten typischer Entwicklungsumgebungen

• Smalltalk Code befindet sich normalerweise nicht in Textdateien, sondern in einer Art Datenbank, die in die Entwicklungsumgebung integriert ist, und deren Daten in Form einer großen Binärdatei abgespeichert werden. Diese Datei wird Image genannt, weil sie ein Abbild des Zustandes der gesamten Entwicklungsumgebung ist. Das beinhaltet die Standardbibliothek, Anwendungen und den Zustand der Benutzeroberfläche. Es ist traditionell nicht unüblich zur Entwicklung einer Anwendung dem System nicht nur Klassen hinzuzufügen, sondern auch Methoden zu bestehenden Klassen, was den Einsatz von über übliche VersionsKontrolle a la CVS hinausgehende Code-Verwaltung unabdingbar macht. (Letzteres ist dann natürlich auch in die Entwicklungsumgebung integriert.) In einigen neueren Entwicklungsumgebungen wurde Smalltalk um Namespaces erweitert. (Allgemeines zum Thema Entwicklungsumgebungen siehe IDE, siehe auch MartinFowlers Artikel über Repository Based Code).
• Inkrementeller Compiler (je nach Dialekt gibt es einen PseudoCodeInterpreter, JustInTime-Compiler, Ausführung über DotNet, Übersetzung nach C oder in Maschinencode)
• IDE is komplett in Smalltalk geschrieben und als Source im System vorhanden

Vorteile der Sprache

• Syntax leicht erlernbar, danach typischer Code sehr gut lesbar
• durchgängiges OO-Konzept

Nachteile der Sprache

• Programmierer die bereits C, C++, Java oder Pascal gelernt haben und zum ersten Mal Smalltalk-Code sehen, verstehen zunächst nichts, und fühlen sich deshalb häufig von der Sprache abgestoßen.
• Pures OOP ist nicht für alle Anwendungsgebiete die beste Lösung.

Vorteile typischer Entwicklungsumgebungen

• umfangreiche Klassenbibliothek inkl. Source
• integrierte Tools wie KlassenBrowser, Debugger, RefactoringBrowser und SmallLint; wie zum Teil in dieser Demo zu sehen
• keine Turnaround Zeiten, jede Methode wird nach Änderung sofort kompiliert und kann getested werden, das geht auch für Methoden von bereits erzeugten Objekten also bei laufender Anwendung!
• GarbageCollection

Nachteile typischer Entwicklungsumgebungen

• Das Arbeiten mit Images statt mit Textdateien erfordert etwas andere Arbeitsabläufe, als die meisten Programmierer gewohnt sind, was auf viele sehr abschreckend wirkt.
• Einsatz externer universeller Tools (die nicht speziell für die verwendete Entwicklungsumgebung gedacht sind) kaum sinnvoll machbar.

Vorteile einiger Entwicklungsumgebungen

• alle gängigen Datenbanken werden unterstützt
• auf (fast) allen Platformen verfügbar
• plattformunabhängig (Write once, run everywhere)

Typische Anwendungsbereiche

• Individualentwicklung
• Projekte mit hohem Wartungsaufwand
• Anwendungen mit komplexen Benutzeroberflächen
• große Anwendungen
• ExtremeProgramming-Projekte
• OOP-Kurse an Universitäten

Community

• GermanSmalltalkUsersGroup
• Why Smalltalk?

Sprachverwandtschaft

Andere Sprachen oder Entwicklungsumgebungen, die besonders stark von Smalltalk beeinflusst sind:

• SpracheStrongTalk
• SpracheObjectiveCee
• SpracheRuby
• SpracheSuneido
• VisualAgeForJava
• SpracheBistro
• ...

Programmierbeispiele

• siehe HelloProgramme

Kontrollstrukturen

Eine weitere erwähnenswerte Besonderheit ist die Abwesenheit von in die Sprache eingebauten Kontrollstrukturen. Kontrollstrukturen werden über DynamicClosures realisiert. Diese heißen in Smalltalk Blöcke und werden mit eckigen Klammern erzeugt. Kontrollstrukturen sind als Methoden von Boolean oder BlockClosure implementiert und es lassen sich beliebige Konstrukte nachrüsten. Die Implementation von whileTrue: bei BlockClosure könnte z. B. so aussehen:

whileTrue: aBlock Werte aBlock solange aus, wie mein Wert wahr ergibt.

^self value ifTrue: [ aBlock value [ self value ] whileTrue: [ aBlock value ]]

Wer das begriffen hat, wird keine Probleme haben, die Methoden Boolean>>ifTrue:ifFalse oder Collection>>do: zu implementieren. Die mitgelieferte Klassenbibliothek hält eine Reihe von in dieser Form implementierten Kontrollstrukturen bereit. Diese werden i. A. durch die VirtuelleMaschine optimiert behandelt und sind daher Eigenkreationen vorzuziehen.

Kapselung

Alle Instanzvariablen sind protected. Es ist durchaus üblich, trotzdem Zugriffsmethoden bereitzustellen, diese aber in ein Protokoll private zu verschieben. Das ist letztenendes eine Frage der persönlichen Vorlieben. Will man eine Methode als private kennzeichnen, so ist man generell auf solche Konventionen angewiesen. Die SpracheSmalltalk kennt keine privaten Methoden.

Diskussion

"Heute die Nummer 3 nach Java und C+" -- Und Delphi? Wäre das nicht Nr. 3?

"Dazu sind - im Gegensatz zu Lisp - keine Makros nötig":

    Was soll so schlecht an Makros sein - bitte nicht verwechseln: C-Preprocessor-Makros und Lisp-Makros

Warum steht PocketSmalltalk unter kommerziell? Auf der Homepage dazu steht "free open source". ...