Schnelles Programmieren lernen: Ist es bereit für die Hauptsendezeit?

Apples Einführung von Swift im vergangenen Juni, einer neuen Programmiersprache zum Schreiben von iOS-Apps, hat in der gesamten iOS-Entwicklergemeinschaft für viel Begeisterung und Aufregung gesorgt.

Seit der Markteinführung kämpfen viele iOS-Entwickler mit der Frage, ob, wie und wann der Übergang von Objective-C zu Swift erfolgen soll. Die Antwort auf diese Frage wird natürlich für jedes Team und jedes Projekt anders sein.

Es gibt eine Reihe von Artikeln, die Sie lesen können und die viele der Vorteile von Swift behandeln. Anstatt also dieselben Punkte noch einmal aufzuwärmen, konzentrieren wir uns in diesem Artikel stattdessen auf einige der Bedenken, die Sie berücksichtigen sollten, bevor Sie sich mit der App-Entwicklung mit Swift vertraut machen.

Aber zuerst drehen wir die Uhr ein wenig zurück…

Vor Swift: Sie werden Objective-C verwenden und es wird Ihnen gefallen …

Wir schreiben das Jahr 2010. Das iPhone war noch keine 3 Jahre alt, und die Möglichkeit, native Apps für das iPhone zu schreiben, gab es erst seit etwa 2 Jahren. Am 8. April dieses Jahres kündigte Apple die Version des iPhone OS an. Das iPhone-Betriebssystem (das war, bevor es seinen Namen in iOS änderte) enthielt so verlockende neue Funktionen wie Multitasking, schnelles Wechseln zwischen Anwendungen und Hintergrunddienste. Verständlicherweise wollten die iPhone-Entwickler unbedingt das neue SDK in die Hände bekommen und mit all diesen aufregenden neuen Funktionen spielen.

Aber das iPhone OS 4 SDK enthielt eine unerwartete Bombe. Diese Bombe stand nicht in der Software, sondern in der Nutzungsvereinbarung. Mit dem iPhone OS 4 SDK wurde Abschnitt 3.3.1 der Entwicklervereinbarung aktualisiert, um die folgenden beunruhigenden Formulierungen aufzunehmen:

Anwendungen müssen ursprünglich in Objective-C, C, C++ … geschrieben sein und nur in C, C++ und Objective-C geschriebener Code darf kompiliert und direkt mit den dokumentierten APIs verlinkt werden.
– Abschnitt 3.3.1 der iPhone OS 4 SDK-Entwicklervereinbarung

Unnötig zu erwähnen, dass diese neue Einschränkung viele Entwickler überrascht hat. Der offizielle Grund für die Änderung, der von Steve Jobs selbst angegeben wurde, war, die Verwendung von plattformübergreifenden Tools wie dem kürzlich angekündigten Flash CS5 zu verhindern. Jobs wurde mit den Worten zitiert, dass „Zwischenschichten zwischen der Plattform und dem Entwickler letztendlich [sic] minderwertige Apps produzieren“. Aber die Tatsache, dass Apples Ansatz zur Bekämpfung dieser „Zwischenschichten“ darin bestand, einzuschränken, welche Programmiersprachen zum Schreiben von iPhone-Apps verwendet werden könnten, offenbarte etwas mehr über Apples Denken: Objective-C sollte für jeden gut genug sein.

Man könnte dieser Behauptung zustimmen, da Objective-C zwei Jahre in Folge die Auszeichnung „Programmiersprache des Jahres“ des Tiobe-Index gewonnen hat. Aber die Realität war, dass die Popularität von Objective-C eine Funktion des wachsenden App-Ökosystems war und nicht umgekehrt. Schon 2010 waren viele Menschen mit Objective-C unzufrieden und so tauchten bereits alternative Möglichkeiten auf, iPhone-Apps in anderen Programmiersprachen zu schreiben.

Schließlich hob Apple diese Änderungen an Abschnitt 3.3.1 der SDK-Entwicklervereinbarung nur fünf Monate später auf Druck der Entwicklergemeinschaft insgesamt auf. Dennoch war die Botschaft klar: Wenn Sie Apps für das iPhone schreiben wollten, sollten Sie wahrscheinlich Objective-C verwenden.

… oder vielleicht nicht. Geben Sie die neue iOS-Sprache Swift ein.

Spulen Sie 4 Jahre von diesem Vorfall bis Juni 2014 vor, als Apple Entwicklern seine neue Sprache Swift vorstellte. Wenn die Botschaft von vor 4 Jahren war, dass Apple mit Objective-C vollkommen zufrieden war, dann war die Botschaft von Swifts Einführung, dass Apple endlich bereit war, die Wahrheit zuzugeben. Objective-C ist möglicherweise nicht unbedingt die beste Sprache zum Schreiben mobiler Apps.

Es wurde viel darüber gesagt, dass Swift eine „modernere“ Sprache als Objective-C ist. Wenn Sie daran interessiert sind, die Programmiersprache Swift zu lernen, sollten Sie sich den Leitfaden für den Wechsel von Objective-C zu Swift ansehen.

Was Sie jedoch beachten sollten, ist, dass es zwei wichtige Unterschiede zwischen den Sprachen Objective-C und Swift gibt:

1. Swift ist keine strikte Obermenge der C-Sprache.
2. Swift ist statisch typisiert, nicht dynamisch typisiert.

Da es sich nicht um eine strikte Obermenge von C handelt, steht es Swift frei, Syntaxkonstrukte zu verwenden, die andernfalls nicht erlaubt wären. Dadurch ist es beispielsweise möglich, benutzerdefinierte Operatoren in Swift zu implementieren.

Statisch typisiert zu sein bedeutet, dass Swift viele der jüngsten Fortschritte bei Typsystemen nutzen kann, die von Sprachen wie Haskell entwickelt wurden.

Obwohl Swift 4 Jahre in der Entwicklung war, bevor es der Öffentlichkeit vorgestellt wurde, ist es immer noch eine junge Programmiersprache, daher gibt es eine Reihe von Einschränkungen.

Kompatibilität mit Objective-C

iOS teilt ein gemeinsames Erbe mit OS X, das wiederum seine Geschichte vom NeXTSTEP-Betriebssystem hat, das erstmals 1989 veröffentlicht wurde. NeXTSTEP wurde ursprünglich größtenteils in Objective-C geschrieben, und viele der Kernbibliotheken in OS X und iOS verfolgen alle ihre Wurzeln den Weg zurück zu diesen ursprünglichen Implementierungen. (Hierher stammt übrigens das allgegenwärtige „NS“-Präfix, das auf Kernklassen wie NSString zu finden ist.) Während Swift theoretisch ohne diese Kernbibliotheken existieren könnte, ist die Realität, dass Sie in naher Zukunft alle Swift-Programme schreiben könnten muss eine Schnittstelle mit Objective-C haben.

Man muss den Entwicklern von Swift zugutehalten, dass sie fantastische Arbeit geleistet haben, um die Interaktion mit bestehenden Objective-C-Bibliotheken so einfach wie möglich zu gestalten. Das heißt aber nicht, dass der Prozess völlig schmerzfrei ist. Apple hat eine hilfreiche Anleitung bereitgestellt, die erklärt, wie man Objective-C-Code von Swift aus aufruft und umgekehrt, aber es gibt einige wichtige Impedanz-Fehlanpassungen, die man beachten sollte.

Die vielleicht offensichtlichste Diskrepanz bezieht sich auf Header-Dateien. Objective-C erfordert aufgrund seiner C-Wurzeln immer noch, dass Funktionen deklariert werden, bevor sie aufgerufen werden. Beim Aufrufen einer Bibliothek werden diese Deklarationen in den Header-Dateien der Bibliothek gefunden. Swift verwendet jedoch keine Header-Dateien. Wenn Sie also Swift-Code von Objective-C aufrufen möchten, müssen Sie zunächst einen „Bridging Header“ erstellen. Während dies konzeptionell nicht so komplex erscheint, kann es in der Praxis tatsächlich eine ziemliche Aufgabe sein.

Eine weitere Reihe von Komplikationen bei der Schnittstelle zwischen Swift und Objective-C ergibt sich aus den inhärenten Unterschieden in ihren Typsystemen. In Anlehnung an andere moderne Sprachen hat Swift das Konzept von nil . An seiner Stelle stehen die optionalen Typen von Swift. Beispielsweise hätte eine Methode, die eine Datei nur öffnet, wenn sie bereits vorhanden ist, den Rückgabetyp File? (statt nur File ) in Swift. Indem er alle Stellen verfolgt, an denen Typen optional sind, kann der Swift-Compiler es effektiv unmöglich machen, auf den gefürchteten „Null Pointer Error“ zu stoßen. Das heißt natürlich, es sei denn, Sie rufen Objective-C an. Da Objective-C keine solchen Garantien dafür gibt, dass nil nicht zurückgegeben wird, hat Swift eine spezielle Kategorie von Typen namens Implicitly Unwrapped Optionals , die beim Aufrufen von Objective-C-Code verwendet werden. Diese Typen können in der Swift-Sprache als optional behandelt werden, zusammen mit dem gesamten damit verbundenen Overhead, der für die Existenzprüfung erforderlich ist. Alternativ können sie wie jeder nicht optionale Typ verwendet werden, aber wenn Objective-C einen nil , erhalten Sie einen Laufzeitfehler, sodass Sie einige der Sicherheitsgarantien von Swift zur Kompilierzeit verlieren.

Schließlich hat ein etwas subtilerer Unterschied, der beim Programmieren zwischen Swift und Objective-C zu berücksichtigen ist, damit zu tun, wie Objekte und Klassen in diesen beiden Sprachen verdeckt erstellt werden. Objective-C verwendet aufgrund seiner dynamischen Natur den dynamischen Versand, um Methoden für Objekte aufzurufen (über objc_msgSend ). Swift kann sicherlich dynamisches Dispatch verwenden, aber da es statisch typisiert ist, hat es auch die Möglichkeit, eine vtable zu verwenden, um Funktionszeiger für jede Methode zu speichern. Welcher dieser beiden Mechanismen Swift verwendet, hängt von einigen Faktoren ab. Ebene alte Swift-Objekte verwenden den vtable Mechanismus, es sei denn, die Klasse oder Methoden innerhalb der Klasse sind mit dem @objc Swift-Attribut kommentiert. Swift-Klassen, die von Objective-C-Klassen erben, verwenden die dynamische Weiterleitung für geerbte Methoden, jedoch nicht für neue Methoden, die von der Unterklasse eingeführt wurden (obwohl Sie die Verwendung der dynamischen Weiterleitung auch hier mit dem Attribut @objc können). Unabhängig davon wird Swift-Code immer in der Lage sein, mit Swift-Klassen zu arbeiten, aber Objective-C-Code kann nur Swift-Objekte und -Methoden verwenden, die ordnungsgemäß annotiert wurden.

Schneller als Objective-C?

Als Apple seine Markteinführung vorstellte, war einer der Vorteile von Swift, der besonders hervorgehoben wurde, seine Geschwindigkeit. Dies ist verständlich, wenn man bedenkt, dass ein Grund für die Zurückhaltung von Apple, von Objective-C auf eine höhere Programmiersprache umzusteigen, oft damit begründet wurde, dass Objective-C, im Wesentlichen eine Erweiterung von C, in der Lage war, viel schnellere und effizientere Programme zu erstellen als etwas wie Python oder Ruby. Trotzdem ist Objective-C kein Raketenschiff, wenn es um absolute Leistung geht, und vieles davon kann auf dynamisches Tippen zurückgeführt werden. Da Swift also ein statisches Typsystem einführt, würde man erwarten, dass Swift mindestens so schnell oder schneller als Objective-C sein sollte.

Natürlich, wie das Sprichwort sagt: „Es gibt drei Arten von Lügen: Lügen, verdammte Lügen und Benchmarks.“ (Oder so ähnlich …) Sicherlich gibt es zahlreiche Gründe, warum die Swift-Sprache möglicherweise schneller läuft. Leider scheint es, dass die Art und Weise, wie Swift Apples ARC-Technik (Automatic Reference Counting) für die Speicherverwaltung verwendet, manchmal dazu führt, dass Swifts Compiler erheblich langsamere Programme generiert, insbesondere mit niedrigeren Optimierungseinstellungen (wie Sie sie beispielsweise während der Entwicklung verwenden). Die gute Nachricht ist, dass es so aussieht, als würden Verbesserungen an Swift dieses Problem kontinuierlich angehen, und es ist daher wahrscheinlich, dass Swift in naher Zukunft ausführbare Dateien mindestens so schnell oder schneller als Objective-C generieren wird.

