Apples Programmiersprache in Version 2.0

Swift 2.0 wird Open Source: „Als Java-Entwickler kann man sich auf einiges freuen“

Wolfgang Frank, Peter Vegh

©Shutterstock/Paul Reeves Photography

Auf der diesjährigen WWDC Konferenz kündigte Craig Federighi an, dass Apple seine neue, vor einem Jahr veröffentlichte Programmiersprache Swift, genauer gesagt: den Compiler und die Standardbibliotheken, unter einer Open-Source-Lizenz veröffentlichen wird. Dies soll mit der kommenden Version 2.0 bis Ende dieses Jahres geschehen, bzw. sobald diese den finalen Status erreicht hat.

Apple hat vor, diese Komponenten auch für Linux zu veröffentlichen, was bedeuten könnte, dass ein Entwickler irgendwann möglicherweise gar nicht mehr zwingend Apple-Geräte braucht, um für die Plattform zu entwickeln.

Und warum hatt Cupertino vor einem Jahr überhaupt eine gänzliche neue Programmiersprache aus der Taufe gehoben? Klar – um die mit 32 schon in die Jahre gekommene Sprache Objective-C, welche noch immer die primäre Sprache für Apple iOS- und OSX-Entwickler ist, abzulösen. Objective-C hatte Apple damals durch NeXT eingekauft, als Steve Jobs einige Zeit gezwungenermaßen außerhalb von Apple tätig werden musste.

Durch Swift wird die Lernkurve für viele Entwickler deutlich flacher, um in die „iWelt“ einzusteigen, denn Objective-C war und ist nicht einfach zu lesen und zu schreiben. Vorkenntnisse in Java sind für Objective-C nicht wirklich sehr hilfreich gewesen. Swift jedoch sieht Java an mehreren Stellen sehr ähnlich, bzw. hat sich aus sämtlichen modernen Programmiersprachen bei den „coolen“ Sprachkonzepten bedient. So gibt es zahlreiche Sprachkonstrukte, die man sich als Java-Entwickler schon länger in Java wünscht und die man ohne große Hindernisse sofort mit Swift produktiv einsetzen kann.

Apple bereits ein Open Source Player

Apple ist bereits ein Mitspieler bei verschiedenen Open-Source-Projekten wie beispielsweise Darwin und WebKit, auch wenn die Firma sich nicht in erster Linie durch ihren Open-Source-Einsatz auszeichnet und sich das Thema nicht sehr stark in ihrem bisherigen Geschäftsmodell widerspiegelt. Erst die Open-Source-Veröffentlichung ihres ResearchKit vor Kurzem zeigt wieder eine größere Bewegung in diese Richtung.

Der neuen Sprache kann es nicht schaden, von einer großen und sicherlich fähigen Community noch mehr Input zu bekommen, um dadurch noch schneller eine größere Userbase aufzubauen. Dadurch wird die Hürde für die Adaption von Swift in der Zukunft viel geringer, denn die Sprache werden evtl. so manche Leute dann bereits aus Projekten oder sogar aus Vorlesungen an Schulen oder Hochschulen kennen. Denn Swift eignet sich hervorragend, um verschiedenste Programmierkonzepte zu erlernen und diese elegant umzusetzen.

Anders als bei rein als Open-Source-entwickelten Projekten (oder Programmiersprachen wie Rust) wird die echte Roadmap indes nie ganz transparent sein. Apple wird natürlich vor allem eigene Ziele verfolgen und die Sprache und Tools für die eigenen SDKs (iOS, OSX, watchOS) optimieren. Das könnte zur Folge haben, dass die Wünsche der Community nicht unbedingt im Vordergrund stehen werden. Im Optimalfall werden Verbesserungen und Erweiterungen in Form von Patches dennoch angenommen, konstruktiv diskutiert und zeitnah integriert.

Eine zentrale Frage ist aber noch unbeantwortet: unter welcher Open-Source-Lizenz Swift 2.0 im Laufe des Jahres veröffentlicht wird. Diese wird aber laut Apple von der OSI zugelassen sein und Abwandlungen erlauben, die selbst nicht zwingend veröffentlicht werden müssen. Das heißt, Konkurrenten werden den Open-Source-Stand nehmen und darauf basierend ihre eigenen Produkte bauen können. Ein Android SDK auf Swift Basis wäre doch mal eine interessante Sache!

Die Java-Sicht

