Typisch Apple!

Apple Swift – Brauchen wir wirklich noch eine neue Programmiersprache? [Kommentar]

Hartmut Schlosser

Swift ist derzeit der am hellsten leuchtende Stern am Programmiersprachen-Himmel. Für viele war die Präsentation des Objective-C-Nachfolgers die spannendste Ankündigung Apples auf der WWDC 2014 – ausgenommen freilich für die reinen Apple-Konsumenten, für die eine neue Programmiersprache so interessant sein dürfte wie ein Blackberry-Update. Doch wird Apples designierter Objective-C-Nachfolger seinen kometenhaften Aufstieg fortsetzen, oder wie so viele Sprachen beim Eintritt in die Atmosphäre des Alltagsgeschäfts wieder verglühen? Angesichts der wahrlich galaktischen Sprachenvielfalt fragen sich heute viele: Brauchen wir wirklich noch eine neue Programmiersprache?

Während die Apple-Keynote für Consumer nur wenig Neues zu bieten hatte, führte sie in Entwicklerkreisen zu wahren Begeisterungsstürmen. Mit der Vorstellung einer neuen Programmiersprache für Cocoa und Cocoa Touch hatten wohl die wenigsten gerechnet. Auf Anhieb war das Interesse der Entwicklerzunft riesig, und auch das Feedback zur Sprache selbst fiel durchweg positiv aus. Nachdem der Überraschungseffekt nun allerdings verflogen ist, mischen sich durchaus auch kritische Stimmen in den Chor der Kommentatoren.

Apples eigenes Süppchen

Klar – verglichen mit Objective-C ist Swift eine deutliche Verbesserung: Zu viele Altlasten hatten sich in Objective-C angesammelt, die die 30 Jahre alte Sprache geschwätzig, schwer erlernbar, schwer lesbar und darüber hinaus auch fehleranfällig machte. Im Vergleich zu Objective-C stehe bei Swift die Syntax dem Verständnis nun nicht mehr im Weg, kommentierte Tammo Freese hier auf JAXenter:

In Swift brauchen wir keine Typangabe bei der Variablen, weil sie aus dem zugewiesenen Wert abgeleitet wird. Wir haben keine kryptische Blocksyntax, kein NS-Prefix, keine Pointer, kein @, keine unleserliche String-Interpolation, kein Semikolon am Zeilenende. Einfach und schön.

Und doch kann man sich fragen, warum Apple mit Swift wieder sein eigenes Süppchen kocht und nicht – etwa wie Googles Android mit Java – auf eine existierende Sprache setzt.

Just for the Apple crowd

Gabe Sumner (Telerik) rät Entwicklern in seinem Artikel Why Most Developers Should Avoid Apple’s New Swift Language dazu, statt auf eine weitere Sprache zu setzen, die proprietär nur einem einzigen Zweck dient, lieber Standards zu unterstützen. Und in der Tat: Wie Objective-C wird wohl auch Swift irrelevant außerhalb des Apple-Ökosystems sein. Anders als bei Webtechnologien wie HTML5, Java für Android – und auch anders als beispielsweise Googles Go, Googles Dart, Mozillas Rust oder Microsofts TypeScript, scheint eine übergreifende Nutzung von Swift überhaupt nicht angestrebt zu werden.

Summers Fazit lautet: Swift ist eine kluger Schachzug für Apple, bringt aber Mobile-Entwicklern generell wenig, da diese weiterhin mit einer fragmentierten Mobile-Landschaft zu kämpfen haben.

Swift is a great move for Apple and exciting news to developers who are willing to commit exclusively to iOS. But most mobile developers are better served by cross-platform technologies which enable them to engage with everyone; not just the Apple crowd.

Technologisch hat Swift keine Daseinsberechtigung

Nun ist der Rat Sumners, auf Cross-Platform-Technologien zu setzen, nicht verwunderlich, da der Telerik Marketing Manager hier geschickt die eigene Mobile-Entwicklungs-Plattform ins Spiel bringen kann. Dennoch ist die Frage nicht ausgeräumt, ob die Welt tatsächlich eine neue Programmiersprache braucht, die proprietär ist und darüber hinaus konzeptuell nichts wirklich Neues bietet.

Selbst Swift-Erfinder Chris Lattner schreibt in seinem Blog, er habe sich beim Sprachdesign von zahlreichen existierenden Sprachen inspirieren lassen:

Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list.

Darüberhinaus scheint man auch bei Swift wieder Zugeständnisse an die Objective-C-Interoperabilität machen zu müssen. Rust-Erfinder Graydon Hoare kommentiert:

It appears to have „Objective C object model interop“ as a hard design constraint, which limits some of the stuff they can safely do.

Man könnte also folgern: Aus technologischer Hinsicht hat Swift keine Daseinsberechtigung. Es führt nichts neu ein, was man nicht schon in anderen Sprachen gesehen hätte. Ist die Begeisterungswelle im Apple-Lager also nur deshalb so hoch, weil die Hürde so niedrig lag? Wäre nicht jede Veränderung am Objective-C-Desaster gefeiert worden?

Swift: Typisch Apple!

Nun, wer diese Fragen stellt, hat zwar womöglich recht, kennt aber Apple schlecht. Swift ist geradezu ein Paradebeispiel für den Unternehmensethos, den viele bei Apple kritisieren, den Apple aber auch groß gemacht hat.

Wie Swift-Entwickler Chris Lattner in einem Blogpost verrät, arbeitet man bei Apple bereits seit 2010 an der Programmiersprache – hinter verschlossenen Türen, selbstredend. Lattner habe das meiste der grundlegenden Sprachstruktur implementiert, während nur wenige Leute von der Existenz von Swift gewusst hätten, schreibt er in seinem Blog. Einige Mitstreiter am Projekt kamen 2011 ins Spiel, während Swift erst 2013 von Apples Developer-Tools-Gruppe ins Visier genommen wurde.

Swift entstand also zu einer Zeit, in der Google mit Android die größten Verbreitungsraten erzielte – Android überholte das iPhone im Jahr 2011. Die Offenheit von Android und die niedrige Einstiegshürde durch den Einsatz von Java dürfte damals einiges an Androids Erfolg ausgemacht haben – und zweifellos Druck auf Apple ausgeübt haben, die eigene Plattform für Entwickler attraktiver zu machen.

Statt sich nun allerdings am Android-Beispiel zu orientieren, geht Apple anders vor: Swift bleibt proprietär, setzt nicht auf Standards, wird lange geheim gehalten und der Entwickler-Community in nahezu fertigem Zustand präsentiert: inklusive 500-Seiten Manual und Tool-Integration (Swift ist in die Beta-Versionen für Xcode 6 integriert).

Swifts Schwäche, Apples Stärke

Was in der Blogosphäre also an Swift kritisiert wird, könnte genauso gut den Erfolg von Swift ausmachen. Anders als Dart, Go, Rust, TypeScript hat Swift einen klar umrissenen Zweck: Die Programmierung für iOS zu erleichtern. Anders als Dart, Go, Rust, TypeScript gibt es für Swift keine wirklichen Alternativen (wenn man Objective-C abschreibt und anerkennt, dass Cross-Plattform-Lösungen eine native Sprache nicht ersetzen).

Darüberhinaus ist der Objective-C-Leidensdruck hoch, sodass man mit einer wechselwilligen Community rechnen kann, die ohnehin dafür bekannt ist, Apple-Produkten treu ergeben zu sein. Und da Swift bekannte Konzepte absorbiert, anstatt Neues zu bieten, findet sich jeder so ein bisschen wieder in der neuen Sprache, was die vielen Vergleiche belegen:

In bekannter Apple-Manier wird uns Swift zudem als Produkt präsentiert, nicht als unfertige 0.Beta mit lückenhafter Dokumentation und nachzureichender Tool-Unterstützung. Was die Performance anbelangt, so sollen auch hier die Parameter von Beginn an stimmen. LLVM-basiert (tatsächlich ist Chris Lattner der ursprüngliche Autor der LLVM Compiler Infrastructure), direkt zu nativem Code kompilierend und die bestehende Cocoa-API- und -Runtime-Infrastruktur nutzend, sollen gegenüber Objective-C nochmals deutliche Geschwindigkeitsgewinne erzielt werden können.

Wozu Swift?

Wozu brauchen wir also noch eine neue Programmiersprache? Im Falle von Swift eben nicht, um besonders innovativ zu sein und neue, akademische Sprachfeatures zu implementieren, die nur die Wenigsten verstehen. Im Falle von Swift ist es der „Killer-App-Aspekt“, der unwiderstehliche Anwendungsfall aus der Praxis, der darin besteht, die Programmierung für iOS dramatisch zu vereinfachen.

Wie Chris Lattner sind wir gespannt, wie es weiter geht mit Swift. Ab Herbst sollen Apps, die mit Swift programmiert wurden, bereits in den App Store gestellt werden können. iOS-Entwicklern dürfte es also nicht schwer fallen, das Sommerloch zu stopfen. Jede Wette, dass Swift Objective-C und Sprachneulinge wie Go, Dart, TypeScript, Rust bald überholt haben wird, in den einschlägigen Programmiersprachen-Popularitätsindices.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: