Das leidige Thema: Objective-C und Redmonds Fenster

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

  • Original von tjp
    Original von longW
    Und deswegen reicht es bei Cocoa aus, die eine Dokumentation von Apple zu lesen. Die gilt für alle von Apple verfügbar gemachten Implementierungen.

    Ja wirklich? Seit wann kann man ein beliebiges Cocoa Programm ohne Änderungen am Sourcecode direkt gegen GNUstep compilieren?

    Du liest zwar viel, aber nicht genau genug. Habe ich behauptet, das ich Quellen nicht ändern möchte?
    I would be embarrassed if they did not spy on me.
  • Original von longW
    Du liest zwar viel, aber nicht genau genug. Habe ich behauptet, das ich Quellen nicht ändern möchte?

    Wenn ich mich mal einmischen darf: so wie ich die Sache sehe, geht die gesamte Diskussion um das Fehlen einer Standardbibliothek einzig und allein darum, dass ich egal für welches Betriebssystem grundlegende Komponenten wie beispielsweise Maps/Dictionarys und Strings ohne eine einzige Anpassung am Code nutzen kann.

    STL macht es da einfach, weil der ganze Krams da drin zusammengefasst wurde und es einfach mit C++ fest verwoben ausgeliefert wird. Umstellungsprobleme gibt es dann nur wenn irgendwelche externen Bibliotheken geändert wurden. Dennoch sind Maps und Strings immer identisch gegeben.

    Cocoa/GNUStep macht es etwas komplizierter, da hier wirklich alles drin hängt. Ich kann meine Anwendung nicht in Core-ObjC klöppeln und mich dann für die GUI für ein Framework 'Cocoa', 'GNUStep' oder 'QuantumSTEP' entscheiden. Hier hängt alles ineinander zusammen, nicht bloß die Kernfunktionalität. Selbst wenn hier NSString, NSArray und NSDictionary immer gegeben sind, so muss ich zumindest die Imports anpassen.

    Dass tjp und -Nuke- keine der existenten CoreFrameworks wie "MetaObjects" oder "StandardLib" nutzen wollen haben sie mit der Existenzsicherheit, Stabilität und Aktualität standardisierter Bibliotheken begründet.

    Mir persönlich isses wurscht, da ich nach wie vor der Meinung bin Plattformunabhängigkeit in Bezug auf das Betriebssystem hilft zwar dem Entwickler, schadet aber dem Anwender.

    tjp/-Nuke- Hab ich das einigermaßen treffend zusammengefasst?
    «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
  • Original von Lucas de Vil
    Mir persönlich isses wurscht, da ich nach wie vor der Meinung bin Plattformunabhängigkeit in Bezug auf das Betriebssystem hilft zwar dem Entwickler, schadet aber dem Anwender.

    Sehe ich nicht so. Wenn man vollständig auf den kleineren (Mac, Linux) Markt abziehlt und da auch was erreichen will, dann muss man natürlich schon alles anpassen, damit es sich wirklich "nativ" sich anfühlt.
    Andererseits muss ich aber sagen, dass bei den tausenden kleinen Projekten bzw. "Nischenprogrammen" mir es lieber wäre, wenn die auch einfach direkt auf dem Mac laufen würden - egal wie "Windows" sie noch aussehen. Wenn Cross-Plattform kein deutlichen Mehraufwand bedeutet, warum nicht?
    C++
  • Original von Lucas de Vil
    Wenn ich mich mal einmischen darf: so wie ich die Sache sehe, geht die gesamte Diskussion um das Fehlen einer Standardbibliothek einzig und allein darum, dass ich egal für welches Betriebssystem grundlegende Komponenten wie beispielsweise Maps/Dictionarys und Strings ohne eine einzige Anpassung am Code nutzen kann.

    Soweit richtig

    Original von Lucas de Vil
    STL macht es da einfach, weil der ganze Krams da drin zusammengefasst wurde und es einfach mit C++ fest verwoben ausgeliefert wird. Umstellungsprobleme gibt es dann nur wenn irgendwelche externen Bibliotheken geändert wurden. Dennoch sind Maps und Strings immer identisch gegeben.

    Streiche STL und setze C++ Standard Library, die C++ Standard Library erhält deutlich mehr Funktionalität als nur die übernommenen Teile der STL.

    Original von Lucas de Vil
    Cocoa/GNUStep macht es etwas komplizierter, da hier wirklich alles drin hängt. Ich kann meine Anwendung nicht in Core-ObjC klöppeln und mich dann für die GUI für ein Framework 'Cocoa', 'GNUStep' oder 'QuantumSTEP' entscheiden. Hier hängt alles ineinander zusammen, nicht bloß die Kernfunktionalität. Selbst wenn hier NSString, NSArray und NSDictionary immer gegeben sind, so muss ich zumindest die Imports anpassen.

    Nein
    1. Eine Standard Library ist kein Framework zur Applikationsentwicklung
    2. Es gab früher einmal Openstep for Mach x86 und 68k (Nachfolger von NEXTSTEP für HP-PA, SPARC, 68k und x86), Openstep for Windows und Openstep for Solaris.
      [/list=1]
      Früher war es möglich einmal ein Openstep Programm zu entwickeln und auf alle Plattformen zu portieren durch ein simplen Recompile. Bis auf die Windows Version sah auch alles immer gleich aus und funktionierte auch gleich. Auch die Solaris Version sah und fühlte sich nicht anders an als echtes Openstep for Mach. Man konnte beim Einloggen sich für den OPEN LOOK, CDE oder Openstep Desktop entscheiden. Das alles war zwar kommerziell, aber für den zahlungsbereiten Profi gab es Möglichkeiten die Anwendungen einfach und kostengünstig auf allen Plattformen anzubieten. Apple hat diese Möglichkeiten entsorgt.
      GNUstep und Cocoa sind nun einmal nicht identisch, sondern GNUstep ist ein freier Clone von Cocoa und hinkt daher dem Original immer hinterher. Man weiß daher nie mit Sicherheit was denn nun wirklich zu 100% funktioniert. Bestenfalls kann man unter GNUstep Software entwickeln und nach Cocoa portieren. Aber spätestens bei Multimedia Ansätzen kann man auch das Vergessen.

      Das alles wäre noch nicht einmal so schlimm, wenn Cocoa sich besser mit anderen Programmiersprachen vertragen würde. Nur das ist nicht der Fall. So wird es schwierig um einen bestehenden Applikationskern ein GUI für MacOS X zu bauen, mit Carbon war das sehr viel einfacher. Das macht die Portierung von Software auf MacOS X zusätzlich teurer. Objective-C++ ist wirklich keine Hilfe, da es zu einem anachronistischen C++ Programmierstil zwingt der etwa auf dem Niveau von C with Classes ist.

      [quote]Original von Lucas de Vil
      Mir persönlich isses wurscht, da ich nach wie vor der Meinung bin Plattformunabhängigkeit in Bezug auf das Betriebssystem hilft zwar dem Entwickler, schadet aber dem Anwender.[/quote]
      Plattformunabhängigkeit verringert drastisch den Wartungsaufwand und damit die Entwicklungskosten, und wenn man den Applikationskern isolieren kann fällt das im GUI noch nicht einmal auf.
  • Original von tjp
    Original von Amin Negm-Awad
    Natürlich gibt es kein Dokument. Und? Das heißt doch nicht, dass ich erblinde. Es geht auch nicht um alle verfügbaren Fälle. Es geht um GNUStep. Wieso baust du dir eine Situation, die nicht existiert?

    So existiert doch! Eine beliebige Cocoa Anwendungen ist nicht portabel, da GNUstep eben nicht 100% der Cocoa Funktionalität abdeckt. Wenn Du das nicht siehst bist Du wirklich blind.

    Keine Anwendung, die eine reale Implementierung eines Framework / einer Sprache vollständig ausnutzt ist portabel. Auch bei C++-Compilern – von der STL muss ich gar nicht anfangen – ist es so, dass jeder sein Extra-Süppchen oben drauf packt. Wenn ich das nutze, kann ich genau so wenig portieren. Anwendungen ohnehin nicht. Dazu reicht der Standard nicht aus.

    Wenn du das nicht siehst, bist du wirklich blind.

    Und nicht anders verhält sich das bei GNUStep und Cocoa: Wenn ich Spezialitäten nutze, ist es nicht mehr portabel. Die Gemeinsamkeiten von GNUstep/Cocoa übersteigen allerdings den Standard von C++ einschließlich STL bei Weitem. Die verlässliche Basis ist also *wesentlich* größer.

    Wenn du das nicht siehst, bist du wirklich blind.
    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 tjp
    Original von longW
    Und deswegen reicht es bei Cocoa aus, die eine Dokumentation von Apple zu lesen. Die gilt für alle von Apple verfügbar gemachten Implementierungen.

    Ja wirklich? Seit wann kann man ein beliebiges Cocoa Programm ohne Änderungen am Sourcecode direkt gegen GNUstep compilieren?

    Kann man ein beliebiges auf dem gcc kompilierbares C++-Programm gegen VC++ kompilieren?
    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 tjp
    Original von Lucas de Vil
    Wenn ich mich mal einmischen darf: so wie ich die Sache sehe, geht die gesamte Diskussion um das Fehlen einer Standardbibliothek einzig und allein darum, dass ich egal für welches Betriebssystem grundlegende Komponenten wie beispielsweise Maps/Dictionarys und Strings ohne eine einzige Anpassung am Code nutzen kann.

    Soweit richtig

    Verteilst Du Noten?

    Original von tjp
    Original von Lucas de Vil
    STL macht es da einfach, weil der ganze Krams da drin zusammengefasst wurde und es einfach mit C++ fest verwoben ausgeliefert wird. Umstellungsprobleme gibt es dann nur wenn irgendwelche externen Bibliotheken geändert wurden. Dennoch sind Maps und Strings immer identisch gegeben.

    Streiche STL und setze C++ Standard Library, die C++ Standard Library erhält deutlich mehr Funktionalität als nur die übernommenen Teile der STL.

    Original von Lucas de Vil
    Cocoa/GNUStep macht es etwas komplizierter, da hier wirklich alles drin hängt. Ich kann meine Anwendung nicht in Core-ObjC klöppeln und mich dann für die GUI für ein Framework 'Cocoa', 'GNUStep' oder 'QuantumSTEP' entscheiden. Hier hängt alles ineinander zusammen, nicht bloß die Kernfunktionalität. Selbst wenn hier NSString, NSArray und NSDictionary immer gegeben sind, so muss ich zumindest die Imports anpassen.

    Nein
    1. Eine Standard Library ist kein Framework zur Applikationsentwicklung
    2. Es gab früher einmal Openstep for Mach x86 und 68k (Nachfolger von NEXTSTEP für HP-PA, SPARC, 68k und x86), Openstep for Windows und Openstep for Solaris.
      [/list=1]
      Früher war es möglich einmal ein Openstep Programm zu entwickeln und auf alle Plattformen zu portieren durch ein simplen Recompile. Bis auf die Windows Version sah auch alles immer gleich aus und funktionierte auch gleich. Auch die Solaris Version sah und fühlte sich nicht anders an als echtes Openstep for Mach. Man konnte beim Einloggen sich für den OPEN LOOK, CDE oder Openstep Desktop entscheiden. Das alles war zwar kommerziell, aber für den zahlungsbereiten Profi gab es Möglichkeiten die Anwendungen einfach und kostengünstig auf allen Plattformen anzubieten. Apple hat diese Möglichkeiten entsorgt.
      GNUstep und Cocoa sind nun einmal nicht identisch, sondern GNUstep ist ein freier Clone von Cocoa und hinkt daher dem Original immer hinterher. Man weiß daher nie mit Sicherheit was denn nun wirklich zu 100% funktioniert. Bestenfalls kann man unter GNUstep Software entwickeln und nach Cocoa portieren. Aber spätestens bei Multimedia Ansätzen kann man auch das Vergessen.
      [/quote]
      Was Du alles weisst! Du hast bestimmt unter OpenStep schon alles rauf und runter kompliert.
      Sicherlich warst Du auch '14-'18 dabei.

      [quote]Original von tjp

      Das alles wäre noch nicht einmal so schlimm, wenn Cocoa sich besser mit anderen Programmiersprachen vertragen würde.
      [/quote]

      Mit welchen denn? Und warum?

      Wie schon gesagt, für Dich sind Äpfel und Birnen immer Obst. Dann hat man mit Pflaumen und Kirschen auch keine Probleme.
      Also gibt es auch keinen Pflaumenkuchen oder Kirschtorte, sondern nur Obstgebäck.
      Das erinnert mich an das appetitanregende Konzept der Sättigungsbeilagen.

      [quote]Nur das ist nicht der Fall. So wird es schwierig um einen bestehenden Applikationskern ein GUI für MacOS X zu bauen, mit Carbon war das sehr viel einfacher. Das macht die Portierung von Software auf MacOS X zusätzlich teurer. Objective-C++ ist wirklich keine Hilfe, da es zu einem anachronistischen C++ Programmierstil zwingt der etwa auf dem Niveau von C with Classes ist.
      [/quote]
      Da hast Du Recht, Objective-C++ ist anachronistisch.
      Das Niveau kann ich nicht beurteilen, sicherlich nicht meines.

      [quote][quote]Original von Lucas de Vil
      Mir persönlich isses wurscht, da ich nach wie vor der Meinung bin Plattformunabhängigkeit in Bezug auf das Betriebssystem hilft zwar dem Entwickler, schadet aber dem Anwender.[/quote]
      Plattformunabhängigkeit verringert drastisch den Wartungsaufwand und damit die Entwicklungskosten, und wenn man den Applikationskern isolieren kann fällt das im GUI noch nicht einmal auf.[/quote]

      Also den kleinsten gemeinsamen Nenner mit dem alleinstellenden Merkmal: möglichst klein!
      Fangen wir doch mit der Bildschirmauflösung an, bevor wir uns in technischen Details verlieren.

      Das Schöne ist, dass Du es nicht nur nicht begreifen willst, sondern tatsächlich nicht kannst. Dein Paradigma greift nicht.
    I would be embarrassed if they did not spy on me.
  • Wie fragte mal jemand: Kann man in Alaska Bananen züchten? Oder so ähnlich.
    Man kann, bestimmt, und auf Island lohnt es sich sogar.
    Aber niemals, wenn man Wasser nur als Eis kennt , oder von Bildern aus Wikipedia.

    Und jetzt will uns da jemand überzeugen, mit Eis Bananen zu züchten.

    Warum kriege ich jetzt bloß Appetit auf ein 'Banana Split"?
    I would be embarrassed if they did not spy on me.
  • Original von longW
    Original von Lucas de Vil
    Nu steig ich gar nicht mehr durch.
    Und das liegt nicht an der Uhrzeit.

    Dann hast Du es ja begriffen.

    Sicherlich. Ich muss nicht fünf Seiten lang diskutieren, dass ich ObjC nicht wie C++ einsetzen kann. Das weiß ich. In vielerlei Hinsicht. ;)
    «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
  • Original von tjp
    Original von Lucas de Vil
    Wenn ich mich mal einmischen darf: so wie ich die Sache sehe, geht die gesamte Diskussion um das Fehlen einer Standardbibliothek einzig und allein darum, dass ich egal für welches Betriebssystem grundlegende Komponenten wie beispielsweise Maps/Dictionarys und Strings ohne eine einzige Anpassung am Code nutzen kann.

    Soweit richtig

    Und soweit mit GNUstep ohne Probleme machbar.

    Original von tjp
    Original von Lucas de Vil
    STL macht es da einfach, weil der ganze Krams da drin zusammengefasst wurde und es einfach mit C++ fest verwoben ausgeliefert wird. Umstellungsprobleme gibt es dann nur wenn irgendwelche externen Bibliotheken geändert wurden. Dennoch sind Maps und Strings immer identisch gegeben.

    Streiche STL und setze C++ Standard Library, die C++ Standard Library erhält deutlich mehr Funktionalität als nur die übernommenen Teile der STL.

    Und deutlich weniger als GNUStep und Cocoa.

    Original von tjp
    Original von Lucas de Vil
    Cocoa/GNUStep macht es etwas komplizierter, da hier wirklich alles drin hängt. Ich kann meine Anwendung nicht in Core-ObjC klöppeln und mich dann für die GUI für ein Framework 'Cocoa', 'GNUStep' oder 'QuantumSTEP' entscheiden. Hier hängt alles ineinander zusammen, nicht bloß die Kernfunktionalität. Selbst wenn hier NSString, NSArray und NSDictionary immer gegeben sind, so muss ich zumindest die Imports anpassen.

    Nein
    1. Eine Standard Library ist kein Framework zur Applikationsentwicklung[/Quote]
      Na, also, geht doch.

      [quote]Original von tjp
    2. Es gab früher einmal Openstep for Mach x86 und 68k (Nachfolger von NEXTSTEP für HP-PA, SPARC, 68k und x86), Openstep for Windows und Openstep for Solaris.
      [/list=1] [/Quote]
      Und jetzt gibt es GNUStep.
      Dir ist schon klar, dass GNUstep openstep-vollständig ist?

      [quote]Original von tjp
      Früher war es möglich einmal ein Openstep Programm zu entwickeln und auf alle Plattformen zu portieren durch ein simplen Recompile. Bis auf die Windows Version sah auch alles immer gleich aus und funktionierte auch gleich.[/Quote]
      Also funktionierte es auf Linux wie Openstep, nicht wie Linux?
      Also funktionierte es auf Windows wie Openstep, nicht wie Windows?
      Also funktionierte es auf $system wie Openstep, nicht wie $system?

      Das ist sinnvoll, verhält es sich in meinem Arbeitsalltag doch so, dass ich dieselbe Anwendung auf ganz vielen Systemen benutze. Oder doch eher ganz viele Anwendung auf demselben System?

      Hmmmmmm, welche Einheitlichkeit sollte man da wohl fördern?

      [quote]Original von tjp
      Auch die Solaris Version sah und fühlte sich nicht anders an als echtes Openstep for Mach. Man konnte beim Einloggen sich für den OPEN LOOK, CDE oder Openstep Desktop entscheiden. Das alles war zwar kommerziell, aber für den zahlungsbereiten Profi gab es Möglichkeiten die Anwendungen einfach und kostengünstig auf allen Plattformen anzubieten. Apple hat diese Möglichkeiten entsorgt.
      GNUstep und Cocoa sind nun einmal nicht identisch, sondern GNUstep ist ein freier Clone von Cocoa[/Quote]
      Nope, GNUstep implementiert Openstep vollständig. Und Clone stimmt ohnehin nicht.

      [quote]Original von tjp
      und hinkt daher dem Original immer hinterher. [/Quote]
      So wie jede Erweiterung in der C++-Welt dem Standard.

      [quote]Original von tjp
      Man weiß daher nie mit Sicherheit was denn nun wirklich zu 100% funktioniert. Bestenfalls kann man unter GNUstep Software entwickeln und nach Cocoa portieren. Aber spätestens bei Multimedia Ansätzen kann man auch das Vergessen.[/QUote]
      Schmarren, was funktioniert, sagt die GNUstep ganz genau.

      [quote]Original von tjp
      Das alles wäre noch nicht einmal so schlimm, wenn Cocoa sich besser mit anderen Programmiersprachen vertragen würde. Nur das ist nicht der Fall.[/Quote]
      Und das ist gut, etwas anderes wäre schlimm, nämlich, wenn sich Cocoa mit dem statischen C++ vertragen würde. Es wäre dann nicht mehr Cocoa. Das Ding ist für Anwendungsentwicklung, wofür C++ völlig ungeeignet ist.

      [quote]Original von tjp
      So wird es schwierig um einen bestehenden Applikationskern ein GUI für MacOS X zu bauen, mit Carbon war das sehr viel einfacher. Das macht die Portierung von Software auf MacOS X zusätzlich teurer. Objective-C++ ist wirklich keine Hilfe, da es zu einem anachronistischen C++ Programmierstil zwingt der etwa auf dem Niveau von C with Classes ist.[/Quote]
      Jede Art der C++-Verwendung zwingt zu einem völlig anachronistischen Programmierstil.

      [quote]Original von tjp
      [quote]Original von Lucas de Vil
      Mir persönlich isses wurscht, da ich nach wie vor der Meinung bin Plattformunabhängigkeit in Bezug auf das Betriebssystem hilft zwar dem Entwickler, schadet aber dem Anwender.[/quote]
      Plattformunabhängigkeit verringert drastisch den Wartungsaufwand und damit die Entwicklungskosten, und wenn man den Applikationskern isolieren kann fällt das im GUI noch nicht einmal auf.[/quote]
      Wenn man den Applikationskern isolieren kann, verwendet man für den einfach kein Cocoa.
      Allerdings glaube ich schon, dass es auffällt, wenn man etwa kein Observing hat. Dann hat man wieder diese schönen Okay-Buttons.
    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"?