Über die Schwalbe, die den Wurm aus dem Apfel picken soll

Swift und seine Bedeutung für die Microsoft-Entwicklerwelt
Kommentare

Viele hatten auf Apples World Wide Developer Conference (WWDC) im Juni 2014 eine Sensation erwartet. Und viele waren enttäuscht, dort keine klassische zum Beispiel in Form von neuer Hardware zu Gesicht bekommen zu haben. Nur: Zum einen hatte es auf der WWDC noch nie neue spektakuläre Hardware gegeben und zum anderen gab es durchaus eine Sensation – eine neue Programmiersprache namens Swift (auf Deutsch etwa: Mauersegler, Turmschwalbe). Was ist Swift, und hat es eine Bedeutung für die Microsoft-Entwicklerwelt?

Visual Basic 6 hat nicht unerheblich zum Erfolg von Windows beigetragen. Beeindruckend an der Programmiersprache ist bis heute, wie einfach und schnell sich mit ihr Problemstellungen in Form von Win32-Anwendungen lösen lassen. Dabei war die Tatsache, dass sich in Visual Basic im Vergleich zu beispielsweise C/C++ nur ein Bruchteil der Möglichkeiten für Win32-Anwendungen umsetzen ließen, kein Nachteil, sondern eher Teil des Erfolgsgeheimnisses. Kein Threading, keine Pointer-Operationen, keine richtige Vererbung und keine Typsicherheit. Was übrig blieb, ließ sich allerdings konkurrenzlos schnell umsetzen und somit gilt bis heute der Grundsatz: Kannst du es nicht in zehn Minuten mit VB6 machen, kannst du es gar nicht mit VB6 machen. Für die meisten der Anforderungen zwischen 1998 und 2005 war VB aber ausreichend und so entstand binnen kürzester Zeit eine unglaubliche Fülle an unterschiedlichsten Nischenanwendungen – das waren zwar nicht immer die besten, ergonomischsten oder stabilsten, in jedem Fall aber mal die preisgünstigsten, und die, für die man in atemberaubendem Tempo neue Benutzerwünsche umsetzen konnte.

Mit .NET war das vorbei. .NET brachte mit C# und VB.NET zwei leistungsfähige Programmiersprachen, die Visual Basic 6 weit überlegen waren. Aber: Die Ein- oder Umgewöhnungszeit war auch dementsprechend größer. Unter .NET ließen sich sehr robuste Anwendungen mit einem viel weiter entwickelten Funktionssatz schaffen, aber das brauchte auch sehr viel mehr Geduld. Die Zeit, zu der native Windows-Anwendungen wie die Pilze aus dem Boden schossen, war somit ab dem Jahr 2003 erst einmal vorbei. Und seien wir ehrlich: Windows zehrt noch heute vom Erfolg von einst, denn es ist zu befürchten: Wenn in den Jahren vor Windows 7 und 8 nicht so viele komplexe Nichtwebanwendungen in den „simplen“ Sprachen wie Visual Basic 6 oder auch Delphi entstanden wären, gäbe es heute weitaus weniger Gründe, gerade im Businessumfeld und in den mittelständischen Betrieben, Windows nach wie vor einzusetzen. Man kann sich nicht des Eindrucks erwehren, dass einige Marketingmenschen bei Microsoft erst sehr langsam begriffen haben, dass der Erfolg von Windows bis zur Version 7 nicht auf ihrem Können beruhte, sondern auf der Tatsache, dass es zu Windows schlicht und ergreifend zu seiner Zeit keine Konkurrenz gab. Doch kurz nach der Einführung von Windows 7 debütierte auch das iPad und trat seinen unaufhaltsamen Erfolg an.

Und so ist die Situation heute anders: Viele Aufgaben, für die es vor zehn Jahren zweifelsohne zu einem PC mit Windows keine Alternative gegeben hätte, erledigt man heute genauso gut mit einem iPad oder einem Android-Tablet.

Was man auf diesen Tablets jedoch auch heute noch selten antrifft, sind komplexere und spezielle Businessnischenanwendungen, wie es sie in der Windows-Welt immer noch zu Tausenden gibt. Nicht dass Mittelständler ihre Anwendungen nicht gerne auf einem iPad sehen würden, in Wahrheit ist wohl eher das Gegenteil der Fall. Nein, bislang war es eher so, dass komplexere Anwendungen für das iPad, das iPhone oder auch den Mac zu entwickeln wegen des Fehlens einer halbwegs guten Entwicklungsumgebung einen Aufwand bedeutet hätte, den kein Mittelständler bereit gewesen wäre zu bezahlen. Bis jetzt.

Swift: die Alternative zu Objective-C

Denn während man bislang in der Apple-Welt nur auf das an unnötiger Umständlichkeit nicht zu übertreffende Objective-C zur nativen Entwicklung zurückgreifen konnte, gibt es nun die Alternative namens Swift. Und mit dieser wirklich leicht zu erlernenden (im Gegensatz zu Objective-C) und dennoch typsicheren (im Gegensatz zu JavaScript) Programmiersprache lassen sich iOS- bzw. Mac-OS-Anwendungen in einem Bruchteil der sonst üblichen Zeit erstellen. Swift bedient sich dabei vom Besten aus allen Welten:

  • Wie in Visual Basic und Visual Basic 6 kennt Swift pro Zeile eine Anweisung, was es unnötig macht, eine Zeile mit einem Semikolon abzuschließen. Man kann zwar wie in VB mehrere Anweisungen in einer Zeile unterbringen, aber das erfordert dann ein Trennzeichen. In VB ist das der Doppelpunkt, in Swift das Semikolon.
  • Wie Visual Basic .NET und C# arbeitet Swift typsicher. Dabei bedient es sich intensiv der Type Inference oder – auf Deutsch – dem Typrückschluss: Eine Variable wird wie in C# mit var definiert. Anders als in Visual Basic und C# gibt es in Swift aber nicht nur den lokalen Typrückschluss; Typrückschluss funktioniert vielmehr auch im Klassen-Scope.
  • Klassen gibt es in Swift natürlich auch, und zwar mit allem Shabang, teilweise sogar noch ein bisschen ausgefuchster als in den .NET-Sprachen. Vererben, abstrakte Klassen, Overrides und Polymorphie sind wie in VB.NET, Java und C# obligatorisch. Aber: Anders als in .NET lassen sich beispielsweise mit Extension-Funktionalitäten nicht nur Methoden, sondern auch Properties ergänzen, und selbst Interfaces, die sich in Swift „Protocols“ nennen, können mit Methoden bereits vorhandener Klassen verdrahtet werden.
  • Wie in Visual Basic 6, und damit anders als in Visual Basic .NET und C#, gibt es in Swift jedoch keine Speicherverwaltung durch einen Garbage Collector. Hier verrichtet eine Speicherverwaltung basierend auf Reference Countern seinen Dienst. Damit das nicht zu den gleichen Katastrophen wie einst in Visual Basic 6 führt, muss der Entwickler ein wenig mitdenken und kann durch den gezielten Einsatz von Weak References Speicher-Leaks aufgrund von zirkulären Referenzen vermeiden.
  • Strukturen werden wie in JavaScript und C# mit geschweiften Klammern definiert. Allerdings weicht Swift beispielsweise bei der Verwendung boolescher Ausdrücke bei If ab, hier sind wie in Visual Basic keine Klammern erforderlich.
  • Swift kennt Funktionen und Closures und Letztere entsprechen den Lambdas in Visual Basic und C#.
  • Attribute kennt Swift ebenfalls. Sie werden mit einem @-Zeichen eingeleitet und stehen, wie auch in VB und CSharp, vor dem eigentlichen Sprachelement.
  • Swift kennt, wie Visual Basic 6 und Visual Basic .NET auch, einen Background-Compiler, der syntaktische Fehler oder fehlende Deklarationen unmittelbar nach einer Veränderung am Sourcecode anzeigt. Ja, auch C# kann das, aber eben nicht so reaktionsschnell und so endgültig, und auch hier scheint Visual Basic Pate gestanden zu haben.

Der in Abbildung 1 zu sehende Code demonstriert, wie einfach in Swift ein kleine Trinkgeld-Rechner-App für das iPad oder das iPhone implementiert werden kann. Dabei ist das Schreiben des Codes in der Tat eine Angelegenheit von ein paar Minuten, wenn man sich erst einmal mit ein paar Besonderheiten vertraut gemacht hat.

Abb. 1: In Swift geschriebene App für iPad und iPhone