Als Java-Entwickler kann man sich bei Swift auf einiges freuen. Die Syntax und somit die Lesbarkeit ist sehr angenehm, weitestgehend bekannt, und Java-gewöhnten Augen tut es gar nicht weh, Swift-Code zu lesen (ganz anders als bei Objective-C!) Schreiben ist sogar noch einfacher. Da Swift eine stark typisierte Sprache ist, kann man grundsätzlich genauso arbeiten wie mit Java. Den Typ bei der Variablendeklaration wie aus Java bekannt zu definieren, geht wie gewohnt von der Hand. Dadurch entfällt die Ausrede, dass man sehr darauf achten muss, was in die Variable gesteckt wird, wie bei schwach typisierten Sprachen wie beispielsweise JavaScript und PHP.

Andererseits, folgt man den Empfehlungen von Apple, geht das sogar noch besser durch sogenannte inferred data types. Die Empfehlung ist, soweit möglich, Variablen bei der Definition gleich zu initialisieren. Damit wird der Typ implizit definiert und die explizite Typdeklaration kann entfallen. Der Typ bleibt fest über die gesamte Laufzeit. Die IDE (aktuell ausschließlich Xcode) zeigt sogar im Editor an, welchen Typ die Variable bekommen hat. Weniger Code heißt auch bessere Lesbarkeit. Die ganze Sprache folgt diesem Stil. Sollte eine Stelle nicht eindeutig genug sein, was sicherlich eher subjektiv ist, kann der Entwickler auf explizite Typdeklaration ausweichen.

Eine weitere schöne Eigenschaft von Swift besteht darin, dass sich sowohl objektorientierte als auch funktionale Programmierstile sehr gut damit umsetzen lassen. Tatsächlich ist es so, dass auch Structs und Enums „First-Class Citizens“ der Sprache sind (Value-Types) und durch die standardmäßige Call-By-Value-Semantik gerade in Multi-Core- und Concurrency-affinen Szenarien ihre Stärken ausspielen können. Anders ausgedrückt: Es spielt sich deutlich mehr auf dem Stack ab, als auf dem Heap.

ARC vs. GC

Automatic Reference Counting (ARC) soll, kurz gesagt, die gleiche Aufgabe erledigen wie der Garbage Collector in Java, nur in Echtzeit und nicht als Batch-Operation irgendwann zu einer unbekannten Zeit. Das bedeutet, der Speicher wird sofort freigegeben, sobald keine „starken Referenzen“ mehr auf ein Objekt zeigen, was einem evtl. vorübergehend nicht ansprechbaren System optimal vorbeugt. Dies kann mit dem GC leicht passieren, wenn (unnötig) viele Objekte erzeugt werden. Dies ist vor allem auf mobilen Plattformen ein großes Thema, da dort Ressourcen bekanntlich sehr knapp sind.

Optionals

Optionals sind ein wesentlicher Bestandteil bei der Programmierung in Swift. Der Grund ist vor allem, dass sie so einfach zu handhaben sind. Die Definition eines Optional-Typs ist nur ein Fragezeichen zusätzlich zu dem normalen Typ entfernt. Damit zu arbeiten ist einfach – nur ein Fragezeichen dazu schreiben und schon wird ausgedrückt, dass eine Variable nil werden kann, oder eine Methode einen nil-Wert zurückgeben könnte. Mit Optional Chaining kann trotzdem die gewünschte Methode auf einem Optional aufgerufen werden, denn so, wie es in Objective-C möglich ist, nil eine „Message zu senden“ (Obj-C-Terminologie), liefert Swift in dem Fall einfach nur nil zurück, d.h. es fliegt auch keine NullPointerException o.Ä. Somit kann der Code sehr kompakt gehalten werden und es ist dennoch sichtbar, was möglicherweise passieren könnte. Der Entwickler wird also schon durch die Schreibweise an den möglichen Fehlerfall erinnert.

Swift Optionals sind also nicht direkt mit Optional in Java 8 zu vergleichen.

Tuples

Viele Entwickler haben sich bereits gewünscht, mehrere Rückgabewerte in einer Methode liefern zu können. Um es kurz zu halten: Das geht in Swift problemlos. Die Parameter bzw. Tupelindices können sogar benannt werden. Somit weiß der Aufrufer genau, was die Methode als Antwort liefert.

Binding

Optional Binding nennt man die Prüfung einer Optional-Variablen mit dem let-Schlüsselwort. In dem anschließenden Block ist dann diese Variable „ausgepackt“ und steht als nicht-Optional, also ganz gewöhnlich zur Verfügung. In diesem Bereich können wir uns ganz sicher sein, dass der Wert definitiv nicht nil ist.

Dies kann bei viel Code und vielen Variablen in einer Methode dazu führen, dass die Lesbarkeit leidet (viele if-lets geschachtelt, falls sie einzeln fehlerbehandelt werden müssen). Mit Swift 2.0 kommt hinzu, dass mit dem guard-Schlüsselwort Variablen einzeln geprüft und gebunden (!) werden können und die Fehlerbehandlung damit frühzeitig erfolgen kann. Das heißt, wir haben keinen großen eingerückten if-Block mehr, bei dem am Ende keiner mehr hinschaut – weil es nicht auf die Seite passt – ob die Fehlerbehandlung implementiert ist! So können also Variablen, bzw. Parameter im Voraus einzeln verifiziert werden, was wieder zu einem einfacher lesbarem Code führen soll.

Error Handling

Bis inkl. Swift 1.2 haben die wenigsten so etwas vermisst, mit Obj-C sind die Entwickler gewöhnt inout– Parameter zu verwenden, um mögliche Fehlerfälle zu identifizieren und zu behandeln. Dies geht mit Swift auch, wobei Optionals bisher einen Teil davon übernommen haben, allein weil die Schreibweise aber auch das Lesen vom Code auf diese Weise viel einfacher ist.

Die neue Fehlerbehandlung basiert auf der auch Java-Entwicklern bekannten try/catch-Methodik, es ist aber eigentlich ein do-try-catch. Programmzeilen innerhalb des do-Blocks, die überhaupt einen Fehler verursachen können, werden einzeln mit try annotiert.

Protocols

Protocols entsprechen grob gesprochen einem Interface in Java, sie sind aber mit Swift 2.0 sehr mächtig geworden. Ab jetzt können sie einerseits ihre eigenen (Default-)Implementierungen besitzen, quasi als Vorschlag für die implementierenden Klassen oder Structs (extend, vgl. implements in Java). Diese können dann aber trotzdem optional überschrieben werden, wenn der Entwickler dies zulassen will. Dies erlaubt ein sehr elegantes Design. Für Apple ist es ein zentrales Feature von Swift. So wurde auf der WWDC von einer „Protocol-orientierten Sprache“ bei Swift gesprochen, statt von einer „Object-orientierten“, oder „funktionalen“ Sprache.

Schlussgedanken

Es bleibt abzuwarten, ob die Open Source Swift-Sprache eine Zukunft vor sich hat. Das Potential ist jedenfalls da. Im schlimmsten Fall hat die Open Source Community eine gute Grundlage, um die eigenen modernen Sprachen zu ergänzen, sollten Teile davon gut ankommen. Selbst einem Fork dürfte nichts im Wege stehen. Wie gesagt… vielleicht schreiben wir in naher Zukunft auch unsere Android Apps in Swift – besser wär’s wahrscheinlich!?

Aufmacherbild: Barn Swallow von Shutterstock / Urheberrecht: Paul Reeves Photography

Verwandte Themen:

Geschrieben von
Wolfgang Frank
Wolfgang Frank
Wolfgang Frank ist Geschäftsführer der arconsis IT-Solutions GmbH aus Karlsruhe. Er beschäftigt sich seit mehreren Jahren hauptsächlich mit der Android- und iOS-Entwicklung. Als Agile Coach (CSM, CSP) und Softwarearchitekt für komplexe Enterprise-Systeme unterstützt er Kunden beim Bau von Mobile Gateways zur Anbindung von Unternehmens-Systemen an die mobile Welt.
Peter Vegh
Peter Vegh
Peter Vegh ist seit 2011 bei der arconsis IT-Solutions GmbH als Mobile-Developer und Trainer tätig. Er besitzt langjährige Erfahrung in der Entwicklung von Apps für Android. Mit der Veröffentlichung von Swift ist er auch intensiv in die iOS-Entwicklung eingestiegen.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Swift 2.0 wird Open Source: „Als Java-Entwickler kann man sich auf einiges freuen“"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
trackback

[…] Online-Artikel bereits verfügbar unter: https://jaxenter.de/swift-2-0-wird-open-source-22514 […]