Buch: Objective-C und Cocoa 2

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

  • oh mein Gott... hoffentlich bekomme ich das richtige - ansonsten muss ich es leider zurückschicken und hoffen das sich die Verwirrung bald legt und ich ein "richtiges" Exemplar bekommen kann.

    *grummel*
    Reimar
    Ich glaube ans Schlimmste und hoffe aufs Beste

  • Original von Tom9811
    Es muss ja kein einmaliges Ereignis bleiben. Ich denke ohnehin über so etwas wie einer festen Cocoa-Runde nach, die sich etwa alle zwei Monate trifft und ein Thema ausdiskutiert.


    Gute Idee! Der Kölner Cocoa-Stammtisch.

  • Original von Tom9811
    Das ist derzeit eine ziemliche Katastrophe bei amazon. Ich wäre mit der Bestellung derzeit vorsichtig. Ich habe den Verleger auch schon darauf hingewiesen.
    +++
    ISBN: 978-3-908497-42-4


    Suche ich nach der ISBN bei Amazon komme ich zu dem nicht mehr erhältlichem Buch, kann also derzeit gar nicht das richtige bestellen. :/

  • Original von chartus
    Original von Tom9811
    Hey, ich komme von der HW und ASM-Schiene. Mir sind keine Register einer CPU fremd. Dennoch halte ich es weder für männlich, noch für sinnvoll, bei einem Aufruf einer Methode ein bestimmtes Verhalten als "Basiswissen" zu kennen. *Das* geht nämlich definitiv in die Hose.

    ich meine man sollte schon die komplette sprachgramatik von Objective C kennen und das bedeutet nun mal auch C"


    Sollte man das nicht generalisieren und fragen, ob man dann auch C lernen muss, wenn man mit Ruby die Cocoa Bindings nutzt?

    Daniel Jalkut (der Entwickler von FlexTime) fragt heute in seinem Blog, ob "C das neue Assembler" werden wird:
    red-sweater.com/blog/278/c-is-the-new-assembly

    He (John Gruber) suggests that a typical developer will write everything in Ruby or Python, and then do performance testing. Anything that needs a speed-up can be redone in Objective-C. You know, that “slow” dynamic variant of C :)

    This analysis is foreboding, because it’s exactly what programmers have always done when they switched to a higher level language. 10 years ago a programmer would be more likely to “switch to assembly” for a much-needed performance boost. Has it come to this? Are we moving to a higher plane? If you’re like me, you’ve probably become quite comfortable in your Objective-C universe, and somewhat dismissive of the scripting languages as they begin to encroach on our holy ground. But we run the risk of being like those losers who still insist on programming everything in assembly, while the higher-level code would be just as fast and easier to maintain.

    Is C is the new assembly?

  • Hehehehehe, ers pricht mir so etwas von aus dem Herzen. Vor einiger Zeit hatten wir einen Thread, indem es darum ging, dass C so viel schneller sei und die Grundlage überhaupt und Basiswissen und haste nicht gesehen.

    Ich erwiderte damals, dass dies natürlich Quatsch sei, weil C totaler high-level-Convienence-Krempel sei und überhaupt Asm das einzig Wahre und sooo viel schneller und total Grundlage. Überhaupt bin ich der Meinung, dass man eine CPU gatterweise verstanden haben muss, um anstänidge Textverarbeitungsapps in Objective-C zu schreiben. Wie soll das sonst gehen? (Andererseits könnte man sich mit Begriffen wie Kapselung und Information Hiding beschäftigen.)

    Auch das Argument, dass man heute nicht Newbies vorwerfen kann, mit Objective-C einzusteigen, weil C soviel KEWLER sei, erinnerte mich an meine Jugend, als man nicht mit C einsteigen durfte, weil Asm soviel KEWLER war. Und hey, ich habe in den PROM-Simulator noch Maschinencode beim Debuggen eingegeben. DAS WAR MAL KEWL!!!!!!!!!!!!!

    Es ist wie in der Gesellschaft: Die ältere Generation mäkelt an der jüngeren herum. Beide haben Unrecht, weil sie nur einen winzigen Zeitpunkt auus der Geschichte bemerken und dies für das alles Heilsbringende halten.

    Goethe spricht über diese "Arroganz der Generation" übrigens im Faust. Also auch hier gilt: Alls schon dagewesen.

    BTW: Nett, dass du wieder mal hier bist.
    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"?

  • Original von Tom9811
    Es ist wie in der Gesellschaft: Die ältere Generation mäkelt an der jüngeren herum. Beide haben Unrecht, weil sie nur einen winzigen Zeitpunkt auus der Geschichte bemerken und dies für das alles Heilsbringende halten.


    Da sagst Du es doch selber: man muss beide Seiten betrachten.

    Jemand, der mit Cocoa/Objc "normale" Applikationen bauen möchte, braucht mit Sicherheit kein C, Inline-Assembler oder sonstwas. Dummerweise deckt Cocoa aber nur eine Teilmenge von dem ab, was man mit dem darunterliegenden Betriebssystem anstellen kann. Und spätestens wenn ich Dinge machen will, die mit Cocoa nicht gehen, muss ich auf C zurückgreifen, um das API des OS zu verstehen.
    Ja, ich kann auch ohne C-Wissen Funktionen des OS nutzen (unter Umgehung con Cocoa). Aber spätestens wenn Software professionellen Ansprüchen genügen soll und dann mangels Wissen einfach irgendwelche C-Aufrufe getätigt werden (-> printf), ist das Kind in den Brunnen gefallen.

    Ich habe erst letztlich wieder ein Code-Audit für eine Software gemacht, bei der wirklich alles falsch gemacht wurde, was man falsch machen kann. Wo kommt das denn her? Daher, dass die Leute sich blind auf Dinge verlassen, die sie nicht verstehen.

    Die Wahrheit liegt doch (wie immer) irgendwo in der Mitte. Wenn ich alles das, was ich machen will, mit Cocoa/Objc machen kann, dann gibt es in der Tat keinen Grund, dass ich mich mit anderen Dingen beschäftigen muss. Aber sobald ich über das Framework hinaus arbeiten muss, muss ich wissen was passiert.

    Dass es einem Cocoa-Programmierer hingegen egal sein kann wie NSFileHandle Dateizugriffe intern kapselt, sehe ich mittlerweile genauso wie Du. Man lernt halt nie aus. ;)

  • Na ja, dein Teilmengenargument kommt immer ohne Beispiel. Ich denke hier nur an NSThread oder NSFileWrapper oder NSCoder oder NSTask usw. Häufig genug rührt es nur daher, dass man etwas anderes besser kennt. (Das ist ja auch ganz natürlich, wenn man damit jahrelang gearbeitet hat und umgekehrt bedenkt, dass Cocoa riesig ist. Das meine ich mit ddem Generationenproblem. Das hängt ja häufig auch daran, dass die Elterngeneration einfach etwas anderes gewohnt ist. Und jeder Mensch ist bestrebt, *seine* Erfarhungen der Weltsicht zu Grunde zu lagen. Auch völlig natürliches Verhalten.) Siehe hierzu auch letzte Anmerkung.

    Aber ich will auf etwas anderes heraus:
    Die Benutzung einer C-Lib, die die BS-Ebene wrappt, macht aus einem Objective-C-Programm kein C-Programm. Funktionen sind Bestandteil von Objective-C. Sie sind nicht Bestandteil von C und C ist Bestandteil von Objective-C. Oder anders formuliert: Wenn ich alleine Objective-C lerne, lerne ich *da mit drin* diese Lib-Funktionen.

    Und das ist keine Korinthenkackerei. Denn es gibt zahlreiche Dinge in C, die ich in Objective-C tatsächlich nie benötige. Würde ich also zunächst C lernen, würde ich diese Dinge erlernen, die ich nie brauche. Wieso?

    Und noch etwas viel Wichtigeres: Ein C-Programm ist nicht ein Programm, das C-Funktionen benutzt. Ein C-Programm ist ein Programm, welches so wie C denkt. Ein Objective-C.Programm ist ein Programm, welches wie Objective-C denkt. Und das schiebst du nicht hin und her durch Verwendung einer Funktion irgendwo. Damit änderst du ja nicht die Denke.

    Ich erlebe es immer wieder in Diskussionen, dass der Unterschied an irgendwlechen Syntax-Kriimskrams oder die Verwendung einer bestimmten Funktion festgemacht wird. Das beschreibt *nicht* die Sprache. Die Denke beschreibt die Sprache.

    Nicht verstehen:
    Klar machen die Leute Dinge falsch, die sie nicht verstehen. Deshalb sollten sie Objective-C lernen, um Objective-C zu verstehen. Daher rühren nämlich viele Fehler in Objective-C: Die Leuite denken, es sei C mit ein paar OOP-Erweiterungen. SChmarren: Es ist ein völlig anderes Konzept von Scratch.

    Kapseln und so:
    In der Tat schreibe ich mir in soclhen Fällen immer eine eigene Kapsel als Wrapper. Dannn ist diie C-Funktion irgendwie weg aus meinem Scope. Puuuh, sage ich da, puuuh, bin ich das los. ;)
    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"?

  • Original von Tom9811
    Und das ist keine Korinthenkackerei. Denn es gibt zahlreiche Dinge in C, die ich in Objective-C tatsächlich nie benötige. Würde ich also zunächst C lernen, würde ich diese Dinge erlernen, die ich nie brauche. Wieso?


    Hättest Du mein Posting aufmerksam gelesen ...

    Es geht nicht um "C-Programm oder nicht", sondern darum, dass man in der Regel immer wieder in die Verlegenheit kommen wird, C zu verwenden, auch wenn es nur Lib-Calls oder Syscalls sind. Und alleine dabei kann man schon ziemlich viel Scheisse bauen wenn man nicht weiß, welche Besonderheiten C hat. Nein, man muss nicht C flüssig sprechen können, aber man sollte zumindest grundsätzlich wissen, was die besonderen Eigenschaften von C sind. Warum? Steht im Vorposting. Und was NTThread, etc. angeht, verweise ich ebenfalls auf den letzten Absatz meines letzten Postings. ;)

  • Original von Tom9811
    In der Tat schreibe ich mir in soclhen Fällen immer eine eigene Kapsel als Wrapper. Dannn ist diie C-Funktion irgendwie weg aus meinem Scope. Puuuh, sage ich da, puuuh, bin ich das los. ;)


    Und wieso kannst Du einen Wrapper schreiben? Weil Du weisst, wie Du das C-Foo in eine vernünftige Sprache packen kannst. Schwierig, wenn man das aber nicht versteht, weil ... muss man ja nicht wissen. ;)

  • Nein, nein, ich habe deinen Beitrag schon gelesen. Ich habe auch dazu geantwortet, möglicherweise verspätet, weil ich meinen Beitrag noch verändert habe.

    Also hierzu noch einmal kurz: Die Verwendung eines Lib-Calls in einem Objective-C-Programm macht daraus nicht ein C-Programm. Es ist die ganz n0ormale Sprachverwendung in der Syntax von Objecti ve-C und -wichtiger- immer noch mit der Denke. Denn ein Call ist ersteinmal neutral. (Eine Nachricht wäre schöner.)

    Ein C-Programmm würde daraus, wenn du deine App so strukturierst wie ein C-Programm. Das machst du aber nicht durch diesen oder jenen Call.
    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"?

  • Ich kann und muss einen Wrapper schreiben, wenn

    a) Das Ding nicht schon da ist.
    b) Ich den Lib-Call kenne.

    Für beides muss ich nicht C beherrschen. Ich muss einen Lib-Call beherrschen.

    Und ich schreibe ihn, damit mein Programm die Struktur, das Konzept einer Objective-C-Applikation behält. C-Style wäre es, eine Funktion dafür zu schreiben, die einen Kontext als Pointer bekommt. Das programmiere ich gerade nicht.
    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"?

  • Original von Tom9811
    Nein, nein, ich habe deinen Beitrag schon gelesen. Ich habe auch dazu geantwortet, möglicherweise verspätet, weil ich meinen Beitrag noch verändert habe.

    Also hierzu noch einmal kurz: Die Verwendung eines Lib-Calls in einem Objective-C-Programm macht daraus nicht ein C-Programm. Es ist die ganz n0ormale Sprachverwendung in der Syntax von Objecti ve-C und -wichtiger- immer noch mit der Denke. Denn ein Call ist ersteinmal neutral. (Eine Nachricht wäre schöner.)

    Ein C-Programmm würde daraus, wenn du deine App so strukturierst wie ein C-Programm. Das machst du aber nicht durch diesen oder jenen Call.


    Hättest Du mein Posting aufmerksam gelesen ...

    "Es geht nicht um "C-Programm oder nicht", sondern darum ..."

  • Original von Tom9811
    Für beides muss ich nicht C beherrschen. Ich muss einen Lib-Call beherrschen.


    Peng! -> man 3 printf. Ah, ist ja einfach. Schnell mal'n Wrapper gebaut. Und schon hast Du die Probleme aus der C-Ebene nach Objc gehievt. DAS ist die miese Art von Programmierung, die mir mein Einkommen sichert. q.e.d.