Swift Einschätzung

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

  • Swift Einschätzung

    Hallo,

    so als Betthupferl. Habe ich im Netz zum Thema Swift gefunden:

    ​The syntax is much simpler and concise, which lowers the the barrier of entry to iOS development, and makes the process more delightful.


    OK, ein Blick auf die Spezifikation hinsichtlich Enumerations sowie die Einbindung von C und/oder Objective-C lässt mich dem Satz aus tiefsten Herzen zustimmen :D . Kritische Stimmen könnten auch fragen "Und wovon träumt der Gute Mann nachts?". Aber wir wollen ja nicht kniefiesslig sein.

    gute Nacht

    gandhi
  • Ach, das hatte ich schon gelesen. Ich weiß zwar nicht, wo die Bedeutung der Syntax von Enums in der modernen App-Entwicklung liegt, aber wenn man für ein paar Tastendrücke weniger die späte Bindung aufgeben möchte, dann soll er es tun.

    Allerdings frage ich mich bei Ray Wenderlich, wie man eine Responder-Chain und Info-Panels ohne späte Bindung implementieren möchte. Vielleicht mit Signals und Slots? Oder doch mit Message-Maps?
    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"?
  • Amin Negm-Awad schrieb:

    Vielleicht mit Signals und Slots? Oder doch mit Message-Maps?

    Ich habe den Eindruck, dass Apple für solche Fälle, immer mehr Ausnahmen und Hintertürchen einbaut, z. B. für Core-Data-Entities gibt's das Attribut @NSManaged. Das macht natürlich auch die Sprache viiiieeeel einfacher und die Sprache kompakter. :D ;)
    „Meine Komplikation hatte eine Komplikation.“
  • Marco Feltmann schrieb:

    Gibt es nicht @dynamic für genau solche dynamischen Fälle? +scnr+

    Mit @dynamic kommst du da kaum weiter. Der Sender muss ja dynamisch verschicken und dabei generisch programmiert sein. Du brauchst also so etwas wie -performSelector…

    Arg, vielleicht meintest du Macmoonshine.

    Aber auch hier: Objective-C und Core Data funktionieren ohne @dynamic. Das ist Syntactic-Sugar. Swift und Core Data funktionieren nicht ohne NSManaged.
    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"?
  • macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    Vielleicht mit Signals und Slots? Oder doch mit Message-Maps?

    Ich habe den Eindruck, dass Apple für solche Fälle, immer mehr Ausnahmen und Hintertürchen einbaut, z. B. für Core-Data-Entities gibt's das Attribut @NSManaged. Das macht natürlich auch die Sprache viiiieeeel einfacher und die Sprache kompakter. :D ;)

    Jepp, so etwas vermute ich auch. Und dann sind wir bei dem Zustand, dass Swift OC3 ist nur in scheiße.
    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"?
  • Amin Negm-Awad schrieb:

    Mit @dynamic kommst du da kaum weiter. Der Sender muss ja dynamisch verschicken und dabei generisch programmiert sein. Du brauchst also so etwas wie -performSelector…

    Davon habe ich viel zu wenig Ahnung.
    Ich gehe davon aus, dass Du an -performSelector… und objc_msgsend() fest hältst, weil Dir keine anderen Möglichkeiten bekannt sind dasselbe zu erreichen.
    Ist zumindest bei mir der Fall, und was ich selber denk' und tu'…

    Wirklich interessant ist und bleibt aber die Frage: braucht man dieses dynamische Zeugs nach der Machtübernahme durch Swift überhaupt noch?

    Blicken wir mal der Realität ins Auge:
    Wie viele iOS Entwickler kennen die Responder Chain? Wie viele wissen diese zu nutzen? Und wie viele nutzen sie tatsächlich?

    Wie viele iOS Entwickler kennen Core Data? Wie viele wissen dies richtig zu benutzen? Und wie viele benutzen es dennoch falsch?

    Wie oft im Entwickleralltag ist man mal dabei, die Klassen einer Instanz zur Laufzeit auszutauschen?

    Gut, okay, die Integration der Cocoa(touch) Frameworks in Swift ist noch gelinde gesagt eine mittelschwere Katastrophe. Eben weil das mittlerweile über 20 Jahre alte Konzept 'Objective-C' mit dem ungefähr 3 Jahre jungen Konzept 'Swift' in höchstem Maße inkompatibel ist.

    Dennoch: wie viele Vorteile der hohen Dynamik Objective-Cs nutzt der durchschnittliche Entwickler so pro Monat?
    Hier dürfte einzig und allein KVO als Schlagwort mit einer Nutzungsrate höher 0.314 fallen.
    Und genau das soll, wenn der below für seinen Vortrag richtig recherchiert hat, in Swift ebenfalls durch so ein Attribut möglich sein…
    «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
  • macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    Vielleicht mit Signals und Slots? Oder doch mit Message-Maps?

    Ich habe den Eindruck, dass Apple für solche Fälle, immer mehr Ausnahmen und Hintertürchen einbaut, z. B. für Core-Data-Entities gibt's das Attribut @NSManaged. Das macht natürlich auch die Sprache viiiieeeel einfacher und die Sprache kompakter. :D ;)


    Häretiker! Die deutsche Steuergesetzgebung funktioniert nach dem selben Prinzip. :rolleyes:
  • Marco Feltmann schrieb:


    Blicken wir mal der Realität ins Auge:
    Wie viele iOS Entwickler kennen die Responder Chain? Wie viele wissen diese zu nutzen? Und wie viele nutzen sie tatsächlich?
    Wie viele iOS Entwickler kennen Core Data? Wie viele wissen dies richtig zu benutzen? Und wie viele benutzen es dennoch falsch?
    Wie oft im Entwickleralltag ist man mal dabei, die Klassen einer Instanz zur Laufzeit auszutauschen?


    Swift … die Rechtschreibreform unter den Programmiersprachen. 8o
  • Dass die meisten Entwickler nicht die Vorzüge des echten Message-Passings (bzw. dynamischer Methodenaufrufe) nutzen, ist wahrscheinlich richtig.

    KVO funktioniert in Swift im Prinzip so wie in Objective-C, aber:

    Die observierte Klasse muss die zu observierende Property als dynamic kennzeichnen, und damit fängt das Problem schon an. Wer macht das? Damit lassen sich nur Properties observieren, die dafür vorgesehen wurden. Da der Swift-Programmierer ja sehr auf Geschwindigkeit bedacht ist, wird ehr eher dazu neigen, diesen Modifizierer wegzulassen. Innerhalb eines Programms ist das nicht schlimm, weil man es nachträglich hinzufügen kann. Bei Bibliotheken ist das problematisch.

    Das erinnert mich an C++: Dort muss man auch die objekt-orientierte Eigenschaft der Überschreibbarkeit von Methoden durch das Schlüsselwort virtual explizit einschalten.
    „Meine Komplikation hatte eine Komplikation.“
  • Marco Feltmann schrieb:

    Amin Negm-Awad schrieb:

    Mit @dynamic kommst du da kaum weiter. Der Sender muss ja dynamisch verschicken und dabei generisch programmiert sein. Du brauchst also so etwas wie -performSelector…

    Davon habe ich viel zu wenig Ahnung.
    Ich gehe davon aus, dass Du an -performSelector… und objc_msgsend() fest hältst, weil Dir keine anderen Möglichkeiten bekannt sind dasselbe zu erreichen.
    Ist zumindest bei mir der Fall, und was ich selber denk' und tu'…

    Wirklich interessant ist und bleibt aber die Frage: braucht man dieses dynamische Zeugs nach der Machtübernahme durch Swift überhaupt noch?

    Blicken wir mal der Realität ins Auge:
    Wie viele iOS Entwickler kennen die Responder Chain? Wie viele wissen diese zu nutzen? Und wie viele nutzen sie tatsächlich?

    Wie viele iOS Entwickler kennen Core Data? Wie viele wissen dies richtig zu benutzen? Und wie viele benutzen es dennoch falsch?

    Wie oft im Entwickleralltag ist man mal dabei, die Klassen einer Instanz zur Laufzeit auszutauschen?

    Gut, okay, die Integration der Cocoa(touch) Frameworks in Swift ist noch gelinde gesagt eine mittelschwere Katastrophe. Eben weil das mittlerweile über 20 Jahre alte Konzept 'Objective-C' mit dem ungefähr 3 Jahre jungen Konzept 'Swift' in höchstem Maße inkompatibel ist.

    Dennoch: wie viele Vorteile der hohen Dynamik Objective-Cs nutzt der durchschnittliche Entwickler so pro Monat?
    Hier dürfte einzig und allein KVO als Schlagwort mit einer Nutzungsrate höher 0.314 fallen.
    Und genau das soll, wenn der below für seinen Vortrag richtig recherchiert hat, in Swift ebenfalls durch so ein Attribut möglich sein…
    Die statische Typisierung + Templates gegenüber dynamischer Typisierung als modern zu bezeichnen, finde ich bei Apple ja schon lustig. Man meint fast, James Watt ist am Werk.

    Man nutzt das übrigens täglich. Bei Wenderlich ging es ja darum, ob Objective-C aufgegeben werden könnte, wird usw. Und das bedeutet, dass all das nicht mehr geht, ebenso Undo-Manager, Proxys, "anständiges KVO" usw. usf. Nein, das heißt nicht, dass man das in Swift nachprogrammieren muss, was ja einfach eine Aufwandsfrage ist, sondern dass das alles so gar nicht mehr geht. Man muss es neu konzipieren. Und die Konzepte, die hier in statisch typisierten Programmiersprachen auftauchen, habe ich oben genannt. Das will man nicht und ist sicherlich nicht modern.

    Du wirst also auch ganz ohne Kenntnis von der Responder-Chain darauf verzichten müssen und dann mitbekommen, was der Grund für dieses Konzept war. Ganz schnell. Ganz schmerzhaft. Ganz viel Boiler-Plate. Ganz viel Code-Generierung. Hurra!

    So mancher Swifty hat noch gar nicht mitbekommen, was das Konzept von Swift durchgezogen bedeutet, weil Objective-C an allen Ecken und Enden hilft. "With a little help of my friends" …
    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"?
  • kmr schrieb:

    macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    Vielleicht mit Signals und Slots? Oder doch mit Message-Maps?

    Ich habe den Eindruck, dass Apple für solche Fälle, immer mehr Ausnahmen und Hintertürchen einbaut, z. B. für Core-Data-Entities gibt's das Attribut @NSManaged. Das macht natürlich auch die Sprache viiiieeeel einfacher und die Sprache kompakter. :D ;)


    Häretiker! Die deutsche Steuergesetzgebung funktioniert nach dem selben Prinzip. :rolleyes:
    Na, da muss man aber der Fairness halber sagen, dass die Steuergesetzgebung eher Löcher stopft, die als Hintertür von umtriebigen Leuten gesucht worden sind.
    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"?
  • Wann ist Dir mal Produktivcode um die Ohren geflogen, den Du nicht typsicher programmiert hast?
    (Und warum hast Du ihn so ausgeliefert???)

    Amin
    Smartphones und Tablets sind modern. Können die andere Dinge als damals™ die Palm Teile? Nein.
    HTML5 ist modern. Kann das signifikant andere Dinge als damals™ HTML, CSS und Javascript? Nein.
    (Vielleicht das Canvas Element – wird von vielen SmartTVs meines Wissens nicht unterstützt.)
    Die Cloud ist modern. Kann die was Anderes als damals™ FTP und HTTP? Nein.
    Die AfD ist modern. Kann die was Anderes als damals™ die DVU oder davor die NPD oder noch früher die NSDAP? +hust+
    Die NSA ist modern. Kann die was Anderes als damals™ der MAD oder davor die Stasi? Nein, höchstens effektiver.

    Genau so verhält es sich mit Swift.
    Kann Swift mit seiner statischen Typisierung und den Templates etwas Anderes als C++? Nein. Höchstens noch 'nicht cross platform kompatibel sein'
    Und dennoch ist es modern.

    Ich weiß bis heute nicht, wie man darauf kommt, 'modern' mit 'einfach', 'intuitiv', 'sinnvoll' und 'elegant' gleich zu setzen.
    Das menschliche Bewusstsein an sich hat ein paar Hunderttausend Jahre auf dem Buckel. Das brauchte auch nicht 'modernisiert' werden.

    Wobei natürlich eine Frage nicht abschließend geklärt ist:
    Meinen die jetzt 'modern' im Sinne von 'aktuell' oder eher 'modern' im Sinne von 'verwesen'?
    «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
  • macmoonshine schrieb:

    Das erinnert mich an C++: Dort muss man auch die objekt-orientierte Eigenschaft der Überschreibbarkeit von Methoden durch das Schlüsselwort virtual explizit einschalten.

    Sollten die Swift am Ende ebenso objektbasiert klassenorientiert gestalten wie C++, dann konvertiere ich zu Linux und entwickle ausschließlich in Smalltalk.
    Oder ich bau mir ein eigenes Cross-Platform kompatibles AppKit. GnuStep die 1024ste oder so. ;)
    «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 ich weiß nicht, was ihr alle habt. Ist ein bisschen so wie mit den alten Leuten: "Früher war alles besser, sogar die Zukunft..." :)

    Mir gefallen etliche Sachen an Swift, und ja, die Typsicherheit gehört dazu. M.M.n. eine willkommene Entrümpelung von Objective-C was ja aber nicht sofort unbrauchbar wird, nur weil es eine zweite Apple-Sprache gibt (wer mag z.B. das NSNumber boxing, um primitive values in den Cocoa collections verwenden zu können?).
  • Markus Müller schrieb:

    Also ich weiß nicht, was ihr alle habt. Ist ein bisschen so wie mit den alten Leuten: "Früher war alles besser, sogar die Zukunft..."

    War es ja auch! ;) +scnr+

    Es ist sicherlich nicht alles schlecht an Swift; umgekehrt ist aber sehr vieles auch nicht gut, sondern eher eine Verschlechterung gegenüber Objective-C. Dazu gehört nicht nur die statische Typisierung. Mich stören übrigens auch diese halbwahren und falschen „Marketing“-Aussagen seitens Apple und anderen.
    „Meine Komplikation hatte eine Komplikation.“