Wechsel von Objective-C auf Swift ?

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

  • Ich sach ma: wenn Du Swift lernen willst ist immer jetzt der richtige Zeitpunkt.
    Sollte irgendwann Objective-C abgeschrieben werden, hast Du schon Erfahrung mit dem Neuen während sich Andere erst in der Umgewöhnungsphase befinden. Das kann Dir einen Vorteil verschaffen.

    Wenn Du produktiv mit den Cocoa Frameworks arbeiten möchtest, dann solltest Du das lassen.
    Viel zu viele Integrationsproblemchen zwischen Swift und den Objective-C Frameworks.
    «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

  • Hi,

    sich Swift aneignen ist nie ein Fehler. Man lernt ja nie aus, aber:
    • Niemals nicht würde ich auf die Idee kommen ein existierendes Projekt von Objective-C auf Swift zu Portieren. Absoluter Blödsinn.
    • Es gibt meiner Erfahrung nach massive Integrationsprobleme mit bestehenden Objective-C Libraries. Klar, das schaut alles gut aus in der Apple-Broschüre "Using Swift with Cocoa and Objective-.C". Irgendwelche Kinkerlitzchen-Beispiele gehen auch gut. Aber in der Praxis kämpfst Du ständig mit nichts-sagenden Compiler-Fehlermeldungen, Import-Problemchen, Abstürzen vom Compiler, Bugs desselben usw. usf. Und das kostet Zeit. Keine gute Idee, wenn Du eine Deadline hast oder Deinem Auftraggeber erklären musst warum Du immer noch nicht fertig bist.
    • Xcode 6 ist gerade im Bereich Swift noch ziemlich buggy. Abstürze sind die Regel, nicht die Ausnahme.
    • Swift an sich ist mir an einigen Stellen zu "over-engineered" (Enums z.B. und ob die type-inference ein Segen ist, sei mal dahingestellt, führt unter anderem zu schlechter lesbaren Code. Der Compiler kann die Typen zwar ermitteln, der Haken dabei: Ich bin kein Compiler)
    Klingt jetzt zwar alles recht negativ, trotzdem finde ich, das Swift schon das eine oder andere nette Feature hat, man sollte also nicht alles schlechtreden, aber kritisch begleiten 8)

    Gruß

    gandhi

  • Ich bin dabei eine neue Version einer meiner OS X Apps in neuer Version in swift umzusetzen. bisher klappt das sehr gut. Ich nutze aber auch keine third party libraries. Die App macht Audio-Geschichten. bei den DSP FunktioNen bin ich mit Swift bisher schneller. Im Endeffekt Vorteile und Nachteile, wie aber auch Objective-C . Was ich für den Mac nach massiven Speichermanagementfehlern wieder aufgegeben habe sind Storyboards auf OS X.Aber die sind ja unabhängig von der Sprache.
    Volker

  • Ich finde die Idee hinter Swift eigentlich auch ziemlich gut, und einige dinge sind eben viel schöner als in Objective-C, z.B. die for-schleifen, arrays mit typen, usw.

    Bei mir stürzt Xcode mit Swift allerdings auch noch ab und zu mal ab bzw. verhält sich komisch (z.B. werden Fehlermeldungen andauernd angezeigt und dann wieder ausgeblendet usw., es flackert regelrecht...)

    Außerdem:

    Quellcode

    1. let a = 5,
    2. b = 0.5
    4. let c = a + b

    Dass z.B. sowas nicht geht, finde ich ziemlich daneben. auch, dass Double und CGFloat "nicht kompatibel" sind, ist schwachsinnig. Bei Berechnungen, bei denen Int, Double und CGFloat vorkommen, geht mir das enorm auf die Nerven.

    Cannot invoke "+" on Argument List of (Double, int) -> ich kanns nicht mehr hören / lesen... das macht man einfach instinktiv!

    Hoffentlich wird da nochmal nachgebessert...

    (Edit: Großschreibung bei "Double" korrigiert, um niemanden zu verwirren. Natürlich ist damit Double in Swift gemeint.)

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

  • tedalligator5 schrieb:

    Ich finde die Idee hinter Swift eigentlich auch ziemlich gut, und einige dinge sind eben viel schöner als in Objective-C, z.B. die for-schleifen, arrays mit typen, usw.

    Ja, da freue ich mich auch immer wieder, wenn Apple [AnyObject] verwendet, obwohl ein genauerer Typ verwendet werden könnte. Die Iteration über beliebige Sammlungen, die per AnyObject-Referenz übergeben werden, ist auch sehr lustig. +scnr+ ;) :D
    „Meine Komplikation hatte eine Komplikation.“

  • tedalligator5 schrieb:

    auch, dass double und CGFloat "nicht kompatibel" sind, ist schwachsinnig.

    Das ist nicht schwachsinnig, das ist logisch. double ist ein Swift Datentyp. CGFloat ist ein (Objective-)C Datentyp. Seit wann sind beispielsweise ein C# Double und ein Java Float kompatibel?
    «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:

    Das ist nicht schwachsinnig, das ist logisch. double ist ein Swift Datentyp. CGFloat ist ein (Objective-)C Datentyp.

    Compiler sind case sensitiv, also ist double kein Swift Datentyp. Swift Datentypen fangen alle mit Großbuchstaben an, also Double. CGFloat ist auch nichts anderes, als ein float oder double, je nach dem ob für 32 oder 64 Bit System compiliert wird. Du hast aber in so fern recht, dass double != Double ist.

    tedalligator5 schrieb:

    Wenn das CG-Framework auch in Swift verfügbar ist, muss das gehen, finde ich...

    Das hat mit der Verfügbarkeit von Frameworks nichts zu tun. Swift kennt generell keine implizite Typkonvertierung, auch nicht zwischen Swift Datentypen:

    Quellcode

    1. let a: Int = 10
    2. let b: Float = 5.0
    4. let c = a / b // <- geht nicht
    5. let d = Float(a) / b // <- geht
    6. let e = a / Int(b) // <- geht

    Das ist so gewollt und da wird wohl kaum nachgebessert werden. Swift soll ja gerade typischer sein. Damit musst du in Swift leben.

  • Ich bekomme immer mehr den Eindruck, dass das Typsystem genau durch diese Eigenschaft zum Sargnagel für Swift wird. tedalligator5 hat da bezüglich CoreGraphics vollkommen recht: Wenn man Standard-Mathefunktionen zusammen mit CoreGraphics verwendet, ist man nur am rumcasten. Das ist nicht schön.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Ich bekomme immer mehr den Eindruck, dass das Typsystem genau durch diese Eigenschaft zum Sargnagel für Swift wird.

    Mein Reden, taugt einfach nix.
    Zur Behebung eines theoretischen Problems, welches praktisch nie ausgeliefert wird, werden etliche praktische Probleme eingeführt.
    Dohv.

    [Michael]
    Sie ziehen die 'Vorteile' der Typsicherheit halt voll durch.
    Damit sich niemand wundert, warum 10.2 / 3 genau 3 sein sollte, geht das halt einfach nicht…
    «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

  • Michael schrieb:


    Das ist so gewollt und da wird wohl kaum nachgebessert werden. Swift soll ja gerade typischer sein. Damit musst du in Swift leben.

    Das ist der Punkt. Nach dem Macoun-Vortrag haben wir viele Nachrichten bekommen, dass wir ja nur Bugs in Swift/clang gezeigt hätten, die aber sicherlich bald behoben sein werden.

    Tatsächlich hatten wir nur 1 (in Worten: einen) Bug gezeigt, den wir auch noch "hinweggedacht" haben, um zu zeigen, dass dann das Ergebnis immer noch unverständlich ist. Alles andere war das intendierte Verhalten von Swift. Offenkundig denken viele, dass äh Ungereimtheiten in Swift ein Bug wären. Sie sind das Konzept.
    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:

    Ich bekomme immer mehr den Eindruck, dass das Typsystem genau durch diese Eigenschaft zum Sargnagel für Swift wird. tedalligator5 hat da bezüglich CoreGraphics vollkommen recht: Wenn man Standard-Mathefunktionen zusammen mit CoreGraphics verwendet, ist man nur am rumcasten. Das ist nicht schön.

    Dafür hast du aber totale Sicherheit bei Swift.

    Auf der Macoun saßen da wohl 200 Leute vor uns. Die hatten, sagen wir mal, durchschnittlich 5 Apps programmiert. Wären dann 1000 Apps. Ich gehe davon aus, dass durchschnittlich eine App über alle Versionen(!) mal mindestens einen Bug hatte. Sind dann 1000 Bugs in front of me.

    Auf die Frage, wer den mal einen Typfehler in seinem produktiven Code hatte, hat 1 aufgezeigt. 1 Bug von vorsichtig geschätzt 1000 Bugs war also ein Typfehler. 0,1 %.

    Da musste dringend etwas getan werden.
    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"?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • Amin Negm-Awad schrieb:

    Das ist der Punkt. Nach dem Macoun-Vortrag haben wir viele Nachrichten bekommen, dass wir ja nur Bugs in Swift/clang gezeigt hätten, die aber sicherlich bald behoben sein werden.

    Anscheinend haben die Nachrichtenverfasser nicht begriffen, dass die Unzulänglichkeiten der Type-Inference ein inhärentes Problem und keine mangelhafte Umsetzung sind. Ich verstehe die Logik auch immer noch nicht: Einerseits soll das System typsicher sein andererseits soll der Compiler dem Programmierer die Entscheidung abnehmen, welchen Typ eine Variable hat.
    „Meine Komplikation hatte eine Komplikation.“

  • Jo, einer schickte sogar einen Tweet mit so einem Minicode wie in dem anderen Thread dargestellt und meinte, dass der Bug sicherlich bald beseitigt wird. Als Christian ihm antwortete, dass das kein Bug sei, sondern genau so gewünscht, wollte er es nicht glauben. Die anfängliche Begeisterung über Swift findet sicherlich einen Großteil ihrer Ursache in der anfänglichen Unkenntnis. Dazu gehört auch, dass die Type-Inference auch "rückwärts" funktioniert, was meines Wissens gar nicht dokumentiert ist, jedenfalls von keinem meiner Gesprächspartner gewusst wurde und lustige Effekte hat, siehe Vortrag.

    Das System dahinter ist, dass wenn der Compiler einen Typen schließen kann, das als typsicher definiert ist. Es wird übersehen, dass ein Bug (oder schwere Lesbarkeit) darin liegen kann, dass der Coder falsch, anders, gar nicht inferiert hat. Das ist mein zweiter zentraler Vorwurf an Swift: Das ist eine Programmiersprache für Compilerbauer, nicht für Coder.
    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"?

  • Hm, ich arbeite jetzt seit zwei Wochen (jeden Tag so 2, also nebenbei) mit Xcode 6.1 und Swift und bin bisher zufrieden. Ich erinnere mich an ähnliche Phasen bei jeder neuen Xcode Version, und auch davor beim ProjectBuilder lief es nicht immer runder...aber vmtl. konzentriere ich mich zu sehr auf meine Arbeit und ignoriere so nicht nur das Telefon sondern mittlerweile die SourceKit Meldung alle 5 bis 10 Minuten...