10 Dinge zu Apples neuer Programmiersprache Swift

Zum Zeitpunkt des Verfassens dieses Artikels sind kaum 48 Stunden vergangen, seit Apple die neue Programmiersprache “Swift” vorgestellt hat. Normalerweise gäbe es sicher keinen so großen Aufruhr zu einer neuen Sprache, aber vor allem wegen Apples Dominanz im mobilen App Markt darf man annehmen, dass die Sprache in Zukunft einen nicht ganz unerheblichen Einfluss auf die entsprechenden Geschäftsfelder haben wird.

Vordenker zu sein ist ein elementarer Wert der codecentric und so ist es kein Wunder, dass einige von uns sich direkt in die Sprach-Dokumentation eingelesen haben. Ich gehöre zu den Neugierigen, muss aber auch zugeben, dass ich es nicht geschafft habe, das gesamte Buch (860 Seiten…) zu lesen, bevor ich angefangen habe selbst Code zu schreiben.

Apple ermuntert sogar dies zu tun, denn die neue Version von Xcode (6 beta), die man für Swift benötigt, bringt ein Feature namens “Playground” mit. Im Grunde handelt sich um eine REPL-Umgebung, also eine interaktive Shell, die es erlaubt einfach loszutippen und die Ergebnisse des Codes direkt nachzuverfolgen. In Swift ist das besonders einfach, da der global scope es erlaubt, Code direkt auszuführen, ohne Klassen oder main-Methoden geschrieben haben zu müssen.

Trotz der Tatsache, dass ich den offiziellen Sprach-Guide “The Swift Programming Language”, auch wegen seiner guten Lesbarkeit, empfehlen kann, dürfen Sie gerne einen Blick in unser Swift-Playground-Repository werfen. Neben interessanten Kleinigkeiten, die wir dort sammeln, haben wir auch ein Mini-Tutorial bereitgestellt. Dieses ist besonders für diejenigen gedacht, die bereits Erfahrung mit anderen Programmiersprachen wie Java haben und sich eher einen Kurzüberblick wünschen. Das Tutorial enthält kaum 350 Codezeilen und gibt einen wirklich kondensierten Blick auf Syntax und Features der Sprache, für die man sonst zumindest die ersten paar hundert Seiten des Sprach-Guides lesen muss.

Neben dem Hinweis auf das Repository möchte ich diesen Blog-Post nutzen, um meine persönliche Meinung zu einigen (frühen und sicher nicht abschließenden) Erkenntnissen beim Experimentieren mit der Sprache zu äußern. Zur Information: Ich habe einen Hintergrund in Ruby, Java und Objective-C. Damit der Post nicht ausufert, habe ich mich auf fünf Punkte “dafür” und “dagegen” beschränkt.

5 Dinge, die ich gut finde

Die Syntax. I mag die Syntax von Objective-C, hauptsächlich wegen der benannten Parameter in Methodenaufrufen. Während man in Java foo(true, false, 0, 1, null) liest, sind Aufrufe in objC deutlich besser lesbar – wie jetzt auch in Swift. Mir gefällt auch der Rest der Syntax, etwa der Pfeil -> für die Ankündigung von Rückgabewerten, die Tupel-Notation, die saubere Syntax für Closures und die Annotation von Ausdrücken mit ? und !, was mich zum nächsten Punkt bringt…

Die Handhabung von nil (null). Ich halte es für eine fundamentale Änderung, dass man von der Sprache gezwungen wird nil explizit zu behandeln. nil stellt auch nicht mehr einen Pointer ins Nichts dar, sondern beschreibt vielmehr die Abwesenheit eines Wertes. Auch die Art wie man mit möglichen nil-Werten umgehen kann, indem man ? (Fragezeichen) nutzt, die man sogar aneinander ketten kann, scheint mir recht elegant zu sein und erinnert ein bisschen an die try-Methode aus Rails.

Strenge. Das ist sicherlich Geschmackssache, aber ich bin ein Fan davon, direkt vom Compiler zu erfahren wo ich etwas getan habe, das ich nicht hätte tun sollen. Sowas gibt es für viele Skriptsprachen nicht (außer vielleicht man hat eine sehr gute Entwicklungsumgebung). Außerdem bin ich der Meinung, dass beispielsweise Typsicherheit und andere “Strenge-Features” dazu beitragen, dass man eher gezwungen ist, sich an “gute” Programmierpraktiken zu halten.

Der “Playground”. Eine interaktive Shell ist eine klasse Sache, wenn man einfach mal ein Stück Code ausprobieren will. Dazu kommt, dass Apple den “Playground” tatsächlich so gestaltet hat, dass man definitiv mehr Einblick darin erhält, was eigentlich passiert. Anfangs dachte ich, dass dies etwas wie irb – die Ruby-Shell – wäre, aber der “Playground” liefert tatsächlich mehr und ist – gerade zum Lernen – sehr gut gemacht.

Die (zukünftige) Akzeptanz und der Support von Entwicklern. Wie oben schon geschrieben könnte man meinen, dass jeden Tag eine neue Programmiersprache veröffentlicht wird. Neben einigen wenigen, die es geschafft haben zumindest ein wenig auf die Mainstream-Schiene zu kommen, werden wenige wirklich geschäftsrelevant. Wegen Apples großem Markteinfluss – insbesondere im mobilen Bereich – wird das hier sicher anders sein. Es wird sicher noch einige Zeit vergehen bis jemand Swift als Mainstream bezeichnet, aber in den kommenden Monaten und Jahren wird es deutlich mehr Job-Angebote mit Swift-Anforderungen geben als etwa für Rust, die eigentlich recht ähnlich ist. Dieser Punkt gefällt mir, weil ich die Sprache insgesamt für eine moderne, konzeptuell gut durchdachte Sprache halte, unabhängig davon was ich im folgenden Abschnitt schreiben werde.

5 Dinge, bei denen ich (mindestens) skeptisch bin

Any und AnyObject. Es scheint so als würden einige der Cocoa-APIs, die noch immer auf Objective-C und C zurückgreifen, oftmals Werte des Typs AnyObject zurückliefern. Nach wenigen Minuten des Ausprobierens fiel mir etwa dequeueReusableCellWithIdentifier(String) auf. Von der Methode hätte ich den Rückgabetyp UITableViewCell? erwartet. Stattdessen wird AnyObject! (mit !) geliefert – und das kann überraschenderweise ein objC nil enthalten. Ich schätze jedoch, dass die API diesbezüglich in späteren Releases noch überarbeitet werden wird.

Extensions. Etwas, das ich schon in Ruby nicht so gerne mag ist das “Patchen” von Klassen. Mit Swift kann man über Extensions Klassen nachträglich um Methoden oder sogar Konstruktoren erweitern. Ich habe bisher noch keine Dokumentation dazu gefunden wie hier Konflikte behandelt werden, aber Extensions könnten die Nutzung von Komponenten Dritter recht schwierig machen, weil sicher jeder seine eigenen Convenience-Methoden in String und Array patchen wird.

Array. Wo ich schon mal bei Arrays bin, diese zeigen ein etwas merkwürdiges Verhalten beim Kopieren beziehungsweise Vergrößern. Wenn a und b das gleiche Array referenzieren und a danach vergrößert wird (etwa durch Hinzufügen eines Objekts) dann ist b immer noch das alte Array und a ein komplett neues Objekt. Das könnte damit zu tun haben, dass man in einem Objekt selbst self neu zuweisen kann, vielleicht auch mit etwas anderem. Ungewohnt in jedem Fall.

Die Dynamik. Objective-C kam mir mit dem Konzept von Messages immer sehr dynamisch vor. Die Strenge von Swift (die oben noch gelobt wurde) scheint im Moment aber gewisse Dynamik-Features zu verbieten. Etwa das Aufrufen von Methoden oder Lesen von Properties, wenn der Name in einem String bekannt ist. Nur mit dem Sprach-Guide fühle ich mich nicht in der Lage etwa einen JSON zu Object-Mapper zu schreiben. Vielleicht habe ich das bisher überlesen, vielleicht kommen solche Features auch später noch dazu.

Dinge, die fehlen. Zuallererst: Sichtbarkeitseinschränkungen. Derzeit scheint es keinen Mechanismus für private Methoden oder Properties zu geben. Insbesondere bei letzteren habe ich bisher auch keinen Weg gefunden, diese wenigstens außerhalb der Klasse nur lesbar zu gestalten. Genauso findet sich im Sprach-Guide nichts zu Exceptions oder Errors. Zwar werden Fehler zur Laufzeit erwähnt, aber nicht wie (oder ob) man darauf reagieren kann. Ebenso wird kein Wort über Multi-Threading-Mechanismen verloren. Sicher gibt es Wrapper für NSThread, aber gerade NSArray hatte doch so nette Methoden, die die Nutzung von Blöcken etwa für das parallele Iterieren über Objekte erlaubt haben. Sicher gibt es noch viel mehr, das im Moment einfach “fehlt”, aber die Sprache ist ja noch neu, insofern würde ich diese Mängel nicht zu stark gewichten.

Wrap-up

Zusammenfassend würde ich sagen, dass ich sicherlich Spaß daran hätte Swift-Code zu schreiben. Gerade wenn man Swift erst mal nur als Ersatz für Objective-C beim Schreiben von iOS- und OS X-Anwendungen sieht, fällt doch deutlich “nerviger” Overhead weg. Trotzdem, bis ich bei einer neuen Idee aufspringe und rufe, “Das schreibe ich in Swift!”, fehlt mir zum jetzigen Zeitpunkt einfach noch zu viel, das ich als wichtig erachte.

Haben Sie schon mit Swift experimentiert? Teilen Sie Ihre Meinung in den Kommentaren!