Ein nettes hallo an alle Swift-Coder

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

  • @matz
    danke für deinen Beitrag und ein Hallo zurück an dich.

    @hns
    ja das stimmt schon. Objective C gibt es schon viel länger. Ich habe ja selber 2 ältere Objective 2 Bücher be Amazon gekauft um mich ein wenig dort um zu schauen, bevor Swift mein grosses Interesse geweckt hatte. :)

    Auch bin ich kein "es-gibt-für-mich-nur-eine-Sprache-alle-anderen-interessieren-mich-nicht" Typ. Mir macht halt Swift sehr viel spass, deswegen lerne ich die Sprache. Da ich eh am Anfang stehe und eine Menge lernen muss und möchte, werden sich die Erfolge erst später melden.

    Zum lernen habe ich das Buch von M. Koffer "Swift 3 - Das umfassende Handbuch" gekauft. Als weitere Quelle, die mir zumindest bis jetzt gut geholfen hast, nutze ich codingtutor.de. Dort gibt es einige Swift-PDFs, die umsonst geladen werden können und sehr gut erklärt worden sind. Hat mir gerade z.B. bei den Thema Optionals unheimlich gut geholfen.

    Gruss aus Berlin ... AmigaCoder...
    Swift 3 Anfänger. Suche Gleichgesinnte Swift-Coder für Erfahrungsaustausch.
    Mein Apple-Universum: MacBook (13", Anfang 2015), ( 8 GB RAM), iPhone 5.

  • Wenn man erstmal ein paar sprachen kann, dann ist es gar kein Problem eine neue Sprache in weniger als 1 Woche zu lernen. Ich habe in meinen über 30 Jahren jetzt in über 10 verschiedenen Sprachen und Scriptsprachen gearbeitet und ich bin auch immer offen für Neues.
    Aber es muss eben auch einen Anreiz geben diese Sprache zu lernen. Swift bietet mir da gar nichts. Nicht nur, dass diese Sprache dermaßen in den Kinderschuhen steckt, dass sie regelmäßig neu umgeworfen wird, auch dass sie absolut nur für Apple Anwender brauchbar ist und keine Anlehnung an etwas hätte das ich bisher gemacht habe. Es ist eine absolute Nischensprache die nich überhaupt keine richtige Lobby hat und deren Verbreitung mehr als schleppend voran geht. Weiterhin ist es wieder mal so eine Sprache die meint strikte Typisierung wäre der goldene Gral des Programmierens weil es verhindert das die Programmierer Fehler machen. Das hat man damals bei Java auch schon gedacht. Das Ergebnis sieht man in Java 8. plötzlich gibt es für jede strikte Typisierung eine Ausnahme und eine Möglichkeit diese zu umschiffen. Natürlich ist das viel komplizierter als wenn man es gleich erlaubt hätte. Sinn sehe ich darin gar keinen.

    Warum nicht dem Programmierer alle Möglchkeiten geben und er kann entscheiden was er davon nutzt? Ich fände es gut,wenn mich die IDE darauf aufmerksam machen würde, wenn ich etwas programmiere das Fehleranfällig ist. Eben wenn ich nicht richtig typisiere oder etwas Vergleiche das nicht vom selben Typ ist. Aber das der Compiler es mir verbietet! Warum? Kann ja durchaus sein, das ich auch weis was ich tue...

    Ich verstehe um Beispiel nicht, warum es in Java die mächtigsten IDEs gibt aber keine mal auf die Idee kommt eine Warnung auszuwerfen wenn man Strings mich == vergleicht. Jeder zweite Post eines Neulings in Java Foren ist dieser Fehler. Das kann doch nun wirklich nicht so schwer sein.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Ich verstehe um Beispiel nicht, warum es in Java die mächtigsten IDEs gibt aber keine mal auf die Idee kommt eine Warnung auszuwerfen wenn man Strings mich == vergleicht. Jeder zweite Post eines Neulings in Java Foren ist dieser Fehler. Das kann doch nun wirklich nicht so schwer sein.
    IntelliJ bzw. Android Studio warnen selbstverständlich davor und vor vielen anderen problematischen Konstrukten. Das Problem sitzt in der Regel vor dem Bildschirm und ignoriert die fast komplett gelbe (= Hier ist eine Warnung), rechte Seitenleiste des Editors. Das ist umso unverständlicher, weil die Glühbirne in der Regel die Warnung auf Knopfdruck beheben kann.
    „Meine Komplikation hatte eine Komplikation.“

  • Thallius schrieb:

    dass diese Sprache … absolut nur für Apple Anwender brauchbar ist und keine Anlehnung an etwas hätte das ich bisher gemacht habe. Es ist eine absolute Nischensprache die nich überhaupt keine richtige Lobby hat und deren Verbreitung mehr als schleppend voran geht.

    Meinst Du das wirklich ernst? o_O

    Keine Lobby? Also IBM finde ich schon ziemlich stark. Nenne mir einen Big Player, der in den letzten 20 Jahren groß in Objective-C investiert hätte. Außer Apple selbst natürlich.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Keine Lobby? Also IBM finde ich schon ziemlich stark. Nenne mir einen Big Player, der in den letzten 20 Jahren groß in Objective-C investiert hätte. Außer Apple selbst natürlich.
    Es gab ja auch sogar mal Gerüchte, dass Google für Android überlegt, auf Swift umzusteigen. Vielleicht kann ich dann diesen Krampf aus der Bergsicht mal ernst nehmen. ;)

    Viel wichtiger als IBM (Who?) finde ich allerdings, dass es eine Open-Source- und Server-Strategie gibt. Ich weiß zwar nicht, ob das mal eine nennenswerte Community wird oder ob das für mich mal relevant wird. Der Sprache und Apple wird's jedenfalls eher nützen als schaden. Mit Swift 4 scheint Apple ja nun auch langsam mal erkannt zu haben, dass Rückwärtskompatibilität auch ein Great Thing ist.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:


    Es gab ja auch sogar mal Gerüchte, dass Google für Android überlegt, auf Swift umzusteigen. Vielleicht kann ich dann diesen Krampf aus der Bergsicht mal ernst nehmen. ;)

    M.W. ging es dabei nicht um einen 'Umstieg', sondern 'nur' um zusätzliche Unterstützung im Userspace… Ich kann mir sehr gut vorstellen, daß _das_ dann doch irgendwann mal kommt…

    macmoonshine schrieb:


    Viel wichtiger als IBM (Who?) finde ich allerdings, dass es eine Open-Source- und Server-Strategie gibt.

    Eben. Hinter der Server-Strategie steckt Who? Genau. Da ist IBM wirklich sehr engagiert. Mit eigenen Leuten an einem core-project. Und Swift haben sie auch schon für ihre Enterprize Server Platform(en) portiert…

    macmoonshine schrieb:


    Mit Swift 4 scheint Apple ja nun auch langsam mal erkannt zu haben, dass Rückwärtskompatibilität auch ein Great Thing ist.

    Gemach, gemach. Die Beschleunigung nimmt nur ab. Das ist ähnlich wie mit der Staatsverschuldung. Nimmt weiter zu, aber nicht mehr so stark. ;) Ich rechne damit, daß auch Swift 5 und 6 noch Code-breaking Überaschungen haben werden, dann vielleicht etwas 'sanfter'…
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • Markus Müller schrieb:

    Man kann obj-c Code nach Jahren sogar noch compilieren...SCNR ;)

    Es sei denn, Du hast 'Features' benutzt, die heute nicht mehr gehen. Beispiel: Objective-C-Class allocation auf dem Stack. Echt das ging mal in Objective-C. Seit Objective-C 2.0 aber nicht mehr. Und das ist eine Sprachgeschichte, keine API-Angelegenheit. Bei der API hat Apple in den letzten Jahren ganz schön rumge…
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Markus Müller schrieb:

    Man kann obj-c Code nach Jahren sogar noch compilieren...SCNR ;)
    Es sei denn, Du hast 'Features' benutzt, die heute nicht mehr gehen. Beispiel: Objective-C-Class allocation auf dem Stack. Echt das ging mal in Objective-C. Seit Objective-C 2.0 aber nicht mehr. Und das ist eine Sprachgeschichte, keine API-Angelegenheit. Bei der API hat Apple in den letzten Jahren ganz schön rumge…
    Bist Du da sicher? stackoverflow.com/questions/12…ting-objects-on-the-stack
    m.E. ging seit 1988 nur [Class alloc], was auf dem Heap alloziert.

  • torquato schrieb:

    Und das ist eine Sprachgeschichte, keine API-Angelegenheit. Bei der API hat Apple in den letzten Jahren ganz schön rumge…
    Unterhaltet Ihr Euch ernsthaft darüber, ob reine Sprachkonstrukte nach x Jahren noch kompilierbar sind? Ihr müsst echt in einem anderen Universum leben als ich :D

    Ich habe hier ein über fast 10 Jahre gewachsenes Gebilde mit Projekten unter macOS und iOS. Da reicht schon ein kleines SDK-Update, um mich vor lauter API-Changes blass werden zu lassen. Letztes Mal waren es ca. 150 Warnings ... gut, meist nur "deprecated", aber ich behebe sie lieber beizeiten, bevor sie mich später in den Hintern beißen.

    Sprachstabilität? Ist das wirklich ein langfristiges Thema (nicht zu verwechseln mit der Dynamik von Swift)?

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • hns schrieb:

    torquato schrieb:

    Markus Müller schrieb:

    Man kann obj-c Code nach Jahren sogar noch compilieren...SCNR ;)
    Es sei denn, Du hast 'Features' benutzt, die heute nicht mehr gehen. Beispiel: Objective-C-Class allocation auf dem Stack. Echt das ging mal in Objective-C. Seit Objective-C 2.0 aber nicht mehr. Und das ist eine Sprachgeschichte, keine API-Angelegenheit. Bei der API hat Apple in den letzten Jahren ganz schön rumge…
    Bist Du da sicher? stackoverflow.com/questions/12…ting-objects-on-the-stackm.E. ging seit 1988 nur [Class alloc], was auf dem Heap alloziert.
    Ja, bin ich. Ich habe es ja selber schon mal gemacht. Nur zu Testzwecken. Ist schon lange her. Das war so in den Nuller-Jahren.
    Man mußte dazu aber Obj-C zugrundeliegende C function calls verwenden, um an das C-struct Layout einer Klasse zu kommen. Nur mit Obj-C Methoden ging das nicht. Unter Obj-C 1 war das dokumentiert und erlaubt, mit Obj-C 2 nicht mehr.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?

  • torquato schrieb:

    Ja, bin ich. Ich habe es ja selber schon mal gemacht. Nur zu Testzwecken. Ist schon lange her. Das war so in den Nuller-Jahren.Man mußte dazu aber Obj-C zugrundeliegende C function calls verwenden, um an das C-struct Layout einer Klasse zu kommen. Nur mit Obj-C Methoden ging das nicht. Unter Obj-C 1 war das dokumentiert und erlaubt, mit Obj-C 2 nicht mehr.
    Ah, verstehe was Du meinst. Ja, da gab es tatsächlich ein Sprachkonstrukt das die iVar-Liste einer Klasse in eine Art typedef umgewandelt hat. @typeof(class) oder so ähnlich.
    Damit konnte man einen beliebigen Pointer in ein Objekt umwandeln, also auch einen Speicherbereich auf dem Stack. Oder gleich ein passendes struct auf dem Stack anlegen.
    Aber worin besteht der Nutzen?
    Ich habe das in >15 Jahren Obj-C-Erfahrung aber nie vermißt und denke mal dass das in 0.00000001% des weltweiten Obj-C-Codes genutzt wurde. Daher ist das kein signifikantes Gegenbeispiel, wenn man das dann mit ObjC 2 nicht mehr compilieren kann.

  • hns schrieb:

    torquato schrieb:

    Ja, bin ich. Ich habe es ja selber schon mal gemacht. Nur zu Testzwecken. Ist schon lange her. Das war so in den Nuller-Jahren.Man mußte dazu aber Obj-C zugrundeliegende C function calls verwenden, um an das C-struct Layout einer Klasse zu kommen. Nur mit Obj-C Methoden ging das nicht. Unter Obj-C 1 war das dokumentiert und erlaubt, mit Obj-C 2 nicht mehr.
    Ah, verstehe was Du meinst. Ja, da gab es tatsächlich ein Sprachkonstrukt das die iVar-Liste einer Klasse in eine Art typedef umgewandelt hat. @typeof(class) oder so ähnlich.Damit konnte man einen beliebigen Pointer in ein Objekt umwandeln, also auch einen Speicherbereich auf dem Stack. Oder gleich ein passendes struct auf dem Stack anlegen.

    Ja, genau. Du beschreibst das viel besser, als ich das heute noch könnte^^

    hns schrieb:


    Aber worin besteht der Nutzen?

    Der bare Nutzen ist doch eigentlich offensichtlich. Heap-Allocations sind bekanntlich teuer.

    Übrigens ist das eine der Fehlstellen, die ich in Swift sehe. Es fehlen stackbasierte Arrays fester Größe. Ein immer wieder auf swift-dev verlangtes Feature, aber das core team weiß immer noch nicht, was sie damit machen sollen…

    hns schrieb:


    Ich habe das in >15 Jahren Obj-C-Erfahrung aber nie vermißt und denke mal dass das in 0.00000001% des weltweiten Obj-C-Codes genutzt wurde. Daher ist das kein signifikantes Gegenbeispiel, wenn man das dann mit ObjC 2 nicht mehr compilieren kann.

    Klar, ist wohl kaum jemals in der Praxis benutzt worden.^^

    Fiel mir jetzt nur so spontan ein, um einfach mal das Märchen zu zerstören in C oder Objective-C wäre niemals irgendwas rückwärts zerbrochen worden… Doch ist es. Und da gibt's noch mehr.

    Swift ist einfach noch in einem frühen Entwicklungsstadium…
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?