Cocoa/Obj-C vs andere Sprachen/Frameworks

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Dann nimm als Präfix eben CorePlot und ZermPlot – oder als Namespace ZP.

    Konflikte von Identifiern ändern sich doch nicht dadurch, dass ich stets ein :: davorsetze?

    Natürlich nicht. Aber "ZermPlot" davor zu setzen ist ja gegen die Konvention ;) Und viel zu Tippen, was mir die Namespace-Mechanismen sonst abnehmen.

    Ist es das? Ich habe jetzt nicht nachgeschaut, aber IIRC ist es nicht verboten, lange Präfixe zu verwenden. Es ist einfach unüblich.

    Tipparbeit ist für Sekretärinnen ein Argument, nicht für Programmierer. (Es sei denn, die Tipparbeit macht einen nennenswerten Anteil an der Programmierarbeit aus. Das ist dann aber eher bei Codiersklaven der Fall. Außerdem gibt es ja Name-Completion, also die Lösung des Tippproblems dort, wo sie hingehört: In den Editor, nicht in die Sprachdefinition.)


    zerm schrieb:

    In der einen Antwort bei Stackoverflow (siehe mein Post weiter oben) hat ja auch jemand von @compatibility_alias berichtet, was ich in Objective-C wohl verwenden kann. Damit kann ich dann meine Klassen Zerms_Super_Framework_PlotView nennen, und per Alias das ganze im Code etwa mit ZSFPlotView verwenden. Nur, wie er auch berichtet, muss ich den langen Namen etwa bei NSClassFromString angeben etc. Aber ist ja schonmal ein Anfang ;)

    Nein, das ist ein Ende. "Ich mache mir Abkürzungen über Sprachtricks, damit ich weniger tippen muss" dürfte man dann wohl als den Untergang aller Informatik bezeichnen. Irgendwann sind wir dann so weit, dass ein Schreibmaschinenkurs Bestandteil des Informatikstudiums wird? Bitte 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"?

  • Amin Negm-Awad schrieb:

    Ist es das? Ich habe jetzt nicht nachgeschaut, aber IIRC ist es nicht verboten, lange Präfixe zu verwenden. Es ist einfach unüblich.

    Lucas de Vil schrieb:

    A prefix has a prescribed format. It consists of two or three uppercase letters and does not use underscores or “sub prefixes".

    Sieht für mich nach einem ganz klaren Verbot aus. ;)

    Amin Negm-Awad schrieb:

    Irgendwann sind wir dann so weit, dass ein Schreibmaschinenkurs Bestandteil des Informatikstudiums wird?

    Wenn dafür der Mathescheiß rausfällt bin ich dabei. ^^
    «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

  • Amin Negm-Awad schrieb:

    ramo schrieb:

    Assembler war super, da haben Anwendungen noch zu 100% das getan was der Programmierer wollte, Objective C finde ich aber einen wirklich sehr guten Ersatz für 99,9% der heute geforderten Anwendungen.

    Komisch, ich hing ständig im Logic Analyzer, weil mein Assemblercode nicht das machte, was ich wollte.

    Aber umgekehrt: Wann hat denn dein C-Programm etwas anderes getan als du wolltest.
    Ich habe in dieser Zeit Steuerungen für die Industrie entwickelt ( Hard- und Software ) wo der Einsatz fertiger Systeme ( SPS o.ä. ) aus Gründen des Timings nicht möglich waren. Es war einfach wichtig das Dinge zu der Zeit passieren wo ich es wollte und nicht dann wenn das System dafür Zeit hat und das Ganze im Millisekundenbereich. Da 10 MHz Taktfrequenz damals schon das Maximum waren dauerten diverse Dinge mit Hochsprachen bereits Sekunden. Ein typisches Beispiel waren die ersten prozesssorgesteuerten Telefonanlagen, bei den alten Relaisanlage konnte man abheben und sofort eine Ziffer wählen, bei ersten den mP gesteuerten Anlagen mußte man das Wählzeichen abwarten. Für die ersten elektronischen Verkehrssignalanlagen wurde zur Steuerung ein 4-Bit Prozessorsystem in TTL-Technik aufgebaut,
    da ein SAB-8080 System nicht in der Lage war die zeitkritische Steuerung zu erledigen.

    Aber wie gesagt, heute lassen sich sicher 99,9% aller Probleme mit fertigen Systemen und Sprachen lösen.

  • ramo schrieb:

    Amin Negm-Awad schrieb:

    ramo schrieb:

    Assembler war super, da haben Anwendungen noch zu 100% das getan was der Programmierer wollte, Objective C finde ich aber einen wirklich sehr guten Ersatz für 99,9% der heute geforderten Anwendungen.

    Komisch, ich hing ständig im Logic Analyzer, weil mein Assemblercode nicht das machte, was ich wollte.

    Aber umgekehrt: Wann hat denn dein C-Programm etwas anderes getan als du wolltest.
    Ich habe in dieser Zeit Steuerungen für die Industrie entwickelt ( Hard- und Software ) wo der Einsatz fertiger Systeme ( SPS o.ä. ) aus Gründen des Timings nicht möglich waren. Es war einfach wichtig das Dinge zu der Zeit passieren wo ich es wollte und nicht dann wenn das System dafür Zeit hat und das Ganze im Millisekundenbereich. Da 10 MHz Taktfrequenz damals schon das Maximum waren dauerten diverse Dinge mit Hochsprachen bereits Sekunden. Ein typisches Beispiel waren die ersten prozesssorgesteuerten Telefonanlagen, bei den alten Relaisanlage konnte man abheben und sofort eine Ziffer wählen, bei ersten den mP gesteuerten Anlagen mußte man das Wählzeichen abwarten. Für die ersten elektronischen Verkehrssignalanlagen wurde zur Steuerung ein 4-Bit Prozessorsystem in TTL-Technik aufgebaut,
    da ein SAB-8080 System nicht in der Lage war die zeitkritische Steuerung zu erledigen.

    Aber wie gesagt, heute lassen sich sicher 99,9% aller Probleme mit fertigen Systemen und Sprachen lösen.

    So ist ja auch meine Karriere, auf einem 65xx anstelle eines 8080, also mutmaßlich (weiß nicht mehr genau) ein Stück noch traditionelleres Silizium.

    Ich glaube aber nicht, dass ich als Assemblerprogrammierer bei einem x64_64 noch vorhersagen kann, was genau wann wie lange passiert. Übrigens kann man natürlich auch eine Assembleranalyse mit compiliertem Code vornehmen.
    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"?

  • cuby schrieb:

    Lucas de Vil schrieb:


    Amin Negm-Awad schrieb:

    Irgendwann sind wir dann so weit, dass ein Schreibmaschinenkurs Bestandteil des Informatikstudiums wird?

    Wenn dafür der Mathescheiß rausfällt bin ich dabei. ^^


    Dafür kommt aber der Kurs in Schreibmaschinentechnik! Und das ist alles andere als trivial. Jawoll! :)

    hackaday.com/2010/11/28/wiffle…ital-to-analog-converter/

    Geil! :)

    Kann man darauf auch ein Linux installieren?
    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:

    ramo schrieb:

    Amin Negm-Awad schrieb:

    ramo schrieb:

    Assembler war super, da haben Anwendungen noch zu 100% das getan was der Programmierer wollte, Objective C finde ich aber einen wirklich sehr guten Ersatz für 99,9% der heute geforderten Anwendungen.

    Komisch, ich hing ständig im Logic Analyzer, weil mein Assemblercode nicht das machte, was ich wollte.

    Aber umgekehrt: Wann hat denn dein C-Programm etwas anderes getan als du wolltest.
    Ich habe in dieser Zeit Steuerungen für die Industrie entwickelt ( Hard- und Software ) wo der Einsatz fertiger Systeme ( SPS o.ä. ) aus Gründen des Timings nicht möglich waren. Es war einfach wichtig das Dinge zu der Zeit passieren wo ich es wollte und nicht dann wenn das System dafür Zeit hat und das Ganze im Millisekundenbereich. Da 10 MHz Taktfrequenz damals schon das Maximum waren dauerten diverse Dinge mit Hochsprachen bereits Sekunden. Ein typisches Beispiel waren die ersten prozesssorgesteuerten Telefonanlagen, bei den alten Relaisanlage konnte man abheben und sofort eine Ziffer wählen, bei ersten den mP gesteuerten Anlagen mußte man das Wählzeichen abwarten. Für die ersten elektronischen Verkehrssignalanlagen wurde zur Steuerung ein 4-Bit Prozessorsystem in TTL-Technik aufgebaut,
    da ein SAB-8080 System nicht in der Lage war die zeitkritische Steuerung zu erledigen.

    Aber wie gesagt, heute lassen sich sicher 99,9% aller Probleme mit fertigen Systemen und Sprachen lösen.

    So ist ja auch meine Karriere, auf einem 65xx anstelle eines 8080, also mutmaßlich (weiß nicht mehr genau) ein Stück noch traditionelleres Silizium.

    Ich glaube aber nicht, dass ich als Assemblerprogrammierer bei einem x64_64 noch vorhersagen kann, was genau wann wie lange passiert. Übrigens kann man natürlich auch eine Assembleranalyse mit compiliertem Code vornehmen.

    x64_64 oder so - da hast du vollkommen recht, aber ich glaube generell ein Problem wenn auf fertigen Systemen zeitkritische Aufgaben gelöst werden müssen.
    65xx und sein Befehlssatz war das beste Ding in dieser Zeit, überhaupt dann die statische Version mit 4MHz, das war Power !!
    Mit 256 Befehlen war alles lösbar - eben ein starkes Stück - aber das war einmal und Objectiv -C finde ich gleich SUPER !

  • cuby schrieb:

    Lucas de Vil schrieb:


    Amin Negm-Awad schrieb:

    Irgendwann sind wir dann so weit, dass ein Schreibmaschinenkurs Bestandteil des Informatikstudiums wird?

    Wenn dafür der Mathescheiß rausfällt bin ich dabei. ^^


    Dafür kommt aber der Kurs in Schreibmaschinentechnik! Und das ist alles andere als trivial. Jawoll! :)

    hackaday.com/2010/11/28/wiffle…ital-to-analog-converter/

    Kranke Scheiße. 8o
    Großartig. :)
    «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

  • Amin Negm-Awad schrieb:


    So ist ja auch meine Karriere, auf einem 65xx anstelle eines 8080, also mutmaßlich (weiß nicht mehr genau) ein Stück noch traditionelleres Silizium.


    Da war intel ausnahmsweise mal früher - der 8080 kam 1974 raus, der 6502 1975...

    Amin Negm-Awad schrieb:

    Ich glaube aber nicht, dass ich als Assemblerprogrammierer bei einem x64_64 noch vorhersagen kann, was genau wann wie lange passiert. Übrigens kann man natürlich auch eine Assembleranalyse mit compiliertem Code vornehmen.


    Das funktioniert schon auf viel trivialeren Architekturen nicht - Pipelines, Caches, Buskonflikte, virtueller Speicher und so sind ziemlich nervig für eine Zeitanalyse. Daher kann man im allgemeinen Fall nur eine Worst-Case-Abschätzung geben (wenn überhaupt). Details dazu (ist hier bei uns ein Forschungsschwerpunkt), wen's interessiert, gibt's unter de.wikipedia.org/wiki/Maximale_Laufzeit.

  • Lucas de Vil schrieb:

    Übrigens: kennst du die Kurzzeichen, für die der Mechanismus da wäre?
    NS (namespace: NextStep)
    UI (namespace: UserInterface)
    CG (namespace: CoreGraphics)
    CA (namespace: CoreAnimation)
    CF (namespace: CoreFoundation)
    Irgend wie verstehst Du das Grundproblem nicht. Ein ganz einfaches Beispiel für Dich, daß Du hoffentlich nachvollziehen kannst. Es gab mal eine Firma Netscape, die benutze für die eigenen Frameworks ebenfalls NS als Qualifizierung. Und so abwegig war/ist der Gedanke nicht gleichzeitig Netscape und Nextstep Code in der eigenen Applikation verwenden zu wollen. In solchen Fällen ist es nicht ausgeschlossen, daß es zu Namenskollisionen kommt.

    Mit Namesräumen löst man das Problem einfach, da man z.B. NX für Nextstep (so hieß es übrigens früher) nutzen kann und NS für Netscape. Ohne Namensräume hat man die A-Karte gezogen und muß einen Wrapper schreiben, der es ermöglicht beide Namensräume in einer Sourcedatei zu nutzen. Namensräume sind ein sehr sinnvolles Mittel solche Kollisionen zu unterbinden. Dir mag dies mangels eigener Erfahrung nicht einleuchten, es mag auch sein, daß Apple alle Frameworks konsistent halten kann. Wer aber garantiert, daß dies auch mit allen Frameworks aus der Hand dritter so ist? Alle Apple Frameworks zusammen sehr recht umfangreich, aber sie sind nicht für alle Anwendungen ausreichend, so daß man Frameworks aus der Hand dritter benötigt, wenn man sich unnötige Arbeit ersparen will. Und in solchen Fällen werden solche Kollisionen wahrscheinlich.

  • tjp schrieb:

    Lucas de Vil schrieb:

    Übrigens: kennst du die Kurzzeichen, für die der Mechanismus da wäre?
    NS (namespace: NextStep)
    UI (namespace: UserInterface)
    CG (namespace: CoreGraphics)
    CA (namespace: CoreAnimation)
    CF (namespace: CoreFoundation)
    Irgend wie verstehst Du das Grundproblem nicht. Ein ganz einfaches Beispiel für Dich, daß Du hoffentlich nachvollziehen kannst. Es gab mal eine Firma Netscape, die benutze für die eigenen Frameworks ebenfalls NS als Qualifizierung. Und so abwegig war/ist der Gedanke nicht gleichzeitig Netscape und Nextstep Code in der eigenen Applikation verwenden zu wollen. In solchen Fällen ist es nicht ausgeschlossen, daß es zu Namenskollisionen kommt.

    Irgendwie sehe ich da gar kein Problem: Hat Netscape jemals seinen Browser dafür entwickelt.
    Es gab doch immer nur den einen Browser, wie Du Dich sicherlich erinnerst.

    tjp schrieb:


    Mit Namesräumen löst man das Problem einfach, da man z.B. NX für Nextstep (so hieß es übrigens früher) nutzen kann und NS für Netscape. Ohne Namensräume hat man die A-Karte gezogen und muß einen Wrapper schreiben, der es ermöglicht beide Namensräume in einer Sourcedatei zu nutzen. Namensräume sind ein sehr sinnvolles Mittel solche Kollisionen zu unterbinden. Dir mag dies mangels eigener Erfahrung nicht einleuchten, es mag auch sein, daß Apple alle Frameworks konsistent halten kann. Wer aber garantiert, daß dies auch mit allen Frameworks aus der Hand dritter so ist? Alle Apple Frameworks zusammen sehr recht umfangreich, aber sie sind nicht für alle Anwendungen ausreichend, so daß man Frameworks aus der Hand dritter benötigt, wenn man sich unnötige Arbeit ersparen will. Und in solchen Fällen werden solche Kollisionen wahrscheinlich.

    Ja, da gebe ich Dir Recht: Wer mag das alles garantieren?
    Ich glaube zudem, dass Namensräume noch zu kurz greifen. Wir sollten uns eine Einrichtung schaffen, die Kürzel global verwaltet, etwa die GINA (Global International NameSpace Authority).
    Und uns gegen Garantieverlust versichert.
    I would be embarrassed if they did not spy on me.

  • longW schrieb:

    Es gab doch immer nur den einen Browser, wie Du Dich sicherlich erinnerst.
    Netscape hatte eine ganze Reihe von kommerziellen Produkten (Directory-Server, Webserver, ...) angeboten, desweiteren freie Frameworks für das Enterprise Computing. Unter anderem gab es von denen eine LDAP-Client Library, damit man leicht LDAP in den eigenen Applikationen verwenden konnte. OpenLDAP entstand erst später. Mittlerweile sind die ehemaligen Netscape Produkte über den Umweg SUN bei Oracle gelandet.

  • tjp schrieb:

    longW schrieb:

    Es gab doch immer nur den einen Browser, wie Du Dich sicherlich erinnerst.
    Netscape hatte eine ganze Reihe von kommerziellen Produkten (Directory-Server, Webserver, ...) angeboten, desweiteren freie Frameworks für das Enterprise Computing. Unter anderem gab es von denen eine LDAP-Client Library, damit man leicht LDAP in den eigenen Applikationen verwenden konnte. OpenLDAP entstand erst später. Mittlerweile sind die ehemaligen Netscape Produkte über den Umweg SUN bei Oracle gelandet.


    Und?
    Hat sich damals jemand über den fehlenden Namensraum beschwert?
    I would be embarrassed if they did not spy on me.

  • Namensräume für Objective-C? 4
    1.  
      Kürzel vor dem Namen reichen immer (2) 50%
    2.  
      Ein zusätzlicher Mechanismus für Sonderfälle wäre wünschenswert (0) 0%
    3.  
      Echte Namespaces wären sehr sinnvoll (1) 25%
    4.  
      Nur echte Namespaces garantieren sauberen Code und alles andere ist Mist (1) 25%
    Stimmen wir doch ab! :)
    ♥C++

  • longW schrieb:

    Und?
    Hat sich damals jemand über den fehlenden Namensraum beschwert?
    Ich finde es immer wieder erbauend, daß es Menschen gibt, die von ihren eigenen Ansprüchen darauf schließen, daß niemand darüber hinausgehende Anforderungen haben könnte. Halten wir fest, daß Du und Lucas bisher nicht die Notwendigkeit eines solchen Sprachfeatures gesehen habt.

    Allerdings ist auch zu verzeichnen, daß so ziemlich jede moderne Programmiersprache dieses Features besitzt. Warum ist das wohl so?

  • tjp schrieb:

    longW schrieb:

    Und?
    Hat sich damals jemand über den fehlenden Namensraum beschwert?
    Ich finde es immer wieder erbauend, daß es Menschen gibt, die von ihren eigenen Ansprüchen darauf schließen, daß niemand darüber hinausgehende Anforderungen haben könnte.

    Stimmt, könnte sein. Deshalb hört man auch hin und wieder Fragen von Leuten, die das suchen. Erstaunlicherweise sind das aber Leute, die gerade erst angefangen haben mit Obejctive-C. Das kann natürlich ein Zufall sein …

    Aber wieso nennst du uns nicht einfach die Anforderung, die jemand haben könnte?

    tjp schrieb:

    Halten wir fest, daß Du und Lucas bisher nicht die Notwendigkeit eines solchen Sprachfeatures gesehen habt.

    Sind das wirklich die einzigen?

    Halten wir doch lieber fest, dass du dir vorstellen könntest, dass es eine Person gibt, die eine Anforderung haben könnte, die sich mit Namespaces lösen lässt.


    tjp schrieb:

    Allerdings ist auch zu verzeichnen, daß so ziemlich jede moderne Programmiersprache dieses Features besitzt. Warum ist das wohl so?

    Das muss so sein wie beim statischen Binding.
    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:

    Stimmt, könnte sein. Deshalb hört man auch hin und wieder Fragen von Leuten, die das suchen. Erstaunlicherweise sind das aber Leute, die gerade erst angefangen haben mit Objective-C. Das kann natürlich ein Zufall sein …
    Brauchst mal wieder Nachhilfe in Logik!?
    Natürlich weiß ein jeder der die Sprache kennt, daß sie keine Namensräume hat, daher wird er auch nicht mehr danach fragen. Also mal wieder ein Nullargument von dir - wie es nicht anders zu erwarten war.
    Sind das wirklich die einzigen?

    Das habe ich nicht behauptet. Allerdings haben sich beide in diesem Thread hervorgetan, daher das explizite nennen der beiden.
    Das muss so sein wie beim statischen Binding.
    Wie fast immer Thema verfehlt! Python hat dynamisches Dispatching und es hat Namensräume, C++ hatte in der vor ISO Zeit keine Namensräume. Es finden sich sicherlich noch viele Beispiele für jede Kombination. Es besteht also keinerlei Zusammenhang zwischen der Art des Dispatchings und Namensräumen.

  • tjp schrieb:

    Das habe ich nicht behauptet. Allerdings haben sich beide in diesem Thread hervorgetan, daher das explizite nennen der beiden.


    Du meinst wir beide waren nicht artig und deswegen müssen wir nachsitzen, oder wie soll ich das verstehen?
    Beantworte bitte die Frage, auch wenn es Dir schwer fällt.
    I would be embarrassed if they did not spy on me.

  • longW schrieb:

    Ich verstehe, warum Du Fragen nicht beantworten kannst.

    Wenn Du so offen bist, über die Gründe etwas erfahren zu wollen, dann tipp einfach mal "why namespaces" in die Websuchemaschine Deiner Präferenz ein. Ausreichend Links finden sich zu diesem Thema.

    Falls Literaturempfehlungen genehm sind:
    "Programming in the Large", Chapter 20, Software Engineering with Ada, 3rd Ed., Grady Booch
    Large-Scale C++ Software Design, John Lakos

    Objektorientierte Analyse und Design, Grady Booch (das ist ein Standardwerk)
    Hier wird lang und breit über die Modularisierung und der Namenssichtbarkeit diskutiert.