Apple-Sprache Swift: Entwickler haben noch viele Fragen

Es scheint etwa keinen Schutz vor Speicherkorruption durch Multithreading zu geben. Einige Programmierer überlegen, ob sie für Scripting nun JavaScript, AppleScript oder Swift verwenden sollen. Positiv wird die große Menge an Beispielcode auf GitHub vermerkt.

Unter Mac-Entwicklern sind erste Diskussionen zur letzte Woche vorgestellten neuen Apple-Programmiersprache Swift entbrannt. Viele Programmierer sehen noch eine Reihe offener Fragen, beispielsweise im Hinblick auf das Multithreading und die Integration von JavaScript.

Swift-LogoApple hatte die Sprache auf seiner Entwicklerkonferenz WWDC vorgestellt und – was ungewöhnlich ist – sämtliche Videopräsentationen öffentlich zugänglich gemacht. In früheren Jahren hatte es nur registrierten Entwicklern die Möglichkeit gegeben, sich die Videos anzusehen – beispielsweise die „Introduction to Swift“ von Tim Isted und Dave Addey. Daneben steht eine Swift-Einführung in Apples iBook Store zum kostenlosen Download bereit.

Swift soll Objective C und Python als native Sprachen für Cocoa und Cocoa Touch ersetzen. Swift-Code kann neben vorhandenem Objective-C-Code ausgeführt werden. Apple verspricht zudem mehr Sicherheit durch das Ausschließen bestimmter Fehlerklassen.

Schon jetzt zeichnet sich ab, dass die meisten Entwickler erst ab ihrem nächsten Projekt – also in einem Jahr oder später – Swift nutzen wollen. So betont Programmierer und Buchautor Marco Arment in einem Blogbeitrag, er werde eine Weile brauchen, um die neuen Standards und Erwartungen zu verinnerlichen.

Über die Sicherheit und das Multithreading macht sich Michael Fortin Gedanken: „Apple sagt, es sei auf Sicherheit ausgerichtet. Es ist wichtig, darauf hinzuweisen, dass Swift nicht etwa Speicherkorruption verhindert, wie sie aus Multithreading-Code resultieren kann. Ich finde es bezeichnend, dass Threads und Gleichzeitigkeit in der Sprachdokumentation nicht einmal erwähnt werden. Vielleicht verbietet Apple einfach Threads, aber das wäre schon eine Überraschung.“

Von dieser Multithreading-Lücke abgesehen scheint die Sprache aber Speicherkorruption zu verhindern. Es gibt keine Möglichkeit, die Sicherheitsvorkehrungen zeitweise zu umgehen, wie es etwa in Rust durch Unsafe Blocks möglich ist. Wer unsicheren Code nutzen will, muss ihn in C oder Objective-C schreiben.

Auf Clark’s Tech Blog finden sich gleich mehrere lange Artikel von Clark Goble zum Thema Swift. Unter anderem weist er darauf hin, dass auf GitHub bereits eine erstaunlich große Menge Swift-Code zu finden sei. Er schreibt auch: „Für mich ist das viel einfacher zu lesen. Ich weiß, das einige Objective-C-Verfechter sagen, es sei zu verknappt, um lesbar zu sein. Das trifft auf mich nicht zu. Vielmehr ist es einer meiner Kritikpunkte, dass immer noch so viele Namenskonventionen von Cocoa verbleiben, sodass es zu ausführlich ist. Ich finde nicht, dass Cocoa die Regel gut umsetzt, dass wichtige Methoden und Klassen kurze Namen haben sollten.“

Interessant zu lesen ist auch, wie der als Dr. Drang bekannte Programmierer die Gleichbehandlung von JavaScript und AppleScript als Applikationsskriptsprache für OS X Yosemite kommentiert: „Ich bin kein großer Fan von JavaScript, aber es ist sicher verbreiteter als AppleScript. Ich habe mich zum Erlernen von AppleScript gezwungen, weil es die einzige Möglichkeit war, das heißt jedoch nicht, dass ich es mag. – Der Teufel dürfte jedenfalls im Detail stecken. Das größte Problem von AppleScript waren immer die Anwendungen, die es implementieren. Jede App kann entscheiden, welche Funktionen sie exponiert und wie sie heißen. Das hat dazu geführt, dass ähnliche Konzepte bei unterschiedlichen Apps unterschiedliche Namen tragen. Ich bezweifle, dass JavaScript dieses Problem lösen wird.“

Auch Clark beschäftigt sich in seinem Blog mit der Frage, ob er sich nach der Einführung von Swift mit JavaScript for Automation beschäftigen soll. „Ich habe Scripting mit Swift noch nicht richtig ausprobiert. Schön ist, dass REPL und Playgrounds beim Scripting viele Freiheiten lassen. Da Apples JavaScript offenbar eine eigene Scripting Bridge nutzt, sieht es so aus, als ob man damit keine großen Vorteile gegenüber Swift bekommt. Ich habe JavaScript for Automation noch nicht ausprobiert. Darüber hinaus ist Beta 1 von Yosemite noch so grob, dass ich sie nicht richtig brauchbar fand.“

[mit Material von David Morgenstern, ZDNet.com]

Tipp: Wie gut kennen Sie Windows? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de.

Themenseiten: Anwendungsentwicklung, Apple, Mac OS X, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Apple-Sprache Swift: Entwickler haben noch viele Fragen

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *