Weil das vorhergehende Kapitel so kurz war, gibt es dieses Wochenende noch ein zweites.

In der nächsten Woche werde ich noch erklären, wie Sie Ihre Entwicklungsumgebung aufsetzen (und was das überhaupt ist), dann aber, in der übernächsten Woche beginnt das Kapitel 2 und es geht mit der Programmierung los. Freuen Sie sich darauf. Jetzt aber ersteinmal viel Spaß mit diesem Kapitel:

Kapitel 1: Einleitung / 1.2 Warum Sie Swift lernen sollten

Wenn Sie Programmieren lernen wollen, müssen Sie dafür eine Programmiersprache erlernen. Die Sprache ist die erste Stufe, die es zu erklimmen gilt. Und egal welche Sie wählen, jede Sprache hat ihre Vor- und Nachteile.

Wenn Sie dies hier lesen, dann haben Sie sich für Swift entschieden, aber Sie stehen auch noch am Anfang und können Ihre Entscheidung notfalls revidieren. Was also spricht für und was gegen Swift?

Swift ist eine moderne Sprache.

Und das ist nicht dahergesagt. Wie schon beschrieben, entwickeln sich Programmiersprachen mit der Zeit weiter und Swift enthält neben Altbewährtem auch moderne Konzepte, die man heutzutage in seiner Sprache einfach nicht missen möchte. Swift ist eine so gute Mischung aus alt und neu, dass allein dieser eine Punkt Swift schon zur Sprache der Wahl machen kann.

Swift ist im Kern objektorientiert. Das ist ein grundlegendes Programmierkonzept, bei dem Objekte erstellt und ineinander verschachtelt werden, um das Programm zu bilden. Der Objektorientierung ist in diesem Kurs ein eigenes Kapitel gewidmet.

Swift enthält funktionale Elemente. Insbesondere können Variablen neben Strings oder Zahlen auch Funktionen enthalten und man kann einer Funktion eine andere Funktion als Parameter übergeben.

Swift ist stark typisiert. Wenn eine Variable einmal vom Typ String ist, dann kann sie später nicht mehr vom Typ Zahl sein. Dies sorgt für eine höhere Stabilität des erstellten Codes. Außerdem ist es auch statisch typisiert, d.h. Die Variablen bekommen ihren Typ bereits zur Compilezeit, also während man noch programmiert, und nicht erst zur Laufzeit, also während das Programm bei Ihnen oder jemand anderem läuft. Entsprechend fällt ihr Programm nicht erst beim Kunden auseinander, wenn Sie einen Typisierungsfehler eingebaut haben, sondern bereits während sie noch daran programmieren, so dass Sie den Fehler leichter beheben können.

Swift enthält Konzepte wie Generics oder überladene Operatoren. Okay, überladene Operatoren sind ein alter Hut, aber da sie bei modernen Sprachen oft fehlen, ist das aus meiner Sicht ein Pluspunkt. Generics sorgen unter anderem dafür, dass Listen konkrete Typen bekommen, man also z.B. eine Liste von Strings erstellt, statt einer Liste, in die man alles mögliche hinein tun kann. Auch dies erhöht die Stabilität des Codes. Und überladene Operatoren bewirken, dass z.B. das Pluszeichen – ein Operator – nicht nur verwendet werden kann, um zwei Zahlen zu addieren, sondern auch, um zwei Strings aneinander zu kleben. Das dient der Bequemlichkeit.

Swift enthält bisher allerdings kaum Unterstützung für aspektorientierte Programmierung. Ein Minuspunkt aus meiner Sicht. Aspektorientiert programmiert man, wenn man, leger gesprochen, „quer durch alle Funktionen“ neue Eigenschaften „injizieren“ kann.

Aber Swift ist ja auch noch sehr jung. Und dass sich diese Sprache noch verändern und entwickeln wird, ist extrem wahrscheinlich. Wie alle anderen, lebendigen Programmiersprachen auch.

Swift ist auf Apple beschränkt.

Das ist so. Wenn man für Windows oder Android programmieren möchte, dann ist Swift nicht die geeignete Wahl.

Grundsätzlich gibt es plattformspezifische und plattformübergreifende Sprachen:

Plattformübergreifende Sprachen wie etwa Java haben den namensgebenden Vorteil, dass sie auf mehreren Plattformen laufen, aber auch den daraus resultierenden Nachteil, dass sie die Spezifika einer Plattform nicht nutzen können. Sie können nur das verwenden, was alle Plattformen gemeinsam haben und das, was die Sprache von sich aus mitbringt. Darum sind die Benutzeroberflächen von Java-Anwendungen oft so häßlich und funktionieren so anders als alles andere auf dem System.

