knp.de

– Swift 2 als TimeMachine

Swift 2 als TimeMachine

21.06.2015

Kommt Ihnen die Entwicklung von Swift 2 auch ein bisschen so vor, wie eine Reise in die Vergangenheit? Als Apple die neue Programmiersprache im Juni 2014 vorstellte, wirkte sie noch ziemlich unfertig. Die mehreren Jahre Entwicklungszeit sah man ihr nicht an. Sie erschien eher, wie das Ergebnis eines durchprogrammierten Wochenendes mit zu wenig Schlaf.

Sie konnte ihre Nähe zu Java nicht verbergen. Gab es doch jetzt endlich wieder NullPointerExceptions, da sich Optionals nicht stringent aus den Objective-C Headern herleiten ließen. Dem fiel ein mächtiges Konzept der Vorgängersprache zum Opfer, das für mich beim Entwickeln eine Riesenhilfe war. Ich nenne es das „gutmütige nil“.

Ich glaube, schon in Smalltalk konnte man auf dem nil-Zeiger jede Methode aufrufen und das Ergebnis war auch wieder nil. Oder 0 oder NO, wenn man das Ergebnis einen anderen Datentyp hatte. Das erspart viele Abfragen. Verglichen mit Java und auch mit Swift war der Code kompakter, übersichtlicher und besser lesbar. Anstatt mit den Optionals auf diesen Komfort zu verzichten, hätte man ihn noch ausbauen können. Wenn die Fast Enumeration auch mit nil als Container funktionieren würde, oder bei Zugriffen in ein Array mit nicht vorhandenen Index auch einfach nil zurück geliefert werden würde, könnten weitere umständliche Prüfungen entfallen.

Mit Swift 2, dass auf der diesjährigen Entwicklerkonferenz von Apple vorgestellt wurde, hat man sich weiter hin zu Java entwickelt. Und zu Perl! Warum gibt es bei if let-Konstrukten noch ein optionales where? Warum werden try, guard und defer mit völlig unintuitiven Semantiken eingeführt? Es gibt wieder ein zusätzliches Exception-Handling mit versteckten Variablen. Es scheint als habe Apple versucht, es so vielen Entwicklern wie möglich recht zu machen. Jede Idee wurde aufgenommen, wenn sich damit ein paar Tastenanschläge einsparen lassen. Das Ergebnis ist keine runde Programmiersprache, sondern Stückwerk. Swift ist durch die vielen überlappenden Features schwer zu erlernen, zumal manche Klimmzüge in der Vergangenheit bei Objective-C begründet liegen.

Objective-C hat auch seine Macken, die hauptsächlich auf die C-Herkunft zurückzuführen sind. Präprozessor und die Basis-Datentypen machen einem das Leben schwerer als notwendig. Ich muss jedes Mal nachschlagen, wenn eine Variable oder ein Argument ein Funktionszeiger oder ein Block ist. Aber wenn man möchte, hat man direkten Zugriff auf den Prozessor sogar mit Inline-Assembler.

Die Funktionalen Aspekte von Swift reizen mich als alten Scheme-Liebhaber natürlich. Aber ich weiß nicht, ob sie reichen, wieder zu Java zurückzuschreiten. Wie eine Reise in die Vergangenheit kommen mir die neuen Features vor. Dabei werden sie gefeiert, als wären sie die nächste Entwicklungsstufe nach der objektorientierten Programmierung. Vieles sind nur Fehlerbehebungen des ersten Aufschlags. Ist Objective-C schon so weit weg aus unserer Wahrnehmung gerückt? Oder Smalltalk? Oder Scheme? Type-Inference gibt es auch in C++, in Haskell und in Oracles PL/SQL.

Ich hätte mir mehr Struktur gewünscht. Dass ich dem Sourcecode entnehmen kann, woher ein Bezeichner kommt. Durch explizite Imports würden sich auch die Bauzeiten reduzieren, da nicht für die Übersetzung einer Datei alle Dateien gelesen werden müssten (es könnte ja eine globale Variable darin definiert werden).

Ich bin enttäuscht. Apple hätte das Zeug, eine große neue Sprache einzuführen. Leider verspielen sie ihr Potential und liefern nur Durchschnitt. Immerhin erhalten nun andere Sprachendesigner eine Chance, vor der Übermacht von Java und C# sichtbarer zu werden. Denn sicherlich wird Swift sich Anteile von den beiden Giganten holen. Vielleicht wird die Programmierlandschaft etwas vielfältiger. Das wäre in jedem Fall zu begrüßen.


Kommentare

Haben Sie Ergänzungen oder Korrekturvorschläge zu dem Eintrag? Bitte senden Sie eine E-Mail an timm@knp.de. Gerne veröffentliche ich interessante Beiträge zu diesem Artikel.