Swift programming language



  • Tyrdal schrieb:

    scrontch schrieb:

    Warum muss jeder Hersteller immer seine eigene Sprache entwickeln? 🙄

    Vendor-Lockin?

    Die Idee kam mir auch. Speziell bei Apple. Ist ja nicht die erste becknackte Sprache die ausserhalb der Apple-Welt kein Mensch verwendet.
    Vielleicht war es mit Objective-C++ zu einfach so zu programmieren dass man den Code dann schnell auf andere Systeme portieren kann?



  • kkaw schrieb:

    bitte mal versuchen, mit einer "unowned"-Referenz einen baumelnden Zeiger zu bauen. Würde mich interessieren, ob so ein Versuch vom Typsystem bzw Compiler abgefangen werden kann. Das scheint mir nämlich die unsichere Variakte einer Weak-Referenz zu sein.

    ...

    Apple schrieb:

    Note also that Swift guarantees your app will crash if you try to access an unowned reference after the instance it references is deallocated. You will never encounter unexpected behavior in this situation. Your app will always crash reliably, although you should, of course, prevent it from doing so.

    Finde ich total ausreichend.
    Und impliziert natürlich auch dass die Sprache solche Fälle nicht grundsätzlich unmöglich machen kann.



  • Der grösste Fehler von Apple ist, die Sprache nicht zu opensourcen.



  • bsd schrieb:

    Der grösste Fehler von Apple ist, die Sprache nicht zu opensourcen.

    Was genau soll das bei Sprachen bedeuten? Meinst Du eine OSS-Veroeffentlichung der Referenzimplementierung des Compilers oder der Standardbibliothek? Ich meine, auch im C++ Umfeld ist nicht jeder Compiler Open Source. Die Sprachspezifikation wird sicherlich oeffentlich erhaeltlich sein.



  • hustbaer schrieb:

    Apple schrieb:

    Note also that Swift guarantees your app will crash if you try to access an unowned reference after the instance it references is deallocated. You will never encounter unexpected behavior in this situation. Your app will always crash reliably, although you should, of course, prevent it from doing so.

    Finde ich total ausreichend.
    Und impliziert natürlich auch dass die Sprache solche Fälle nicht grundsätzlich unmöglich machen kann.

    Ah, das hatte ich übersehen. Danke für das Zitat. Jetzt frag ich mich aber, wie sie dieses Verhalten garantieren wollen und was das für einen Overhead bedeutet. Der Overhead müsste ja kleiner als bei einer Weak-Referenz sein; denn sonst verstehe ich den Sinn von unowned-Referenzen nicht. Aber warum sollte man die jetzt verwenden, wo es doch schon Weak-Referenzen gibt? Der Unterschied bzgl Laufzeitkosten dürfte doch nur ein Tropfen auf 'nem heißen Stein sein. Vielleicht sind's ja untenrum doch nur Weak-Referenzen und der Unterschied ist nur ein semantischer. Man muss die unowned-Dinger ja auch nicht mehr auf nil testen.

    Hmmm ... also rein vom Sprachdesign her, find' ich Rust doch interessanter.



  • Ich bin sehr erstaunt über den Zeitpunkt, an welchem Swift vorgestellt wurde. Objective-C verzeichnet über die grössten Zuwachsraten überhaupt, Performance ist kein Problem, da jeder erfahrene Programmierer damit weiss, wann er in C und wann in Objective-C programmieren muss. Das Thema Memory-Management wurde brauchbar gelöst und es existiert eine riesige, gut dokumentierte Code Base.

    Swift passt hier irgendwie nicht rein. Ich habe die ersten 200 Seiten aus dem veröffentlichten iBook gelesen gestern und ich muss sagen, Swift sieht eher aus wie eine Skriptsprache und nicht wie eine Sprache von strategischer Bedeutung (wie eben etwa Java oder Objective-C). Ich weiss auch nicht, ob die Samples extra komisch gewählt wurden, aber wenn ich Sachen sehe wie hier:

    The Swift Programming Language. schrieb:

    if let name = optionalName {
        greeting = "Hello, \(name)"
    }
    

    Ich finde das nicht wirklich schön. Die Grenzen zwischen Sprache und Library/Framework sind verwischt, was ich persönlich für gefährlich halte wenn man eine neue Sprache designed, welche das gesamte Spektrum abdecken soll. Aber ja, ich werde mir Xcode 6 mal installieren und das alles in Ruhe anschauen, vielleicht ist es ja nicht so schlimm...



  • Ich persönlich finde es gut, dass man so langsam weg von Programmiersprachen kommt, die 1. fehleranfällig 2. Boilerplate-Code erzeugen 3. Sehr gute Konzepte/Errungenschaften, die Jahrzehnte alt sind, teils komplett ignorieren (damit meine ich die aus der funktionalen Programmierung).

    Ne, ich bin kein Fan von C, C++, Java etc.
    Scala, rust, Swift etc., die die Stärken aus der OO- und der funktionalen Welt verbinden, sprechen mich deutlich mehr an.
    Klar, Java 8 bietet nun auch lambda-Ausdrücke, C++11 auch, aber Konzepte, die man im Nachhinein einbaut, wirken halbgar als wenn sie von Anfang an so konzeptioniert sind. Außerdem ist der Punkt "Sicherheit" noch gar nicht damit abgedeckt. Der Punkt Boilerplate-Code auch nur bedingt.

    Grub,
    IBV



  • /rant/ schrieb:

    Swift sieht eher aus wie eine Skriptsprache und nicht wie eine Sprache von strategischer Bedeutung (wie eben etwa Java oder Objective-C).

    Ich weiss nicht, was dich daran stört, wenn es nach Skriptsprache ausschaut, aber Swift wird auf jeden Fall statisch kompiliert, also direkte Nachteile hat das nicht.

    Ich weiss auch nicht, ob die Samples extra komisch gewählt wurden, aber wenn ich Sachen sehe wie hier:
    [quote="The Swift Programming Language."]

    if let name = optionalName {
        greeting = "Hello, \(name)"
    }
    

    Ich finde das nicht wirklich schön. Die Grenzen zwischen Sprache und Library/Framework sind verwischt, was ich persönlich für gefährlich halte wenn man eine neue Sprache designed, welche das gesamte Spektrum abdecken soll.

    Das erste Feature gibt es auch in C++:

    if (std::ifstream in{"file.txt"})
      // in has been sucessfully opened
    

    Das zweite Feature finde ich persönlich wirlich nützlich. Dieses Feature hat sich in Python bereits bewährt und in C++ vermisse ich es andauernd. Mit den iostreams etwas auszugeben ist obermühsam und sehr bloated.



  • https://github.com/trending?l=swift

    Gibt immerhin schon ein paar GitHub-Projekte in Swift wo man sich das Ganze mal ansehen kann. Fehlt nur scheinbar noch Syntax Highlightning dazu.

    Was ich persönlich an Swift mag ist die Tatsache, dass die Syntax nicht mehr an Smalltalk orientiert ist. Keine Ahnung, Objective C sieht einfach komisch aus - wenn man mehr damit arbeitet, siehts sicher "besser für einen aus", aber als "hin und wieder Beschäftigung" siehts komisch aus.

    Ich bin mir aber auch nicht sicher, ob man noch eine Programmiersprache gebraucht hat. Bin auf Herbst gespannt, dann seh ich mir das ganze mal selbst an...



  • Obj-C ist doch sehr ekelig, oder? Wenn die jetzt davon weg wollen, ist das ein Segen für die Apple-Jünger.

    Schade nur, das sie etwas neues gemacht haben. Sie hätten sich z.B. an D oder Xamarin wenden können.

    Die Apple-Jünger werden aber natürlich Swift benutzen. Ich finde es nicht schlimm, wenn sie nicht den Anspruch haben, auf andere Plattformen zu portieren. Es ist aber doch ein Aufwand wieder eine komplett neue Sprache zu lernen.



  • Ich kann nicht wirklich Objective-C, aber ekelhaft find ichs nicht unbedingt. Es ist gewöhnungsbedürftig, aber zumindest irgendwie interessant. Swift gefällt mir auf den ersten Blick nicht so wirklich. Das wirkt wirklich wie eine Scriptsprache, mit der ich vielleicht mal ein 200 Zeilen Script schreibe, aber kein Projekt mit mehreren zehnntausend Zeilen angehen würde.



  • Mechanics schrieb:

    Das wirkt wirklich wie eine Scriptsprache, mit der ich vielleicht mal ein 200 Zeilen Script schreibe, aber kein Projekt mit mehreren zehnntausend Zeilen angehen würde.

    Ahja. Was vermisst du denn an Swift? Gibt es etwas, was man mit Objective-C machen kann, aber nicht mit Swift? Ist Objective-C eleganter? Kompakter? Mächtiger? Performanter? Die Fragen muss man eher gegenteilig beantworten.

    Gruß,
    IBV



  • Vielleicht. Aber ich mag die Syntax einfach nicht, und viel mehr wollte ich damit auch nicht sagen. Ich mags nicht, dass Objective-C gleich schlechtgeredet wird und Swift als etwas ganz tolles neue präsentiert wird, worauf die Welt gewartet hat.



  • Mechanics schrieb:

    Vielleicht. Aber ich mag die Syntax einfach nicht, und viel mehr wollte ich damit auch nicht sagen. Ich mags nicht, dass Objective-C gleich schlechtgeredet wird und Swift als etwas ganz tolles neue präsentiert wird, worauf die Welt gewartet hat.

    Also hast du nichts mit substanz zu sagen.

    Objective-C war schon immer scheiße - das ist nicht ein neuer Trend es "schlecht" zu reden. Wenn man es nicht verwenden müsste, würde es Niemand benutzen.



  • 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