Swift-evolution

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Amin Negm-Awad schrieb:

    mattik schrieb:

    Soll das so eine Pascalartige Oberlehrer-Bevormundungssprache werden, bei der mir die Sprache permanent erklären will, was ihre Vorstellung von schön und richtig ist?
    Gerade feiern wir die Geburt unseres Erretters und du nennst Jesus Chris Lattner einen Oberlehrer? Preise den Erlöser, du Pharisäer, dein Heiland ist dir geboren. Und wehe, du weichst von den Lehren ab. Schon aus der Ferne wirst du den Clang der Pferde der heiligen spanischen Inquisition hören. (Wird mal wieder Zeit, dass man einen Nubbel verbrennen kann.)
    Hey, endlich keine ellenlangen Flamewar mehr, ob Foo*bar, Foo* bar, Foo *bar oder Foo * bar die einzig heilsbringende Lehre ist.

    Lobe den Herren,
    der alles so herrlich regieret,
    der dich auf Adelers
    Fittichen sicher geführet,
    der dich erhält,
    wie es dir selber gefällt;
    hast du nicht dieses verspüret?

    Andererseits sollte man den anwachsenden Haufen Scheiße auch nicht erhöhen.

    Swift lässt sich eher mit einer untersetzen Teilzeitdomina aus Wanne-Eickel vergleichen.
    Merke: Traue keinem Heilsbringer, der keine Löcher in den Händen hat.

    Aber warum kennst du dich so gut mit Teilzeitdominas aus Wanne-Eickel aus?
    Multigrad - 360°-Produktfotografie für den Mac

  • Michael schrieb:

    MCDan schrieb:

    Michael schrieb:

    macmoonshine schrieb:

    Schon bei den Nullable-Deklarationen haben die an einigen Stellen geschlampt, und Parameter in den Objective-C-Headern nicht als nonnull deklariert, obwohl die Doku nil ausdrücklich erlaubt.
    Auch den umgekehrten Fall gibt es, was ja noch viel schlimmer ist. Parameter als _Nullable deklariert und in der Erklärung der Parameter direkt darunter steht „This parameter must not be nil“.Zum Thema selbst. Es ist halt auch ein Nachteil der Open Source Geschichte, dass jeder seine persönlichen Vorlieben am liebsten zum Standard erheben möchte. Ich hoffe nur, dass Apple da nicht den Faden verliert und Swift durch Umsetzung solcher, in meinen Augen sinnlosen Vorschlägen, endgültig gegen die Wand fährt. Ich finde es ja schon bemerkenswert, dass eine Version 3.0 immer noch keine Sourcecode Kompatibilität bringen soll. Da kann man Swift doch immer noch nicht produktiv nutzen, bzw. man muss schon ein wenig Mut haben. Ich kenne da jemanden, dem ist mit Schrecken aufgefallen, dass er für seine App zur Zeit nicht mal eben schnell einen Bugfix liefern könnte, weil sie noch in Swift 1.2 geschrieben ist. Er müsste die erst mal auf Swift 2.0 heben, was aber eben doch nicht einfach per Knopfdruck gemacht ist.
    Darf man mit Swift 1.2 geschriebene Apps nicht mehr submitten?
    Dürfen ist eine Frage des Könnens. Kann man noch mit Xcode Versionen kleiner 7 submitten?
    Klar, ich kann hier max. Xcode 6.2 verwenden, da ich noch OS X 10.9 Mavericks habe. Damit hatte ich beim Submit bisher keine Problem. Als iOS SDK verwende ich damit dann max. 8.2. Damit scheint Apple aktuell auch noch zufrieden zu sein. ;)

    Ich gehe aber davon aus, dass ich diese Kombination nicht mehr all zu lange verwenden kann, wenn man nur noch mit Xcode 7.x submitten darf bzw. iOS 9 das min. SDK wird.

  • mattik schrieb:

    Amin Negm-Awad schrieb:

    mattik schrieb:

    Soll das so eine Pascalartige Oberlehrer-Bevormundungssprache werden, bei der mir die Sprache permanent erklären will, was ihre Vorstellung von schön und richtig ist?
    Gerade feiern wir die Geburt unseres Erretters und du nennst Jesus Chris Lattner einen Oberlehrer? Preise den Erlöser, du Pharisäer, dein Heiland ist dir geboren. Und wehe, du weichst von den Lehren ab. Schon aus der Ferne wirst du den Clang der Pferde der heiligen spanischen Inquisition hören. (Wird mal wieder Zeit, dass man einen Nubbel verbrennen kann.)Hey, endlich keine ellenlangen Flamewar mehr, ob Foo*bar, Foo* bar, Foo *bar oder Foo * bar die einzig heilsbringende Lehre ist.

    Lobe den Herren,
    der alles so herrlich regieret,
    der dich auf Adelers
    Fittichen sicher geführet,
    der dich erhält,
    wie es dir selber gefällt;
    hast du nicht dieses verspüret?

    Andererseits sollte man den anwachsenden Haufen Scheiße auch nicht erhöhen.

    Swift lässt sich eher mit einer untersetzen Teilzeitdomina aus Wanne-Eickel vergleichen.
    Merke: Traue keinem Heilsbringer, der keine Löcher in den Händen hat.
    Aber warum kennst du dich so gut mit Teilzeitdominas aus Wanne-Eickel aus?
    Dazu möchte ich mich nicht äußern.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Ehrlich gesagt verstehe ich dieses Gebashe nicht.
    Also speziell dieses Herumgehacke auf 'final as default', 'i++ is dead' und 'for the loose'.

    Wenn dadurch erreicht wird, dass der 08-15 Standardhipster (und wer sonst setzt aktuell seine Projekte in Swift um?) erst überlegt bevor er eine Subklasse anlegt, dann ist doch alles geritzt.

    Ob man i++ bzw. ++i braucht sei auch mal dahingestellt.
    Ja, es ist weniger Tipparbeit.

    Dennoch ist die Intention einfach klarer, wenn es heißt:

    C-Quellcode

    1. i += 1;
    2. doSomethingWith(i);
    4. doSomethingWith(j);
    5. j += 1;
    7. /** Statt
    8. * doSomethingWith(++i);
    9. * doSomethingWith(j++);
    10. */

    Dass for rausfliegt ist auch okay. Wo bitte braucht man denn heutzutage noch i++, wenn nicht in for(i=0;i<j;i++)?
    Swift bietet ja nun mehr als genug Möglichkeiten, um durch Collections, Enums und Structs zu iterieren.
    Ein kontinuierliches Inkrementieren eines Indexwertes in Verbindung mit dem Abholen des dahinterliegenden Wertes einer Collection ist damit überflüssig.
    (Wofür man for(i=0;i<j;i++) sonst noch brauchen könnte weiß ich nicht.)

    Wie heißt es so schön in 'Practices of an Agile Developer': Know When To Unlearn

    Und eins muss man dem Lattner lassen: Flexibel isser. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    erst überlegt bevor er eine Subklasse anlegt
    Da gibt's dann nichts mehr zu überlegen.


    Marco Feltmann schrieb:

    Dass for rausfliegt ist auch okay.
    Das ist aber doch genau der Punkt:
    1. Man verkleinert den Sprachumfang einer produktiven Programmiersprache, was dazu führt, das Code bricht.
    2. Das Ganze wird mit der inkompatiblen Philosophie von Swift begründet. Mag ja sein. Ich finde es aber ein sehr schlechtes Zeichen, weil das nur den Schluss zulässt, dass man sich bei der Entwicklung dieser Sprache nicht viele Gedanken gemacht hat.
    „Meine Komplikation hatte eine Komplikation.“

  • Marco Feltmann schrieb:

    Wenn dadurch erreicht wird, dass der 08-15 Standardhipster (und wer sonst setzt aktuell seine Projekte in Swift um?) erst überlegt bevor er eine Subklasse anlegt, dann ist doch alles geritzt.
    Wenn das eine Hipstersprache bleiben soll hast du Recht. Ich hatte das Gefühl, dass das langfristig auch von Leuten verwendet werden soll, die damit etwas Sinnvolles machen wollen. Dann ist so ein Heckmeck nicht zu gebrauchen.

    Man kann ja über die einzelnen Konstrukte unterschiedlicher Meinung sein (ich glaube beispielsweise, dass eine For-Schleife durchaus sinnvoll sein kann, z.B. wenn man nicht nur die Array-Werte, sondern auch die Indizes braucht). Aber ohne Not Semantik ändern oder Syntax reduzieren? Ach nö, darauf habe ich keine Lust.

    Meinetwegen können sie ja einen Strict-Mode oder sowas einführen, der dann alles rausschmeißt, was den Sprachgöttern nicht in den Kram passt. Ich glaube aber nicht, dass syntaktische Gängelung in irgend einer Weise zu besserem Code führt. Dazu müsste man keine For-Schleifen, sondern eher Copy & Paste aus Programmierforen verbieten.
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:

    ich glaube beispielsweise, dass eine For-Schleife durchaus sinnvoll sein kann, z.B. wenn man nicht nur die Array-Werte, sondern auch die Indizes braucht
    Gerade dafür bietet Swift ein, wie ich finde, durchaus gelungenes alternatives Konstrukt an:

    Quellcode

    1. let array = ["A", "B", "C", "D"]
    2. for (index, value) in array.enumerate() {
    3. print("\(index): \(value)")
    4. }
    Das nur am Rande bemerkt.

    Abgesehen davon, daß ich offensichtlich hier zur Minderheit gehöre, die Swift an sich überwiegend positiv bewertet, teile ich die hier vorherschende Kritik am Rausschmiß der C-style-for-loops. Kurz gefaßt:

    1.) Es wird kein Problem gelöst.
    2.) Es wird nichts verbessert.

    Bei der Gelegenheit eine Preisfrage. Wie würde man folgende For-loop zukünftig in Swift schreiben?

    Quellcode

    1. for var i = 10; i > 0; i -= 2 {
    2. print(i)
    3. }
    Na? Hat jemand 'ne Idee? Versucht das mal ohne for ;; umzuschreiben. :)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von torquato ()

  • Wo ist das Problem?

    Mal in c, da ich die Swift Syntax nicht kenne.

    Quellcode

    1. int i = 10;
    2. while (i > 0)
    3. {
    4. print(i);
    5. i -= 2;
    6. }
    Ich verstehe allerdings nicht, was an einem while-loop jetzt besser als an einem for-loop sein soll. Evtl. hat Herr Lattner dazu ja einen Hinweis oder ein gutes Argument parat. ?(

  • MCDan schrieb:

    Wo ist das Problem?

    Mal in c, da ich die Swift Syntax nicht kenne.

    Quellcode

    1. int i = 10;
    2. while (i > 0)
    3. {
    4. print(i);
    5. i -= 2;
    6. }

    Genau das habe ich erwartet. Jede For-loop läßt sich als While-loop schreiben, per Definition. Das ist genau das, was jeder (JEDER!) instinktiv sofort als erstes machen würde. Code-Bloat und Unleserlichkeit sind vorprogrammiert.

    Es gibt tatsächlich ein kompakteres Swift-Statement für so einen Fall. Bin gespannt, ob jemand, bzw. wieviele darauf kommen...

    Nebenbemerkung: In diesem Fall zeichnet Doug Gregor als Review manager verantwortlich, nicht Chris Lattner. Ehre, wem Ehre gebührt.

  • Naja, die Existenz eines Konstruktes mit seiner Benutzung begründen ist aber schon sehr abstrakt. Wofür brauchst Du das?

    mattik:
    Ich erinnerte mich an meine Arbeit mit ObjC. Da nutze ich ewig keine for-Schleifen mehr. Selbst fast enumeration über das forin Konstrukt ist den enumerateXyzUsingBlock: gewichen.

    Dinge mitschleppen, weil das schon immer so war halte ich für sehr konservativ.
    Die Existenz ist in Swift eher sinnlos und mutmaßlich langsamer als die spracheigene Variante mit den Tupeln.

    Aber ka, da hätten die auch in 0.9 schon drauf kommen können und den Scheiß vor Release rauswerfen müssen. So ist das fragil.
    Aber das zieht sich so durch die Swift Evolution. Eventuell wollen sie alle Sprachen überholen: Von Geburt bis Begräbnis in nur 5 Jahren, aber mit ordentlich Aufmerksamkeit.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Also für die Standard-For Loop nähme ich den for-in Krams.

    Quellcode

    1. for i in 10...1 {
    2. print( i )
    3. }
    Oder so. Zwei Punkte, drei Punkte, Gleichheitszeichen - ich seh da nicht mehr durch.

    Jedenfalls hoffe ich, dass man das nich noch weiter vermurksen kann, so dass er nur jedes Dritte anspringt... :(
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Also für die Standard-For Loop nähme ich den for-in Krams.

    Quellcode

    1. for i in 10...1 {
    2. print( i )
    3. }
    Oder so. Zwei Punkte, drei Punkte, Gleichheitszeichen - ich seh da nicht mehr durch.

    Jedenfalls hoffe ich, dass man das nich noch weiter vermurksen kann, so dass er nur jedes Dritte anspringt... :(
    Ich tue mal so, als ob das eine ernsthafte Antwort wäre...^^

    Nein. Das geht/paßt nicht. Aus zwei Gründen:
    1.) Beim Typ Range<T> kann per Definition die linke Seite nicht größer als die rechte sein. Also 0...3 ja, 3...0 nein. :(
    2.) Das Inkrement, bzw. Dekrement ist nicht 2.

    Ich würde sagen: Der Teekessel ist ganz kalt...^^
    Trotzdem: Danke für's Mitmachen!

    Kleiner Tipp: Du könntest sowas in Xcode in einem Playground ausprobieren... ;)

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von torquato ()

  • Marco Feltmann schrieb:

    Dinge mitschleppen, weil das schon immer so war halte ich für sehr konservativ.
    Die Existenz ist in Swift eher sinnlos und mutmaßlich langsamer als die spracheigene Variante mit den Tupeln.
    mir ist es aber wichtig dass ich 10 jahre alten code einfach kompilieren kann. das ging bei obj-c bisher fast immer (und bei C sowieso). Bis auf einige deprecated methoden die man ändern sollte, läuft doch meist alles.
    Swift code der 2 jahre alt ist, musste inztwischen sschon zwei mal geändert werden dass er überhaupt compiliert...

  • tsunamix schrieb:

    MCDan schrieb:

    Wo ist das Problem?

    Mal in c, da ich die Swift Syntax nicht kenne.

    Quellcode

    1. int i = 10;
    2. while (i > 0)
    3. {
    4. print(i);
    5. i -= 2;
    6. }
    Genau das habe ich erwartet. Jede For-loop läßt sich als While-loop schreiben, per Definition. Das ist genau das, was jeder (JEDER!) instinktiv sofort als erstes machen würde. Code-Bloat und Unleserlichkeit sind vorprogrammiert.

    Es gibt tatsächlich ein kompakteres Swift-Statement für so einen Fall. Bin gespannt, ob jemand, bzw. wieviele darauf kommen...

    Nebenbemerkung: In diesem Fall zeichnet Doug Gregor als Review manager verantwortlich, nicht Chris Lattner. Ehre, wem Ehre gebührt.
    Ok, wie sieht die umwerfende und super innovative Lösung in Swift denn nun aus?

    Ich hoffe der Grund für dieses neue Swift-Statement ist nicht einfach nur kompakterer Code, sondern das ganze ist auch deutlich lesbarer und verständlicher als der entsprechende for-/while-loop.

    Dass der Compiler dieses Statement evtl. in besseren, weil schnelleren, Code übersetzt, kann ja wohl nicht der Grund für eine obskure Syntax oder ein Statement sein. Da muss dann nicht der Entwickler der Sprache, sondern der Compiler Entwickler entsprechend optimieren.

    Ich schaue mir dieses kompaktere Swift-Statement aber gerne mal an. ;)

    Ach und BTW: Frohes neues Jahr! :)

  • Marco Feltmann schrieb:

    Dinge mitschleppen, weil das schon immer so war halte ich für sehr konservativ.
    Das ist ja auch die Hauptbegründung in der Evolutionliste für das Rausschmeißen von verschiedenen Konstrukten. Ich fände es auch nicht schlimm, wenn Swift keine C-For-Schleifen oder Post-Inkrement- oder -Dekrement-Operatoren hätte. Was ich schlimm finde, ist das Streichen von Konstrukten aus einer Programmiersprache, weil dadurch Code bricht.

    Das Verbieten von Vererbung und Überschreibung finde ich allerdings als Konstrukt völlig daneben, egal ob implizit oder über ein explizites Schlüsselwort, wie es bislang schon möglich ist. Das schränkt für den Vorteil einer zweifelhaften Optimierbarkeit die Möglichkeiten erheblich ein, und führt letztendlich nur zu POITROAE, Stinkendem Code und unnötiger Arbeit.
    „Meine Komplikation hatte eine Komplikation.“

  • Quellcode

    1. for i in 10.stride(to: 0, by: -2) {
    2. print(i)
    3. }
    Dinge wie die For-Schleife zu killen finde ich im aktuellen Stadium nicht so schlimm, wenn der Konverter funktionieren wird.
    Wenn man eine junge Sprache weiterführen will (und zudem jetzt das öffentliche Mitwirken erlaubt), ist es fraglich ob man jetzt schon das Korrigieren von anfänglichen Umsetzungen nicht mehr erlaubt.

    Eine Programmiersprache muss weit länger existieren als die kurze Zeit Swift bisher.
    Ich denke jedem ist aber klar, dass das Brechen der Kompatibilität alten Codes in den nächsten 1-2 Jahren aufhören muss und IMO wird es das auch.

    Alte Konstrukte die man aus Gewohnheit von C übernommen hat dürfen meiner Meinung nach auch gerne gekillt werden.
    Wenn ich in einer Sprache 10 Möglichkeiten habe das selbe auszudrücken, ohne dabei merklich Code oder Zeit einzusparen, dann ist das nicht wirklich ein Gewinn oder Wünschenswert.

    Zum Thema Subclassing sehe ich das aber wie der Rest hier.
    Anstatt im Forum zu meckern sollten wir aber evtl. lieber die Zeit dafür investieren die Bedenken auf swift.org zu bekräftigen.

    Ist ja nicht so, dass es dort nicht viele Gegenstimmen gäbe.
    Und nicht jedes eingereichte Proposal oder Hinfurz bedeuted, dass dies auch so übernommen wird.


    Somit ist der Aufruf hier sicher nicht die blödeste Idee:
    curtclifton.net/app-developers-on-swift-evolution

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Thyraz ()

  • macmoonshine schrieb:

    tsunamix schrieb:

    Hat jemand 'ne Idee?

    Quellcode

    1. for var _i in (2...10).reverse() {
    2. let i = 2 * _i
    3. print("\(i)")
    4. }

    Der call nach .reverse() ist gar nicht mal so schlecht. Löst aber natürlich nur die Hälfte des Problems, das Runterzählen. Das Dekrement müßte man dann wohl eher separat mit Modulo lösen... *ächts* Der unmittelbaren Leesbarkeit hilft das auch nicht....