Im Windows-Umfeld sieht man Java-Anwendungen darum nur gelegentlich und auf dem Mac praktisch gar nicht. Und unter iOS kann man Java-Apps gar nicht erst ausführen.

Java wird viel bei der Serverprogrammierung eingesetzt, denn dort kommt die Stabilität der Sprache zum tragen und Benutzeroberflächen werden in der Regel sowieso mit Webtechnologien umgesetzt.

Plattformspezifische Sprachen können hingegen in vollem Umfang auf die Spezifika einer Plattform zugreifen. Es entstehen native Applikationen, die sich innerhalb der Plattform anfühlen, als wäre alles aus einem Guss. Denn es ist ja alles aus einem Guss.

Die .NET-Familie, allen voran C# (englisch: Cee-Sharp) und Visual Basic, stellt die nativen Sprachen für Windows. Wenn man unter Windows programmiert, will man .NET programmieren.

Entsprechendes gilt für Java unter Android, C++ unter Linux und eben für Objective-C und Swift unter OS X und iOS.

Die Beschränkung auf Apple ist also kein Nachteil, sondern die Entscheidung für eine plattformspezifische Sprache.

Aber: Apple ist anders als andere. Im Positiven wie im Negativen. Hat Apple einen Einfall, dann muss man als Programmierer hinterher. Microsoft ist hier oft nicht so streng, was als Kehrseite dieser Medaille auch dazu führt, dass die Programmierschnittstellen unter Windows mit der Zeit extrem zumüllen, während Apple den Mut hat, auch mal dicke alte Zöpfe abzuschneiden.

Eine Apple-Eigenart ist allerdings unangenehm:

Wie bereits angesprochen, wird die API einer Sprache normalerweise in dieser Sprache verfasst. Und es ist gute Praxis, die Quelltexte dafür offen zu legen. Die Quelltexte von Java sind schon immer frei einsehbar gewesen und selbst Microsoft hat nach anfänglichem Zögern die Quellen von .NET zugänglich gemacht. Nur Apple hält sich bei Objective-C bis heute bedeckt und die Quellen unter Verschluss. Dementsprechend ist auch für Swift nichts anderes zu erwarten.

Für den Programmieranfänger ist das nicht so schlimm – wenngleich es schon interessant wäre, mal hinter die Kulissen zu schauen. Wenn man die Sprache aber produktiv nutzt, dann wäre es manchmal schon hilfreich, auch in den Quellcode von Apple hinein debuggen und auch dort Fehler suchen zu können.

Und, das ist auch wichtig: Für die Swift-Entwicklung benötigt man einen Mac. Hat man keinen Mac, dann kann man in Swift nicht sinnvoll entwickeln. Sicherlich auch ein Entscheidungskriterium für den einen oder die andere.

Swift ist eine junge Sprache.

Swift wurde auf dem Reißbrett entworfen, ohne alten Ballast. Darum ist Swift auch so modern und leichtgewichtig. Aber anders als bei einer alten Sprache weiß man noch nicht, ob es sich durchsetzen kann.

Nicht lange vor Swift zum Beispiel hat Google – die Firma hinter Android – die Sprache Go vorgestellt. Auch eine sehr gute Sprache (wenn auch mit einer, wie ich finde, gruseligen Syntax). Aber: Niemand den ich kenne verwendet Go. Die Sprache hat sich nicht durchgesetzt.

Unter Android kommt man hervorragend mit Java und C++ zurecht. Und Google tut nichts, um Go für Android zu empfehlen. Die Sprache kompiliert nicht mal problemlos für Android. Entwickelt wurde Go wohl ursprünglich als Google-internes Hilfsmittel für die Serverprogrammierung. Und weil Android vergleichsweise offen ist, herrscht bei den Sprachen mehr Konkurrenz. Java und C++ können die älteren Programmierer bereits, ihr bestehender Code ist darin geschrieben und die Sprachen sind vielleicht nicht sehr gut, aber gut genug.

Vieles davon ist bei Swift anders. Swift wurde von vornherein auf die Entwicklung für Mac und iOS zugeschnitten. Dem Programmieranfänger wurde bewusst viel syntaktischer Ballast aus dem Weg geräumt. Swift ist also eine vergleichsweise leicht zu lernende Sprache.

