Soso... es ist also schwierig, für die altbewährte Win32-API oder die neue .net-API Programme zu entwickeln. Ja, klar, MacOS X ist so irre modern, etwas völlig neues, was mit Next überhaupt nichts mehr zu tun hat. Auch die ständigen Wechsel der Prozessorplattform und der Programmierschnittstelle (Classic, Carbon, Cococa) vereinfachen die Sache ungemein. Das sieht man ja gerade bei Adobe

Es kommt halt immer auf die Ausgangssituation an. Wenn man ein bestehendes Programm mit MIllionen von Zeilen hat und wird dann aufgrund des Abschneidens alter Zöpfe gezwungen das Programm praktisch von Grund auf neu zu erstellen, dann kommt man sicherlich zu einer anderen Bewertung als jemand, der mit einem neuen Projekt anfängt.
Das Windows-Entwickler ihre Software nicht so sehr pflegen wie Mac-Entwickler halte ich für eine schlichte Verallgemeinerung.

Wobei der Cocoa-Zopf ja nicht so wirklich neu ist, sondern knapp 20 Jahre alt...

naja, wer .net schlecht redet, hat's noch nie verwendet imho. visual studio als ide und zB C# sind wirklich sehr brauchbar und es ist einfach zu entwickeln

Merzer
Classic, Carbon und Cocoa sind kein ständiger Wechsel, das ist schlicht und ergreifend die... ich nenn es mal Evolution der API. Sie entwickelt sich eben konsequent weiter. Altes wird zu "depricated" und Entwickler bekommen genug Zeit zur neuen API zu portieren. Dann fliegt Altes raus. Nur so lässt sich die Basis sauber und frei von Altlasten halten. Die gibt es zwar auch noch in OS X, aber es ist recht überschaubar.

Als Weiterentwicklung würde ich das nicht sehen - Classic war die alte API des klassischen Mac OS, Cocoa die Weiterentwicklung der zwar guten, aber uralten und von fast niemanden benutzten API von Next (wohl im wesentlichen von OpenStep). Carbon ist eine Art von Notlösung, um mit relativ geringen Änderungen am Code alte Anwendungen, die für das klassische MacOS entwickelt wurden, auch außerhalb von Classic unter MacOS X nutzen zu können.

Da war doch die Vorgehensweise von Microsoft eleganter, wo sich die API trotz des grundlegend unterschiedlichen Unterbaus der Dos-basierten Systeme und der NT-basierten Systeme überhaupt nicht unterschied und sogar noch nahtlose alte 16-bit-Anwendungen in virtuellen DOS-Maschinen ausgeführt werden können, ohne daß der Benutzer davon irgendetwas mitbekommt.

Adobe ist hier kein Argument, deren Codebase ist nicht viel besser als die von Windows selbst.

Ich habe keine Ahnung wenn es um Programmieren geht. Aber einfache Feststellung: ich lade unter XP eine Demo runter (Systemanforderungen werden erfüllt) und sie läuft einfach nicht, das selbe schon mehrmals mit Shareware. Ist mir unter MacOS X noch nie passiert. Soweit mein Kommentar von der Verbraucherseite.

Merzer
Carbon ist keine Notlösung, es ist der "fließende" Übergang von Classic zu Cocoa. Apple hat mit dem Erscheinen von Cocoa von Anfang an kommuniziert, für neue Anwendungen nur noch Cocoa zu verwenden. Bestehende sollten mit Carbon unter Cocoa lauffähig gemacht werden, um den Umstieg flüssiger zu gestalten. Es wurde immer davon geredet, dass Carbon austerben wird.
In meinen Augen ist das eine saubere Lösung.

Genau das von dir aufgeführte Beispiel alter 16-bit Anwendungen unter Windows macht es doch recht deutlich. Zu Beginn war das sicher eine gute Lösung, ohne Frage. Aber ich vergleiche das inzwischen eher mit einem Schneeball, der einen Hang herunterrollt. Am Anfang ist er klein und flink, und läuft tadellos. Aber auf seinem Weg nimmt er immer mehr Zeugs mit und behält auch das, was er schon hat, im Kern. Er wird immer größer, behäbiger und schwerer. Eigentlich fast nicht mehr zu kontrollieren. Und aus meiner Sicht bieten sich nur zwei Optionen:

[1] Er bleibt stehen und nix geht mehr
[2] Er zerbricht komplett, und aus ist's

phranck
Richtig.

Wenn Carbon nur eine Notlösung ist, warum verwendet es Apple ewig selber noch im Finder??

So ganz kann ich das Argument mit dem Schneeball nicht nachvollziehen. Im Gegensatz zur Win32-API (=Subsystem) werden die alten 16-bit-Anwendungen innerhalb einer virtuellen Maschine ausgeführt, die einfach als ganz normale Anwendung unter Windows läuft. Inwiefern dadurch das Betriebssystem aufgebläht werden soll, erschließt sich mir nicht - schließlich handelt es sich dabei für das Betriebssystem einfach um eine weitere Anwendung.

Natürlich war Carbon eine Notlösung, mit der ermöglicht werden sollte, überhaupt mit einem vernünftigen Aufwand Programme außerhalb von Classic anbieten zu können. Und damit laufen auch nicht alte Classic-Anwendungen "unter Cocoa" - bei Carbon handelt es sich vielmehr um eine völlig eigenständige API, welche möglichst viele alte Toolbox-APIs nachbildet und über diese den Zugriff auf MacOS X ermöglicht.

Wo steht eigentlich, daß Carbon "aussterben wird"? Verwechselst Du das mit der Toolbox? Daß Carbon kein 64-Bit unterstützt, kam dann wohl doch etwas überraschend - so viel zum Thema "verläßliche Kommunikation" (vgl. auch den relativ überraschenden Umstieg auf Intel).

"Wenn Carbon nur eine Notlösung ist, warum verwendet es Apple ewig selber noch im Finder??"

Weil der Finder programmtechnisch ein ziemlicher Murks ist - aber das hat Tradition: erst mit MacOS 8.5 lief der damalige Finder nativ auf dem PowerPC, nachdem er vorher noch als emulierte 68er-Anwendung ausgeführt wurde (über die integrierte 68020er-Emulation des klassischen MacOS). iTunes ist ja auch eine Carbon-Anwendung, die unter dem Namen Soundjam MP für das klassische MacOS entwickelt und dann zugekauft wurde.

Ich arbeite in einem Rechenzentrum und die (sauteure) Windows Software, die dort verwendet wird, kann man nur als Scheiße bezeichnen.

Programmierer, die nur für WIndows programmieren sind absolut letztklassig. Idioten, die nur geisteskranken Dünnschiß produzieren.

Ich kann den Autor nur zustimmen, was die Motivation und Qualität vs. Quantität angeht: viele WinApps sind unlieb mittels RAID zusammengeschustert und sehen wirklich gegenüber OS X Applikation ziemlich blass aus. Ich selber verdiente mittels Programme für XP (und Embedded) mein Unterhalt und die Motivation
Seit ich die Arbeit auf OS X (auch Java ) fokussiert habe , hat man dieses typische apfelgefühlt ( User ... ) , was eigentlich nicht immer beschreibbar ist, aber das kennen die meisten
Ich ertappe michh dabei nach der Arbeit meinen Mac zu streicheln, auch Entwickler lieben ihren Mac

Um die eigentliche Frage zu beantworten - als der heutige Finder geschrieben wurde, war die Implemtentierung von Cocoa noch nicht fertig. Um jedoch rechtzeitig den Finder fertigstellen zu können, wurde er mit Klassenbibliotheken der Entwicklungsumgebung PowerPlant von Metroworks als klassische MacOS-Anwendung entwickelt und nachträglich carbonisiert.

phranck
Die 16-bit-Applikationen sind das EINE GUTE Beispiel unter Windows, ziemlich genau so wie Carbon oder die Prozessor-Wechsel 68kPPCx86. Den alten Zopf zwar abschneiden, aber eine geschickt integrierte Emulationsumgebung anbieten, wo das alte Zeug doch noch läuft.

Der Schneeball bei Windows liegt in der undendlichen Vielzahl von guten, mittelprächtigen und grausamen APIs, wo sie eben dieses Vorgehen mit der Emulation NICHT gemacht haben, und die drum ALLESAMT weiter unterstützt werden müssen, weil sie in ganz vielen teuren Enterprise-Softwareprojekten im Einsatz sind.

Apple ist grausamer mit den Entwicklern umgegangen, hat viel mehr konsolidiert und vereinheitlicht. Sie konnten das tun, weil sie so gut wie keine Enterprise-Software berücksichtigen mussten, weil es die auf dem Mac kaum gibt. Sondern hauptsächlich klassische Anwendungen, von professionellen Softwarehäusern nicht nur erstellt sondern im Eigeninteresse auch weiterentwickelt. Klar toben die bisweilen, wenn dicke Brocken wie Intel oder so kommen, aber sie machens, und letztlich tut ein gröberes Rewrite dem Produkt gut.

Bei auf Projektbasis erstellter (Microsoft basierter) Enterprise-Software ist aber niemand mehr da, der das von sich aus macht. Der Anwender müsste eine Anpassung wieder auf Projektbasis in Auftrag geben, für viel viel Geld. Das wird er nimmer tun, also bleibt MS nichts anderes übrig als ihren API-Berg weiterzuschieben und immer schwerfälliger dabei zu werden.

"die (sauteure) Windows Software, die dort verwendet wird, kann man nur als Scheiße bezeichnen."

Ich finde es gut, daß alle Diskutanten ein sehr hohes Argumentations- und Ausdrucksniveau erreichen, wie es für Apple-Nutzer charakteristisch ist. Noch mehr freue ich mich, daß eine Diskussion auf sehr hohem technischen Niveau stattfindet und auf meine Beiträge fundiert eingegangen wird.

Zur Diskussion:
1. Classic ist keine API.
2. Carbon bildet weitestgehend die Toolbox-API nach.
3. Carbon ist eine Kompatibilitäts-API.
4. Carbon läuft nicht "unter", "über" oder "auf" Cocoa.

Apfelmac
Ich laube nicht das die meisten geisteskranke Idioten sind, auch dies habe meistens eine gute Ausbildung oder ein Studium absolviert, wie ich. Der Mark drängt die meisten für Windows zu programmieren. Auf den Marktanteil dieses OS muss ich wohl nicht mehr hinweisen. Viele Auftraggeber wollen schnell und dirty Anwendungen für wenig Geld oder viel wird in billigen Ausland programmiert, habe ich auch schon machen lassen, bin ganz schön auf die Nase gefallen ...
Also immer langsam mit den Pferden

Merzer
zu iTunes: Das wusste ich nicht. Höre ich zum ersten Mal (dass es zugekauft wurde).
zu Carbon & Finder: Das stimmt, der Finder ist eine ziemliche Flickschusterei. Das mit Carbon alte Classic Anwendungen laufen, habe ich ja nicht gesagt. Aber mit Carbon haben Entwickler die Möglichkeit bekommen, ihre alten Anwendungen schnell unter OS X lauffähig zu bekommen, ohne gleich komplett nach Cocoa portieren zu müssen. Das meinte ich.

Lieber Merzer,

Lotus Notes = Scheiße
OCÉ Prisma Produktion = Scheiße
SAP R/3 = Scheiße
Microsoft Internet Explorer = Scheiße
Peregrin Service Center = Scheiße

Nur eine kleine Auswahl, aber ein Haufen jämmerlicher Programmierkotze, die einem ständig mehr Arbeit macht, als notwendig, kombiniert mit praktisch nicht vorhandener Usability oder was die Idioten imit ihrer kranken Birne darunter verstehen.

Zum Artikel:
Cocoa-Applikationen zu schreiben, ist nicht immer so ein Zuckerschlecken, wie sich der Ars-Autor das wohl vorstellt. - Ich glaube Bertrand Serlet sagte mal zutreffend "Simple things are simple. Complex things are possible."
Sobald man keine zu seiner Aufgabe passende Klasse / Framework mehr findet, kann das richtig schweisstreibend werden, insbesondere wenn man meist Fremdapplikationen portiert.

Merzer
"wie es für Apple-Nutzer charakteristisch ist"

Polemik hilft aber auch nicht wirklich. Ich nutze Macs seit gut 12 Jahren, seit 10 Jahren fast ausschließlich. Sachlichkeit und/oder Intelligenz hat in meinen Augen nix mit dem Nutzen oder Favorisieren einer Plattform zu tun, es ist vielmehr eine Charakterfrage und eine Sache des Willens, sich auch tellerübergreifend Wissen anzueignen.
Ich habe es "probiert" und eineinhalb Jahre auch unter Windows entwickelt. Die Werkzeuge dort (Studio) sind erstklassig und Äonen dem voraus, was Apple derzeit mit Xcode anbietet. Dennoch, ich bin froh inzwischen wieder auf und auch für Mac OS X entwickeln zu können. Wie ein Schreiber vor mir es ausdrückte, es fühlt sich für mich "irgendwie" wohliger an.

phranck
Das iTunes eine Carbon-App ist, ist doch schon ewig bekannt. Über den Daumen gepeilt, sind noch deutlich mehr als die Hälfte aller Apps auf deiner Platte mit Carbon gestrickt worden. Und bei allem was QT verwendet ist das sowieso obligatorisch.

Merzer: Wenn dir jemand blöd kommt dann ist das eine Sache. Aber gleich jeden Applenutzer in eine Tasche zu stecken finde ich wesentlich schlimmer.

iCode
Das iTunes Carbon ist, das wusste ich. Mir war nur neu, dass es hinzugekauft wurde. Muss irgendwie an mir vorüber gegangen sein

"Die Werkzeuge dort (Studio) sind erstklassig und Äonen dem voraus, was Apple derzeit mit Xcode anbietet."

Die Entwicklungsplattform XCode + MacOS X ist durch den Unixanteil an Produktivität kaum zu schlagen. Vielleicht mit Eclipse aber sonst fällt mir nix ein, was dem auch nur ansatzweise das Wasser reichen könnte - zumindest nicht in der Liga, in der Visual Studio spielen will.

Sicher ist Visual Studio kein schlechtes Tool wenn man es mit den Sachen vergleicht, die auf der Windowsplattform existieren.

detto
Ich würde da jetzt nicht so ein Fass auf machen, denn im großen Ganzen hat er recht. Das kann man von einigen Anderen, die hier mit Herzblut aber ohne Sachkenntnis diskutieren, wirklich nicht behaupten. - Aber ich würde diese Verhalten wirklich nicht allein auf Apple-Anwender beziehen.

Apfelmac

ich könnte die Liste weiterführen

zB.
PDMS = dreck mit kommandorzeilen und das für 15000 € pro Lizens und die Ganze Software von AVEVA (und das ist sicher keine schnell und billig Ding) :sick:

und noch Paar einfache Programme für BackUp, wird schlecht wenn man die Dinge nur aufmacht

natürlich nicht Alles für Windows das letzte Schrott ist
aber weitgehen mehr als für mac

und für Alle die andere Meinung haben
"ich muss kein Koch sein um festzustellen, dass die Suppe versaltzen ist"