Es gibt jedoch eine weitere Einschränkung bezüglich der Geschwindigkeit von Swift. Der springende Punkt bei Swift ist, dass Entwickler nicht denselben Code schreiben, den sie in Objective-C geschrieben hätten. Was bedeutet das für die Leistung? Nun, es bedeutet sicherlich, dass der Vergleich der Leistung zwischen Swift und Objective-C komplizierter ist, als einfache Benchmarks zeigen können. Das bedeutet auch, dass der Vergleich der absoluten Laufzeitleistung generierter ausführbarer Dateien nur die halbe Wahrheit erzählt.

Jeder will schnelle Programme, aber oft ist die Entwicklungsgeschwindigkeit genauso wichtig – wenn nicht sogar wichtiger. Eine Sprache, die ausdrucksstärker ist und in der Lage ist, mehr Arbeit in weniger Codezeilen zu erledigen, kann in dieser Hinsicht ein großer Vorteil sein. Wenn Sie andererseits in einer kompilierten Sprache arbeiten, in der der Bearbeitungs-Kompilierungs-Ausführungs-Debug-Zyklus einen Großteil des Tages eines Programmierers einnimmt, kann ein langsamer Compiler die Produktivität wirklich beeinträchtigen. Während die Beweise hauptsächlich anekdotisch sind, scheint es, dass der Swift-Compiler derzeit gerade langsam genug ist, um lästig zu sein, insbesondere wenn mit Code gearbeitet wird, der das fortschrittliche Typsystem von Swift ausübt. Eine Gruppe fand sogar die Kompilierungsgeschwindigkeit problematisch genug, um einen Wechsel zurück zu Objective-C zu motivieren.

Der Compiler

Apropos Swift-Compiler, er selbst ist die Quelle von noch mehr Vorbehalten, wenn man erwägt, auf die neue Swift-Sprache umzusteigen. Abgesehen von der Kompilierungsgeschwindigkeit, als Swift aus dem kleinen Kader von Entwicklern hervorgegangen ist, die damit bei Apple arbeiten, und auf die Massen losgelassen wurde, hat der Compiler begonnen, Risse unter dem Stress zu zeigen. Es gibt sogar ein ganzes GitHub-Repository, das dem Sammeln von Codebeispielen gewidmet ist, die den Swift-Compiler zum Absturz bringen.

Außerdem stellt sich die Frage, wie sich der Swift-Compiler verändern wird. Ein weiteres Projekt auf GitHub sammelt Spekulationen und Analysen aus der Community darüber, welche Änderungen für Swift bevorstehen könnten. Beispielsweise können benutzerdefinierte Operatoren einen Parser erheblich belasten. Anfänglich konnten benutzerdefinierte Operatoren in Swift kein Fragezeichen (?) verwenden. Obwohl dies in der neuesten Swift-Version behoben wurde, strömen weiterhin Anfragen von der wachsenden Community von Swift-Entwicklern nach noch mehr Flexibilität bei dem, was als gültiger benutzerdefinierter Operator angesehen werden kann.

Jedes Mal, wenn Sie hören, dass der Parser für eine Sprache im Fluss ist, sollten Sie innehalten. Der Parser einer Sprache ist das Herz und die Seele einer Programmiersprache. Bevor eine Sprachsemantik angewendet werden kann, um dem Code eine Bedeutung zu verleihen, ist es der Parser, der zunächst bestimmt, was gültiger Code ist und was nicht. Es ist daher ermutigend, dass Apple versprochen hat, ein gewisses Maß an Laufzeitkompatibilität für Swift sicherzustellen. Das garantiert jedoch nicht unbedingt, dass Swift-Code ausgeführt wird, ohne für jede neue Version von Xcode und/oder iOS neu kompiliert zu werden. Es garantiert auch nicht, dass Sie Teile Ihres Swift-Codes nicht neu schreiben müssen, um mit zukünftigen Versionen von Swift kompatibel zu bleiben. Aber auch hier ist Apples Engagement, diesen Prozess so schmerzlos wie möglich zu gestalten, zumindest ein kleiner Trost.

Gemeinschaft

Einige der schlechtesten Programmiersprachen, die jemals geschaffen wurden (die namenlos bleiben sollen), wurden vorangetrieben, lange nachdem der gesunde Menschenverstand sagt, dass sie allein aufgrund der Stärke ihrer jeweiligen Gemeinschaften in den Mülleimer der gescheiterten Technologie hätten verbannt werden sollen. Gleichzeitig ist die Sammlung wirklich schöner Programmiersprachen, die sich mangels einer Community nicht durchgesetzt haben, zu zahlreich, um sie zu zählen. Starke Gemeinschaften produzieren Tutorials, beantworten Fragen zu Stack Overflow, hängen online oder persönlich auf Konferenzen ab, um Geschichten, Tipps und Tricks auszutauschen, und schreiben und teilen nützliche Bibliotheken miteinander. Bei der Wahl der Sprache, die für ein Projekt verwendet werden soll, ist Community definitiv etwas, das berücksichtigt werden sollte.

Leider hat die iOS/Objective-C-Community nicht den besten Ruf, freundlich und einladend zu sein. Das ändert sich allmählich und Open Source spielt eine immer wichtigere Rolle in der Objective-C-Entwicklung. Dennoch ist es in diesem frühen Stadium schwer zu sagen, wie die Swift-Community in Zukunft aussehen wird. Wird es hauptsächlich aus Inselentwicklern bestehen, die nur mit den offiziellen Apple-APIs und ihren eigenen privaten Codesammlungen arbeiten? Oder wird es eine lebhafte Gemeinschaft von Gruppen sein, die Tipps, Tricks und nützliche Bibliotheken austauschen?

Ein weiterer Aspekt der Rolle der Community ist die Rolle der Swift-Entwickler selbst. Der allgemeine Trend in der Programmierung geht weg von proprietären Programmiersprachen und Plattformen hin zu Open-Source-Lösungen. Open-Source-Entwicklung, insbesondere auf der Ebene von Programmiersprachen und Laufzeiten, kann ein echter Vorteil sein. Während die Swift-Entwickler mehrfach erklärt haben, dass sie beabsichtigen, die Swift-Sprache und -Laufzeit vollständig als Open Source zu öffnen, muss dies noch geschehen, sodass Vorsicht geboten ist.

Allerdings sind die Entwickler hinter Swift einige der gleichen Entwickler hinter dem langjährigen LLVM-Projekt. LLVM ist keine perfekte Analogie, da es als offenes Projekt der University of Illinois, Urbana-Champaign, ins Leben gerufen wurde. Aber man muss ihnen zugutehalten, dass die Core-Entwickler sehr offen und engagiert mit der Community geblieben sind, selbst nachdem die meisten von ihnen zu Apple gewechselt waren. Es ist völlig vernünftig zu erwarten, dass die Swift-Sprache (größtenteils) offen weiterentwickelt wird, obwohl abzuwarten bleibt, ob Patches und Funktionsvorschläge aus der Community jemals ihren Weg in die Sprache finden werden.

Soll ich Swift lernen?

Hier gibt es natürlich keine „one size fits all“-Antwort. Wie immer erfordert die Auswahl des richtigen Werkzeugs für den Job eine genaue Kenntnis aller Details des betreffenden Projekts. Sicherlich bleibt Objective-C zu diesem Zeitpunkt die „sichere“ Wahl für die iOS-Entwicklung, aber Swift ist definitiv eine Überlegung wert.

Die bedeutendste Änderung, die Swift in die iOS-Entwicklung bringt, ist jedoch, dass sich viele Entwickler zum ersten Mal die Frage stellen werden: „Welche Sprache soll ich verwenden?“ Angesichts der Geschichte von Apple, Objective-C und der iOS-Plattform ist allein diese Änderung ziemlich aufregend, insbesondere wenn man bedenkt, dass die Wahl nicht binär ist. Während Apple seine Präferenz deutlich gemacht hat, arbeitet die iOS-Entwicklergemeinschaft insgesamt seit Jahren hart daran, noch mehr mögliche Antworten auf diese Frage zu liefern.