Swift oder Objective C

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

  • MyMattes schrieb:

    Amin Negm-Awad schrieb:

    Ich halte Fragen wie "Typdynamik", "Generics", "Speicherverwaltung" für zentral beim Erlernen einer Programmiersprache und wenn dies die Programmiersprachen unterschiedlich handhaben, ist das nicht unerheblich.

    Für das Erlernen einer Programmiersprache: Ja. Für das Erlernen des Programmierens: Nein. Das eine hat mit dem anderen nur bedingt zu tun, und Programmieren kann ich auch mit Pseudocode lernen.

    Als Anfänger würde ich auf der gewünschten Plattform die Sprache mit der weitesten Verbreitung / dem besten Community-Support wählen. Sonst wird es bei Problemen schnell einsam. Und hier dürfte Swift ObjC doch "etwas" unterlegen sein.

    Mattes


    Ich glaube du hast noch keinen Community-Support für Java gesucht oder? Wenn Du im größten deutschsprachigen Java Forum eine Frage stellst, dann bekommst du erstmal zig unqualifizierte Antworten von Leuten die selber gerade mal seit 2 Wochen programmieren. Wenn Du viel Glück hast und nicht allzu viele von diesen geantworte haben, dann liest sich Deine Frage auch mal einer durch der mehr Ahnung hat und hilft aber das ist echt reine Glücksache.

    Da finde ich das Forum hier deutlich angenehmer. Da bekommt man in der Regel nur Antworten von kompetenten Leuten.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

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

  • MyMattes schrieb:

    Amin Negm-Awad schrieb:

    Ich halte Fragen wie "Typdynamik", "Generics", "Speicherverwaltung" für zentral beim Erlernen einer Programmiersprache und wenn dies die Programmiersprachen unterschiedlich handhaben, ist das nicht unerheblich.

    Für das Erlernen einer Programmiersprache: Ja. Für das Erlernen des Programmierens: Nein. Das eine hat mit dem anderen nur bedingt zu tun, und Programmieren kann ich auch mit Pseudocode lernen.

    Als Anfänger würde ich auf der gewünschten Plattform die Sprache mit der weitesten Verbreitung / dem besten Community-Support wählen. Sonst wird es bei Problemen schnell einsam. Und hier dürfte Swift ObjC doch "etwas" unterlegen sein.

    Mattes
    Wenn du Programmiren auffasst als 2Aneinanderreihung von Befehlen", dann hast du Recht. Nur ist das irgendwo in den 60ern.

    Wenn du programmieren auffasst als Befehlen Struktur geben, hast du Unrecht. Denn ob man ein Generics verwendet oder einen typlosen Container, ob ein Typ zur Übersetzungszeit oder zur Laufzeit bestimmt wird, ist für die Gestaltung deines Codes von zentraler Bedeutung. Ach, das braucht man doch nie? Doch das braucht man für die Struktur seines Programmes von der ersten Zeile Code an.

    Der Unterschied ist die Brauchbarkeit des Codes. Für mich ist das zentral.
    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:

    Wenn du Programmiren auffasst als 2Aneinanderreihung von Befehlen", dann hast du Recht. Nur ist das irgendwo in den 60ern.

    Ich bin noch ein Schritt weiter vorne: "Programmieren lernen" heißt für mich erst einmal, eine diffuse Anforderung in eine strukturierte Problemstellung umzuwandeln, Teilschritte zu identifizieren, und für diese Algorithmen zu entwickeln. Dafür sollte ich mich mit Datenstukturen auskennen, bool'sche Algebra können und wissen, wie man einen Programmablauf steuert. Alles lange vor einer wirklichen Programmiersprache, auch wenn diese zur Verdeutlichung hilfreich ist. Das kann ich auch mit Pseudocode auf Papier lernen.

    Old school? Ja, vielleicht. Aber bei einigen Postings hier hätte der Autor diese Schritte besser nicht übersprungen.

    Wenn es dann um's konkrete Programm schreiben geht, ist die Sprache m. E. Banane: Man wird als Entwickler eh x lernen und die Sprachkonstrukte selber halte ich für die kleinere Hürde gegenüber APIs und Eigenheiten einer Plattform. Einfach pragmatisch entscheiden, und dass wäre bei mir auf OS X / iOS z. Z. eben noch ObjC.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Amin Negm-Awad schrieb:

    Denn ob man ein Generics verwendet oder einen typlosen Container, ob ein Typ zur Übersetzungszeit oder zur Laufzeit bestimmt wird, ist für die Gestaltung deines Codes von zentraler Bedeutung. Ach, das braucht man doch nie? Doch das braucht man für die Struktur seines Programmes von der ersten Zeile Code an.
    Der Unterschied ist die Brauchbarkeit des Codes. Für mich ist das zentral.


    Ich finde es wesentlich übersichtlicher und klarer, wenn die Typen vorab definiert sind. Insbesondere bei späterer Wartung des Codes.

    Aber: Würde ich anders Programmieren, wenn ich swift verwende? Nein. Die Brauchbarkeit bleibt aus meiner Sicht dieselbe. Nur halt nicht von vornherein typsicher (wenn man nur den Quellcode sieht). <- ha, ha. Widerspricht sich das jetzt? Nein, das ist nur die Antwort auf die Frage, ob sich die Struktur des Programmes verändert.

    Abgesehen davon, ist es doch sicher so (wenn Xcode sogar ein Liverendering anbietet), dass Xcode bei jedem weiteren Auftauchen der Variable im Code auf einen Datentyp besteht.(der während der Laufzeit bestimmte Typ)

  • MyMattes schrieb:

    Amin Negm-Awad schrieb:

    Wenn du Programmiren auffasst als 2Aneinanderreihung von Befehlen", dann hast du Recht. Nur ist das irgendwo in den 60ern.

    Ich bin noch ein Schritt weiter vorne: "Programmieren lernen" heißt für mich erst einmal, eine diffuse Anforderung in eine strukturierte Problemstellung umzuwandeln, Teilschritte zu identifizieren, und für diese Algorithmen zu entwickeln. Dafür sollte ich mich mit Datenstukturen auskennen, bool'sche Algebra können und wissen, wie man einen Programmablauf steuert. Alles lange vor einer wirklichen Programmiersprache, auch wenn diese zur Verdeutlichung hilfreich ist. Das kann ich auch mit Pseudocode auf Papier lernen.

    Old school? Ja, vielleicht. Aber bei einigen Postings hier hätte der Autor diese Schritte besser nicht übersprungen.

    Wenn es dann um's konkrete Programm schreiben geht, ist die Sprache m. E. Banane: Man wird als Entwickler eh x lernen und die Sprachkonstrukte selber halte ich für die kleinere Hürde gegenüber APIs und Eigenheiten einer Plattform. Einfach pragmatisch entscheiden, und dass wäre bei mir auf OS X / iOS z. Z. eben noch ObjC.

    Mattes
    Nein, das ist nicht Old-School, sondern verlangt Kenntnis von den Mitteln der konkreten Programmiersprache.
    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"?

  • entwickler schrieb:

    Amin Negm-Awad schrieb:

    Denn ob man ein Generics verwendet oder einen typlosen Container, ob ein Typ zur Übersetzungszeit oder zur Laufzeit bestimmt wird, ist für die Gestaltung deines Codes von zentraler Bedeutung. Ach, das braucht man doch nie? Doch das braucht man für die Struktur seines Programmes von der ersten Zeile Code an.
    Der Unterschied ist die Brauchbarkeit des Codes. Für mich ist das zentral.


    Ich finde es wesentlich übersichtlicher und klarer, wenn die Typen vorab definiert sind. Insbesondere bei späterer Wartung des Codes.

    Aber: Würde ich anders Programmieren, wenn ich swift verwende? Nein. Die Brauchbarkeit bleibt aus meiner Sicht dieselbe. Nur halt nicht von vornherein typsicher (wenn man nur den Quellcode sieht). <- ha, ha. Widerspricht sich das jetzt? Nein, das ist nur die Antwort auf die Frage, ob sich die Struktur des Programmes verändert.

    Abgesehen davon, ist es doch sicher so (wenn Xcode sogar ein Liverendering anbietet), dass Xcode bei jedem weiteren Auftauchen der Variable im Code auf einen Datentyp besteht.(der während der Laufzeit bestimmte Typ)
    Im Falle von Swift zu Objective-C dürften die Konzepte weitestgehend identisch sein. Insofern tut sich da mutmaßlich wirklich wenig. Aber natürlich programmiert man hoffentlich anders in Java als in Objective-C. Und die Ergebnisse, wenn man das nicht tut, sieht man ja hier zuweilen bedauerlicherweise.
    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:

    Aber natürlich programmiert man hoffentlich anders in Java als in Objective-C. Und die Ergebnisse, wenn man das nicht tut, sieht man ja hier zuweilen bedauerlicherweise.

    Weil man keine Ahnung von Objective-C hat? Oder weil man keine Ahnung von der API, den Frameworks und den Best Practices hat?
    AFAIK ist das manuelle Memory Management via -retain und -release kein existenzieller Bestandteil von Objective-C, sondern ein existenzieller Bestandteil der Frameworks Cocoa, Cocoa Touch, NextStep, GNUStep, OpenStep und Artverwandten. 'Nacktes' Objective-C hat das nicht.
    AFAIK sind die im Forum oft zitierte Retain Cycles hingegen kein einzigartiges Phänomen in Objective-C, sondern existieren unter anderem Namen und unter Möglichkeiten der Aushebelung des Garbage Collectors auch in C#, Java und so weiter.

    Sprache vs. Frameworks, API, Pattern, Plattformeigenheiten
    Erstere ist eigentlich immer die kleinere Hürde.
    «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

  • markusschalk schrieb:

    Also ich würde an deiner Stelle mit reinem C beginnen. Dort gibt es keine Objektorientierung und man kann sich rein auf die Logik und Algorithmen stürzen.

    Ich würde mit reinem Maschinencode, echten Bits, beginnen. Da gibt es diesen ganzen Overhead der Hochsprachen nicht, und Du kannst Dich rein auf die Logik und Algorithmen stürzen. +scnr+
    „Meine Komplikation hatte eine Komplikation.“

  • Marco Feltmann schrieb:

    Amin Negm-Awad schrieb:

    Aber natürlich programmiert man hoffentlich anders in Java als in Objective-C. Und die Ergebnisse, wenn man das nicht tut, sieht man ja hier zuweilen bedauerlicherweise.

    Weil man keine Ahnung von Objective-C hat? Oder weil man keine Ahnung von der API, den Frameworks und den Best Practices hat?
    AFAIK ist das manuelle Memory Management via -retain und -release kein existenzieller Bestandteil von Objective-C, sondern ein existenzieller Bestandteil der Frameworks Cocoa, Cocoa Touch, NextStep, GNUStep, OpenStep und Artverwandten. 'Nacktes' Objective-C hat das nicht.
    AFAIK sind die im Forum oft zitierte Retain Cycles hingegen kein einzigartiges Phänomen in Objective-C, sondern existieren unter anderem Namen und unter Möglichkeiten der Aushebelung des Garbage Collectors auch in C#, Java und so weiter.

    Sprache vs. Frameworks, API, Pattern, Plattformeigenheiten
    Erstere ist eigentlich immer die kleinere Hürde.
    Wer redet hier von Speicherverwaltung? Davon abgesehen stimmt das schon nicht mehr, weil clang/ARC, also Compiler und Laufzeitumgebung dies berücksichtigen.

    Ich spreche aber von Generics vs. dynamischer Typisierung, von Exceptions vs. Error-Handling, … Von dem, was wir hier regelmäßig erleben.
    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"?

  • entwickler schrieb:

    Amin Negm-Awad schrieb:

    Denn ob man ein Generics verwendet oder einen typlosen Container, ob ein Typ zur Übersetzungszeit oder zur Laufzeit bestimmt wird, ist für die Gestaltung deines Codes von zentraler Bedeutung. Ach, das braucht man doch nie? Doch das braucht man für die Struktur seines Programmes von der ersten Zeile Code an.
    Der Unterschied ist die Brauchbarkeit des Codes. Für mich ist das zentral.


    Ich finde es wesentlich übersichtlicher und klarer, wenn die Typen vorab definiert sind. Insbesondere bei späterer Wartung des Codes.

    Aber: Würde ich anders Programmieren, wenn ich swift verwende? Nein. Die Brauchbarkeit bleibt aus meiner Sicht dieselbe. Nur halt nicht von vornherein typsicher (wenn man nur den Quellcode sieht). <- ha, ha. Widerspricht sich das jetzt? Nein, das ist nur die Antwort auf die Frage, ob sich die Struktur des Programmes verändert.

    Abgesehen davon, ist es doch sicher so (wenn Xcode sogar ein Liverendering anbietet), dass Xcode bei jedem weiteren Auftauchen der Variable im Code auf einen Datentyp besteht.(der während der Laufzeit bestimmte Typ)
    Ja, ja, bei Generics den Quellcode sehen. Schau dir mal eine Sprache mit Generics an und welche Klimmzüge in der Folge entstehen, damit das immer sicher geht. Da kommt man ohne bestimmte Pattern gar nicht mehr aus.

    Theoretisch ist das verständlicher, weil mehr Informationen vorhanden sind. Praktisch ist das undurchschaubarer, weil Menschen nicht alle Informationen erkennen, merken und im Zusammenhang verarbeiten können.
    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"?

  • MyMattes schrieb:

    Amin Negm-Awad schrieb:

    Nein, das ist nicht Old-School, sondern verlangt Kenntnis von den Mitteln der konkreten Programmiersprache.

    das erklär mal Alan Turing...

    Mattes
    Alan Turing hat nicht Anwendungen für UI mit mehreren Millionen Zeilen Code geschrieben. Und wenn du allen Ernstes jemanden rätst, die Grundlagen bei Turing zu lernen, weil die ja für alle Programmiersprachen gleich sind, verfolgst du offensichtlich das Ziel, dir einen Wettbewerber vom Leib zu halten.

    Dieses Beispiel ist das beste: Du hast Recht, dass das die absoluten Grundlagen sind. Und ich habe Recht, dass damit kein Mensch etwas bei Applikationsentwicklung anfangen kann.
    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:

    markusschalk schrieb:

    Also ich würde an deiner Stelle mit reinem C beginnen. Dort gibt es keine Objektorientierung und man kann sich rein auf die Logik und Algorithmen stürzen.

    Ich würde mit reinem Maschinencode, echten Bits, beginnen. Da gibt es diesen ganzen Overhead der Hochsprachen nicht, und Du kannst Dich rein auf die Logik und Algorithmen stürzen. +scnr+

    Naja, C ist aber keine Hochsprache!

  • Amin Negm-Awad schrieb:

    Ich spreche aber von Generics vs. dynamischer Typisierung, von Exceptions vs. Error-Handling, …


    Nun, genau genommen ist doch alles starr typisiert. Ein int ist immer ein int. Ein float ist selten ein double. Und void* ist immer void*.
    Ob ich jetzt Generics benötige, um Objekte unterschiedlicher Superklassen in ein und dieselbe Collection zu packen, oder ob alle Objekte einer Superklasse entsprechen und daher in die Collection gepackt werden können, ist doch für das theoretische Verständnis der Programmierung zweitrangig. Dies wird erst bei der Umsetzung/Durchführung der Programmierung interessant.

    Ich muss für die Programmierung wissen, dass ich durchaus Objekte eines Supertyps in eine Collection stopfen und aus dieser auch entfernen kann.
    Ich muss für die Programmierung wissen, dass ich unsortierte Collections, indexbasierte Collections und schlüsselbasierte Collections nutzen kann.
    Ich muss für die Programmierung wissen, dass ich im Falle eines Fehlers dafür sorgen muss, dass mein Programm stabil weiter läuft.
    Ich muss für die Programmierung wissen, dass ich im Falle des totalen Blödsinns eine Exception zu werfen habe.

    WIE ich die Objekte eines Supertyps in eine Collection stopfen und daraus loswerden kann ist programmiersprachenabhängig.
    WIE die unsortierten, indexbasierten und schlüsselbasierten Collections im Detail implementiert sind ist programmiersprachenabhängig.
    WANN etwas als totaler Blödsinn oder als Fehler definiert wird ist programmiersprachenabhängig.

    Ich denke, wir sind uns einig, dass es schwierig wird ohne die Nutzung einer Programmiersprache zu programmieren.
    Es ist ja auch alles Andere als einfach ohne die Nutzung einer Sprache zu sprechen.
    Das ist dann mehr so meta.

    Andererseits ist der Rat "Wenn Du für iOS programmieren lernen willst, dann lern programmieren mit Objective-C" faktisch falsch.
    Er müsste korrekt heißen: "Wenn Du für iOS in Objective-C programmieren lernen willst, dann lern programmieren mit Objective-C."

    Amin Negm-Awad schrieb:

    Von dem, was wir hier regelmäßig erleben.

    'Was wir hier regelmäßig erleben.' ist keine Frage, insofern ist ein Fragewort als Anfang des Teilsatzes unbrauchbar. 'Von dem' ist überhaupt kein Satz und damit als Teilsatz unbrauchbar.
    'Ich spreche von den Dingen, die wir hier regelmäßig erleben.'
    Hättest Du dem Herrn Sick mal Beachtung geschenkt. :P
    «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

  • entwickler schrieb:

    Ich finde es wesentlich übersichtlicher und klarer, wenn die Typen vorab definiert sind. Insbesondere bei späterer Wartung des Codes.

    Wer oder was hindert Dich daran, für jede benötigte Collection eine entsprechende Kategorie drum herum zu basteln oder eigene Subklassen zu erstellen?
    Statt [NSArray add:NSObject]; dann halt [NSArray+NSNumber addNumber:NSNumber];

    Dann hast Du Deine 'Wartbarkeit'. Neben den Meckereien des Compilers siehst Du sogar während Du tippst, welcher Typ gerade erwartet wird.
    (Als ob man Code warten könne… Mal eben rasch die NSInteger gegen ein paar Neue wechseln, damit die Laufzeitumgebung schön geschmiert bleibt und nicht verkantet?)
    «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