Swift programming language



  • Mechanics! Wenn NEXT Computer (also Steve Jobs) damals nicht Obj-C eingesetzt hätte, würde es Obj-C heute vermutlich nicht mehr geben. Da Mac OS X aus NextStep entstanden ist, haben die sich das ans Bein gebunden. Keiner sonst wollte es damals benutzen, und keiner benutzt es heute freiwillig.

    Und weißt du was? Selbst Apple will es nicht benutzen, sonst hätten sie nicht Swift raus gebracht. Das sagt schon viel aus.

    Wahrscheinlich war Steve Jobs der einzige Mensch auf diesem Planeten, der es toll fand. Und wo er jetzt nicht mehr in Cupertino das Sagen hat (RIP), haben die Apple-Mitarbeiter ihre Chance wahr genommen, und Swift entwickelt.



  • kkaw schrieb:

    Wie das mit den Generics jetzt genau übersetzt wird, weiß ich nicht. Ist damit "zero-cost abstraction" möglich? Also: Läuft das zwangsweise über Laufzeitpolymorhie mit Boxing von Structs für Protocols (so wie für structs in C# bei interfaces) oder gibt's da "echte Compilezeit-Polymorphie", wo spezielle Funktionen zur Compilezeit generiert werden, wobei der Compiler dann Typparameter-abhängige Funktionen direkt aufrufen/inlinen kann?

    So wie ich das verstanden habe, läuft des wie bei Templates oder wie in Haskell. Die Funktion wird beim Compilen für den entsprechenden Typ instanziiert und hat dann entsprechen volle Geschwindigkeit bei gleichzeitiger Vermeidung vieler Laufzeitfehler.

    Insgesamt finde ich, dass Swift vieles richtig macht und auch vieles einbaut, was für neue Programmiersprachen zwingend erforderlich ist (funktionale Elemente, Type inference) und sich gleichzeitig nicht wie Java von Alles-muss-OOP-und-Vererbung-sein leiten lässt. Boilerplate-code ist minimal und trotzdem wird durch statische Instanziierung Typsicherheit und Geschwindigkeit von nativen Sprachen erreicht.
    Aber diese String interpolation ist ein absolutes No-go für mich. Ich hasse es wenn Daten hier (Strings) und Code vermischt werden. Das ist ja fast so schlimm wie die variablen Variablennamen in PHP.
    Außerdem sehe ich die Unicode-Unterstützung sehr skeptisch. Wenn Leute ihre Funktionen nicht in englisch benennen, ist das schon unangenehm genug, aber wenn sie dann auch noch Zeichen verwenden, die man nicht einmal darstellen kann, hört der Spaß wirklich auf. Und auch wenn es im Manual toll aussieht, pi mit einen Unicode-Simbol als griechischen Buchstaben darzustellen, ist das in der Praxis extrem unbrauchbar.
    Es sieht mir auch alles ein bisschen zu Skriptsprachenmäßig aus. Es gibt Features wie Arrays und Strings, die sehr einfach zu benutzen und in ihrer Funktionalität total überladen sind. Das sieht am Anfang toll aus, weil man damit sehr viel sehr einfach ausdrücken kann, aber sobald man an die Grenzen der Standard-funktionen stößt, ist eine allgemeine Programmiersprache wesentlich mächtiger und kann den Algorithmus eleganter und kürzer beschreiben, als man es in einer Skripsprache je könnte.



  • Marthog schrieb:

    Das sieht am Anfang toll aus, weil man damit sehr viel sehr einfach ausdrücken kann, aber sobald man an die Grenzen der Standard-funktionen stößt, ist eine allgemeine Programmiersprache wesentlich mächtiger und kann den Algorithmus eleganter und kürzer beschreiben, als man es in einer Skripsprache je könnte.

    Was fehlt Swift?



  • Ich finde die Reaktionen hier im Forum völlig irrational.

    "Ungewohnte Syntax" => "Sieht aus wie eine Skriptsprache" => "Unmöglich, darin grössere Projekte durchzuführen".

    Außerdem sehe ich die Unicode-Unterstützung sehr skeptisch.

    Die meisten modernen Sprachen haben Unicode-Unterstützung, für C++ ist es unvermeidlich am kommen (clang unterstützt das). Nur dass es unterstützt wird, heisst ja nicht, dass man es benutzen soll. Aber ASCII-only ist einfach nicht mehr zeitgemäss.

    Aber diese String interpolation ist ein absolutes No-go für mich. Ich hasse es wenn Daten hier (Strings) und Code vermischt werden. Das ist ja fast so schlimm wie die variablen Variablennamen in PHP.

    Niemand sagt, dass du gezwungen bist, das überall einzusetzen. Ich finde das viel eleganter wie die iostreams.

    println("position of \(name)= (\(x)|\(y)|\(z))")
    

    vs

    clog << "position of " << name << "= (" << x << "|" << y << "|" << z << ")\n";
    

    Dass das nicht geeignet ist um lokalisierte Beschriftungen dem Nutzer anzuzeigen, sollte wohl klar sein.

    Es gibt Features wie Arrays und Strings, die sehr einfach zu benutzen und in ihrer Funktionalität total überladen sind. Das sieht am Anfang toll aus, weil man damit sehr viel sehr einfach ausdrücken kann, aber sobald man an die Grenzen der Standard-funktionen stößt, ist eine allgemeine Programmiersprache wesentlich mächtiger und kann den Algorithmus eleganter und kürzer beschreiben, als man es in einer Skripsprache je könnte.

    Wieso ist Swift keine allgemein Programmiersprache? Die Arrays in C++ sind völlig fehlplaziert, viel zu leicht zugänglich für Anfänger, aber unsicher und deshalb verpönt in der Nutzung.

    Ich finde den Ansatz super, den Common Case möglichst angenehm machen. Heisst ja nicht, dass es verboten wäre, in Spezialfällen auf die knappe Syntax verzichten zu müssen.



  • Marthog schrieb:

    Aber diese String interpolation ist ein absolutes No-go für mich. Ich hasse es wenn Daten hier (Strings) und Code vermischt werden.

    Komisch 🙂
    Ich finde das gerade unglaublich praktisch.
    Ich weiss nicht wie es in Swift umgesetzt wurde, aber wenn man es ordentlich macht, ist es toll. Und ordentlich heisst für mich dass ich ne Fehlermeldung bekomme wenn der Variablenname nicht existiert, oder der Typ nicht zu den angegebenen Formatierungsoptionen passt.

    Schreibst du echt lieber (Syntax erfunden)

    print("Error opening '" + filename + "': " + ex.ToString());
    

    als

    print("Error opening '{filename}': {ex}");
    

    ?

    String-Interpolation ist für mich nur die konsequente und sinnvolle Weiterführung von Format-Strings. Und hat gegenüber diesen den grossen Vorteil dass man nicht so leicht fehler bei der Reihenfolge oder Anzahl der Parameter machen kann. Ich finde es z.B. furchtbar dass C# mir weder einen Fehler noch eine Warning schmeisst wenn ich

    Console.WriteLine("Blah {0} {0}", foo, bar);
    // oder 
    Console.WriteLine("Blah {0} {1}", foo);
    

    schreibe. Was für mich letztlich der Grund war warum ich auf das Zusammenhängen von Strings mittels "+" umgestiegen bin. Was dann aber leider wieder viel unübersichtlicher zu lesen ist.


Anmelden zum Antworten