Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Die Geschichte von Apples Programmiersprachen – von Clascal zu Swift

Als Anfang der Achtzigerjahre der erste Macintosh entstand, benötigte er sowohl ein Betriebssystem als auch eine Basisausstattung an Software. Deren Programmierung musste zwangsläufig auf einer anderen Maschine erfolgen, denn es gab natürlich noch keinen Mac. Das Macintosh-Team nutzte dafür den hausinternen Konkurrenten Lisa. Als Programmiersprache kam dabei die Programmiersprache Pascal zum Einsatz, welche im Konzern für die eigenen Bedürfnisse angepasst wurde – Lisa Clascal. Vierzig Jahre später bevorzugt Apple die Eigenentwicklung Swift. In einem Blog-Beitrag erzählt Howard Oakley die Geschichte von Apples Programmiersprachen nach.


Apple ließ sich nicht nur bei der grafischen Bedienschnittstelle von Xerox PARC inspirieren, berichtet Oakley. Für kurze Zeit experimentierten Apples Entwickler mit der Programmiersprache Smalltalk, ebenfalls ein Produkt des Palo Alto Research Centers. Doch zeigte sich diese als langsam und uneingängig für Entwickler, weshalb man dazu überging, elementare Konzepte in Pascal zu integrieren: Clascal trennte Interface von Implementation und umfasste moderne Programmierkonzepte wie Klassen, Methoden und Vererbung. Die damit gewonnenen Erfahrungen bildeten die Grundlage für Object Pascal, welches Apple in Zusammenarbeit mit Niklaus Wirth entwickelte – dem Erfinder von Pascal.

Von C++ zu Objective-C
Ab 1991 und System 7 schwenkte der Konzern auf C++ um. Zehn Jahre später, mit dem Umstieg auf Mac OS X, fand ein erneuter Wechsel statt. Fortan entstanden Betriebssystem und Apps bevorzugt in Objective-C. Diese kam bereits bei NeXT zur Anwendung, entstand ebenfalls in den Achtzigern – und war wie Clascal von Smalltalk inspiriert. Als Entwicklungsumgebung diente zunächst "Project Builder", welcher im Jahr 2003 in Xcode aufging. Diese IDE stellt Apple bis heute zum kostenlosen Download bereit.

Swift läuft parallel
Während Objective-C bis heute in vielen Software-Projekten zum Einsatz kommt, bietet Apple mit Swift einen hausinternen Mitbewerber an. Innerhalb der elf Jahre ihres Bestehens hat sich die Sprache stark verändert, berichtet Oakley. Er kann sich auch eine dezente Kritik nicht verkneifen: Swift habe mittlerweile beinahe jedes vorhandene Programmierparadigma integriert. Zwar könne man weiterhin Swift in einer Form schreiben, welche einem Pascal- oder C-Kenner verständlich sei; wer jedoch ein anderes Paradigma wähle, könne seinen Code so gestalten, dass er nahezu undurchschaubar für andere ist.

… und viele andere
Neben Apples Empfehlungen entstand zudem ein Ökosystem an kurz- und langlebigen Entwicklungsumgebungen, welche das Mac-fokussierte Programmieren ermöglichten. Oakley erwähnt unter anderem das 1987 veröffentlichte Mac Common Lisp. In den Kommentaren unter dem Blog-Beitrag werden das „Macintosh 68000 Development System“ (MDS) sowie MacFORTH erwähnt, zudem die hauptsächlich für NewtonOS vorgesehene Sprache Dylan.

Kommentare

xcomma22.07.25 10:27
Was in der Auflistung fehlt ist WebObjects , das einen Web Application Server und dazugehörige Tools (einige davon finden sich im heutigen Xcode wieder) umfasste auf Enterprise Niveau - auch zu einem Enterprise Preis $50000 für eine Serverinstanz. Zu den Kunden dieser Technologie zählte damals auch Mercedes Benz beispielsweise.
Dann wurde der Preis mal drastisch reduziert auf $699 und wurde erschwinglicher auch für kleinere Unternehmen (mal die Diskussion losgelöst davon, dass man auch entsprechende Skills aufbauen musste).
Zum damaligen Zeitpunkt waren die verfügbaren Konzepte in WebObjects für Web-Applikationen weit voraus.
0
LoCal
LoCal22.07.25 10:35
xcomma
Was in der Auflistung fehlt ist WebObjects , das einen Web Application Server und dazugehörige Tools (einige davon finden sich im heutigen Xcode wieder) umfasste auf Enterprise Niveau - auch zu einem Enterprise Preis $50000 für eine Serverinstanz. Zu den Kunden dieser Technologie zählte damals auch Mercedes Benz beispielsweise.
Dann wurde der Preis mal drastisch reduziert auf $699 und wurde erschwinglicher auch für kleinere Unternehmen (mal die Diskussion losgelöst davon, dass man auch entsprechende Skills aufbauen musste).
Zum damaligen Zeitpunkt waren die verfügbaren Konzepte in WebObjects für Web-Applikationen weit voraus.

WebObjects ist keine Programmiersprache, es ist mehr eine Framework.
Früher basierte WebObjects auf Objective-C, aber Version 5 kam Java zum Einstatz.
Mittlerweile ist WebObjects nicht mehr öffentlich verfügbar, aber alle AppStores basieren auf WO.
Ich hab zwar keine Lösung, doch ich bewundere dein Problem
+7
Weia
Weia22.07.25 10:36
xcomma
Was in der Auflistung fehlt ist WebObjects ,
Aber WebObjects ist doch keine Programmiersprache?

EDIT: LoCal war schneller.
„Meinung“ ist das Foren-Unwort des Jahrzehnts.
+4
Moranai
Moranai22.07.25 10:43
Wenn jetzt noch die Doku zu SWIFT vollständig und üppiger wäre...
+3
xcomma22.07.25 10:49
Local, Weia,
das ist wohl wahr - da habe ich mich anscheinend davon leiten lassen, dass im Artikel auch Xcode und Project Builder genannt wurden
Allerdings ist vieles im Programmier-Universum von Apple oft mit Tools/IDE so stark verwoben, so dass wenn man A erwähnt auch B nicht weit entfernt ist
0
Unwindprotect22.07.25 13:09
Die Geschichte zur Performance von Smalltalk damals erzählt jedoch nur die halbe Wahrheit. Es wurde auf Xerox Alto Maschinen ausgeführt... die damals immerhin 512 KB RAM hatten und 4 ALUs basierend auf 74181 kombiniert zu einer 16 bit ALU mit 5,88 MHz.

Ein Apple I hatte bis zu 48KB RAM (also 1/10) und einen 6502 als 8-Bit ALU mit 1MHz. Mit Apple II ging es bis 64 KB.

Bei einfachen 8-Bit-Rechnungen konnte der 6502 sogar teils besser als der Alto sein - aber wenn es um 16-Bit Operationen ging oder die Unterstützung höherer Sprachen wie Smalltalk, dann war der Alto deutlich überlegen.

Wichtiger war aber der Arbeitsspeicher. Smalltalk ist typischerweise ein Image-basiertes System. D.h. man startet das Smalltalk-System und fügt dann Code interaktiv hinzu. Man speichert dann ein sogenanntes "Image" (Abbild des Speichers) und später wieder an dieser Stelle fortsetzen zu können. Die ganze Idee hinter Smalltalk ist auch, dass man ein "immer laufendes System" hat... auch während der Entwicklung! Die Entwicklungsumgebung ist Teil des Systems selbst. Die dynamische OOP von Smalltalk basiert zudem auf vielen Objekten die im Speicher gehalten und adressiert werden müssen. Der Alto hat zwar ebenfalls nur einen 16 Bit-Adressraum, aber er unterstützte ein Virtual Memory System auf bis zu 512KB... also das 4-Fache eines 16 Bit Adressraums.

Mit dem Apple Lisa hätte Apple dann eine Hardware gehabt, welche dem Xerox Alto deutlich überlegen war: Bis zu 2 MB RAM und eine Motorola 68000 CPU mit 32 Bit Adressbus. Allerdings war Smalltalk auf dem Alto mit dessen Microcode sehr hardwarenah optimiert. Dasselbe auf einem Motorola 68000 wäre trotzdem signifikant langsamer gewesen. Das größere Problem dürfte jedoch schlicht gewesen sein ein so komplexes System wie Smalltalk zu portieren und zu pflegen. Xerox hatte einen internen Port von Smalltalk auf Lisa, aber das war niemals offiziell unterstützt. Smalltalk war schlicht und einfach sehr viel mehr Forschungssystem als Endnutzerprodukt!

Also selbst wenn Apple mit der Lisa eine Hardware hatte die schon besser dafür geeignet gewesen wäre... eine Programmierung in Motorola 68K Assembler und Pascal ermöglichte eine bessere Nutzung der Hardwareressourcen für das was diesen Computer eigentlich als Produkt auszeichnen sollte: Seine GUI.

Weiterhin muss man natürlich sehen, dass es einfach weit mehr Programmierer gab, die Pascal oder Assembler programmieren konnten als Smalltalk. Pascal ist auch bei weitem primitiver und leichter zu lernen. Gerade diesen Aspekt sehe ich fast noch als gewichtiger an als die Performance.

Was "Clascal", Object Pascal und Delphi anging... all das hatte nur wenig mit dem zu tun was Alan Kay (Erfinder der Bezeichnung "object-oriented" und Smalltalk) damit meinte. Diese Sprachen waren deutlich ähnlicher zu dem was Simula oder C++ anbieten. Smalltalk bildet ein Modell ab in welchem Aktoren Nachrichten austauschen. Das Verhalten ist dabei extrem dynamisch. Simula, C++, Clascal und Object Pascal dagegen haben ein Objektsystem bei welchen man ein starres Klassenmodell beim entwickeln vorgibt und davon im laufenden Programm im Normalfall nichts mehr vorhanden ist. Der einzige dynamische Aspekt dieser Programmiersprachen ist der meist per Virtual Method Table implementierte dynamische Methodenaufruf, doch auch hier ist die exakte Liste der Methoden nach dem übersetzen des Programmes fest vorgeschrieben. Bei Smalltalk ist das jederzeit änderbar.

Deswegen ist auch so interessant, das Steve Jobs dann bei NEXT mit Objective C auf eine Programmiersprache setzte, welche diese dynamischen Vorteile Smalltalk zumindest teilweise wieder realisierte. Der Rest der Welt ging stattdessen den weit weniger objektorientierten starren Weg von C++. Das führte dann zu solch lachhaften Auswüchsen wie bei BeOS, bei dem Klassen um "Dummy-Attribute" ergänzt wurden, damit man diese Klassen in neueren Versionen des Systems noch erweitern kann ohne die Binär-Kompatibilität zu verlieren.
+5
MrJava22.07.25 13:47
Das mit Pascal wusste ich noch nicht - interessant.
Hör auf Dich selbst, sonst hört Dich keiner!
0
Unwindprotect22.07.25 15:57
MrJava
Das mit Pascal wusste ich noch nicht - interessant.

Pascal war ja auch bei Microsoft am Anfang wichtig
0

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.