Außerdem herrscht auf Apple-Plattformen keine offene Konkurrenz. Mit Go kann man auf iOS gar nichts anfangen. Die einzige Alternative zu Swift ist (noch) Objective-C. Aber auch hier gilt: Die Programmierer können Objective-C bereits und ihr alter Code ist darin geschrieben.

Swift und Objective-C lassen sich jedoch innerhalb eines Projektes mischen. Bestehenden Objective-C Code kann man mit Swift erweitern und umgekehrt. Das erleichtert einen Umstieg ungemein. Nicht nur wegen der Verwendung alten Codes, sondern auch, weil mögliche Fehler im noch jungen Swift notfalls im gut abgehangenen Objective-C umschifft werden können.

Aber vor allem: Apple steht hinter Swift und wird mit viel Engagement diese Sprache auf Plattformen vorantreiben, die der Konzern – anders als Google mit Android – komplett unter Kontrolle hat.

Also ja, es kann sein, dass Sie mit Swift auf ein lahmes Pferd setzen. Aber es ist nicht wahrscheinlich. Microsofts Pläne bezüglich .NET erzeugen da weit mehr Unsicherheit. Und Apples Wille, die Sprache durchzusetzten, zusammen mit der offensichtlichen Qualität und der Einsteigerfreundlichkeit der Sprache, machen es sehr wahrscheinlich, dass sich Swift nicht nur kurzfristig gut angenommen, sondern sich auch langfristig durchsetzen wird.

Kapitel 1.2: Warum Sie Swift lernen sollten

2 Gedanken zu „Kapitel 1.2: Warum Sie Swift lernen sollten

  • 31. März 2015 um 15:55
    Permalink

    Als „Native Programmiersprache“ werden Sprachen bezeichnet, die direkt in Maschinencode kompilieren.

    http://www.lerneprogrammieren.com/blog/motivation/warum-mit-c-das-programmieren-lernen
    http://www.enzyklo.de/Begriff/Native%20Programmiersprache

    Die Sprachen der .NET Familie gehören definitiv nicht zu dieser Gruppe! Sie kompilieren in eine Zwischensprache (Intermediate Language) die erst bei der Ausführung von einem Just-In-Time-Compiler in Maschinencode umgesetzt werden. Dies hat zur Folge, das ein .NET Programm mit nur geringem Aufwand wieder in den Quellcode umgewandelt werden kann. Dieser ist dann auch leicht einzusehen!

    Verständlicherweise ist das nicht immer gewünscht aber es ist ein grundlegendes Verhalten von .NET Anwendungen und Bibliotheken. Die Aussage „Wenn man unter Windows programmiert, will man .NET programmieren.“ ist daher mit Vorsicht zu genießen.

    Antworten
    • 1. April 2015 um 16:02
      Permalink

      Hallo Holger, danke für deinen Hinweis.

      Was du schreibst ist soweit korrekt, als dass das Wort nativ im Zusammenhang mit Programmiersprachen traditionell so verwendet wird, wie du es schreibst: Um solche Spachen, deren Kompilate auf dem Prozessor laufen (etwa C++ oder Swift) von solchen abzugrenzen, deren Kompilate auf einer Virtuellen Maschine ablaufen (wie .NET oder Java).

      Eine andere, neuere Verwendung des Wortes nativ bezieht sich allerdings darauf, ob eine Programmiersprache auf einem System natürlich beheimatet ist, so dass sich damit erstellte Applikationen für den Anwender angenehm in das Betriebssystem einpassen. In diesem Sinne ist .NET auf Windows Plattformen zu Hause, genauso wie Java auf Android, obwohl beides auf virtuellen Prozessoren läuft.

      Im Programmierumfeld existieren heute beide Bedeutungen von nativ nebeneinander. Ich habe meinen Text daraufhin noch einmal gelesen und finde, dass die von mir beabsichtigte Bedeutung aus dem Kontext recht gut hervorgeht.

      Nichts desto trotz ist es gut, dass dein Kommentar auf diese doppelte Bedeutung hinweist, um so Missverständnissen vorzubeugen. Und die von mir gemachte generelle Aussage „man will unter Windows .NET programmieren“ ist natürlich nur solange gültig, wie man keine speziellen Anforderungen an die Sprache oder die Applikation hat, die dann ggf. eine andere Sprache zur besseren Wahl werden lassen.

      Gruß, Markus.

      Antworten

Schreibe einen Kommentar

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