Umso erstaunlicher ist die Tatsache, dass es nicht lange nach der Vorstellung von Swift bereits erste Kritik daran hagelte, dass Apple eine neue proprietäre Programmiersprache geschaffen hat und keinen bereits etablierten Industriestandard wie Java oder C# verwendet. Aber war das nicht zu erwarten? Ich meine: Ein iPhone verfügt über keinen USB-Stecker, sondern über einen Lightning Connector, und natürlich tut Apple gut daran, seine eigenen Standards zu definieren. Auf Apple passen inzwischen die Witze, die wir uns Ende der Neunzigerjahre über Bill Gates erzählt haben, nur mit vertauschten Rollen. Wie wechselt Tim Cook eine Glühbirne? Antwort: Gar nicht, er erklärt die Dunkelheit zum Standard. Die Tatsache ist: Apple hat es mit über 200 Millionen verkauften iPads und über 500 Millionen iPhones im Markt überhaupt nicht nötig, sich vorhandener Standards zu bedienen – und genau das ist die große Gefahr, die von Apples neuer Programmiersprache ausgeht, denn eines ist klar: Bei aller Popularität der Apple-Produkte, ganz gleich ob Hardware oder Software, gab es bislang nur ein wirklich schwarzes Scharf im Apple-Stall und das war die Entwicklersprache Objective-C. Sie war alt, schwerfällig, mühsam zu erlernen und noch mühsamer einzusetzen. Mit Swift hingegen können jetzt auch die weniger versierten Entwickler, ja selbst Poweruser in kürzerer Zeit Anwendungen entwickeln – und damit ist der Erfolg von Swift buchstäblich vorprogrammiert. Wenn bislang mit dem „kaputten“ Objective-C bereits eine dermaßen große Fülle an guten Apps und Anwendungen entstanden ist – was für Anwendungen werden dann erst mit Swift entstehen? Und wenn diese Programmiersprache dann wie der Lightning-Adapter auch noch proprietär sind, sind nicht nur Anwender, sondern auch Entwickler viel endgültiger an die Plattform gebunden, und sie werden weiterhin exklusiv für diese Plattform entwickeln. Für Xamarin und seine Cross-Plattform-Entwicklungsumgebung stellt Swift in meinen Augen eine ernstzunehmende, wenn nicht sogar gefährliche Konkurrenz dar, denn durch die Schwerfälligkeit von Objective-C war Microsofts .NET-Technologie in Form von Xamarins Mono-Plattform auch für Nur-Apple-Entwickler bislang recht attraktiv. Jetzt muss man leider sagen: Durch Swift fällt ein großes Entscheidungskriterium pro Xamarin einfach weg. Swift ist quasi umsonst zu haben und noch leichter zu erlernen als C#. Es ist quasi das Visual Basic 6 des aktuellen Jahrzehnts, und deshalb ist zu erwarten, dass die ohnehin schon starke Plattform mit seiner Hilfe noch mehr gestärkt wird.

Für uns Windows- und .NET-Entwickler kann das allerdings nicht nur negative Auswirkungen haben, denn wenn Microsoft es schafft, auch Apple-Entwickler mit der Cloud-Infrastruktur Azure als Backend-Alternative zu begeistern, bedeutet ein Zuwachs von Apple-Apps auch einen sehr viel größeren Bedarf an Cloud-Anwendungen im Backend. Und hier hat Microsoft im Gegensatz zu Apple sowohl beim Tooling als auch beim Ausbau der Infrastruktur eindeutig die Nase vorn.

Dazu kommt, dass Swift für die Cross-Plattform-Entwicklung keine Alternative darstellt. Es ist eben Apple-proprietär. Für Softwareentwickler, deren Apps sowohl unter Android als auch unter Windows und der Apple-Plattform laufen sollen, ist Xamarin nach wie vor konkurrenzlos.

Für mich als Visual Basic MVP ist bei der ganzen Sache eines sehr erstaunlich: Nämlich nicht nur, dass Visual Basic (6) in vielerlei Hinsicht bei Swift Pate gestanden hat, sondern dass gerade die Visual-Basic-Eigenschaften, die beim typischen C#-Entwickler als unprofessionell gelten, bei Swift als herausragende Features für Rapid Application Development angepriesen werden und Apple vermutlich auch großen Erfolg damit haben wird. Microsoft sollte sich deswegen vielleicht als Antwort auf Swift überlegen, ein Pferd ins Rennen zu schicken, das bereits durchaus konkurrenzfähig im Stall steht, und eigentlich nur darauf wartet, loszurennen. Dazu würde allerdings noch ein wenig Drumherum gehören, nämlich beispielsweise eine überarbeitete, an andere Plattformen angepasste IDE, mit der auch Apple- und Android-Entwickler zufrieden wären, und die nicht nur ausschließlich unter Windows liefe. Auch eine Komponentensammlung, deren Erstellung Microsoft nicht nur Drittherstellern überließe. Und eine Sammlung von Assistenten, die dem Entwickler wiederkehrende Doings abnehmen würden, sowie ein überarbeiteter Snippets-Katalog und neue APIs, die es auf einfache Art erlaubten, MongoDB (NoSQL), SQLite oder vereinheitlichende OpenGL/DirectX-Entwicklung zu betreiben. Dann, ja dann könnte man sich vorstellen, wäre eine Programmiersprache bereit, es mit den Swift-Powerusern aufzunehmen. Visual Basic hat es in den Neunzigern ja schon einmal vorgemacht. Heute wäre es mit den richtigen Rahmenbedingungen ausreichend leistungsfähig und ausreichend einfach, das Rennen nochmal zu machen.

Aufmacherbild: Swift flying over head (Common Swift / Apus apus) von Shutterstock / Urheberrecht: Sokolov Alexey

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -