Hallo allerseits,

in einem anderen Thread hier (Synchronisation eigener Audiodateien unter 10.15 Catalina) wurde eher am Rande eine Frage angesprochen, die mich ganz allgemein schon seit längerem interessiert:

Es geht mir dabei um (mir fällt kein besserer Name ein) Medienverwaltungsprogramme ganz allgemein, also Programme, bei denen nicht gezielt einzelne Dokumente aus dem Finder bzw. dem Öffnen-Dialog geöffnet werden, sondern die einen unmittelbaren Zugriff auf viele Dateiinhalte direkt aus ihrer Nutzer-Oberfläche bieten. Beispiele wären iTunes, Mail, Fotos und Nachrichten von Apple und von Drittanbietern Programme wie MacJournal, DEVONthink und viele andere.

Im Alltag kann einem als Anwender bei Programmen dieser Art natürlich egal sein, wo und wie die verwalteten Informationen abgespeichert sind. Aber es gibt Situationen, wo das nicht der Fall ist: weil etwas nicht funktioniert, wie es soll, weil man Zugriff auf eine einzelne Datei haben will, obwohl das Programm das nicht vorsieht, weil der Hersteller des Programms nicht mehr existiert, aber man an seine Informationen gelangen will, oder einfach, weil man gerne versteht, was genau und wo auf dem eigenen Rechner vor sich geht.

Für all diese Fälle wäre es ja sehr naheliegend, die Informationen abzulegen in Dateien und Ordnern, deren Namen der Sortierung auf der Programmoberfläche entsprechen. Ein Musterbeispiel dafür ist iTunes, das das so macht: Die Musikdateien haben als Namen den Titel des Musikstücks und liegen in Ordnern, die den Namen des Albums tragen, die wiederum in Ordnern liegen, die den Namen des Interpreten tragen. Transparenter geht nicht. (Ich weiß nicht, ob das bei der neuen Musik-App in Catalina erhalten bleibt, hat da schon jemand geguckt?)

In anderen Programmen ist das aber zunehmend verschwunden. Entweder war es von Beginn an anders, oder wurde im Laufe der Zeit umgestellt. Dort liegen die Dateien wild verstreut in Ordnern mit Zufallsnamen wie B10DD3E2-629B-4E19-874E-EEC93FB2FFB1 und/oder die Dateien haben selbst solche Namen. Manchmal gibt es auch endlose Ordnerhierarchien mit bedeutungslosen Namen wie 02 → 05 → 13 → 07 → 11, bis man irgendwann auf die eigentliche Datei stößt.

Wenn man, warum auch immer, außerhalb des entsprechenden Programms gezielt an seine Daten gelangen will, ist das natürlich maximaler Mist.

Mir ist unklar, warum das immer weiter zunehmend so gemacht wird. Kennt jemand den Grund für diese offenkundig beabsichtigte Intransparenz?


PS: Eines der Dinge, die ich an NEXTSTEP so überzeugend fand, war die maximale Transparenz des Systems. Ein gutes Beispiel dafür ist das RTFD-Dateiformat, das bis heute auf macOS überlebt hat: Ein Dokument mit Bildern ist de facto ein Ordner, der das RTF-Text-Dokument und die Bilddateien in Standardformaten enthält, alles unabhängig von TextEdit mit Programmen lesbar, die mit Standard-Bild- und Textformaten umgehen können. Transparenter geht nicht. Ebenso konnte man z.B. die .nib-Dateien, die die GUI der Programme enthielten, mit dem Interface Builder selbst bearbeiten und Ordnerhierarchien hatten eben keine kryptischen Namen.

Diese Transparenz, so scheint es mir, wird in macOS immer weiter gezielt zerstört. Warum? DRM? Sicherheitshysterie? Nutzer-Bevormundung (aber aus welchem Motiv?)?

Man braucht das aber nicht, um ein Betriebssystem zu schreiben, und in der Anwendungsentwicklung ist Pointerarithmetik ein stetiger Quelle für Exploits. Ich sehe da halt nicht den Grund weshalb man das unbedingt benötigt, aber ich sehe vor allem die großen Risiken die damit verbunden sind. Dazu ist Objective-C eine reine Applikationssprache und wird für low level Sachen erst gar nicht genutzt – im Gegensatz zu C oder C++, und in C++ geht der Trend eindeutig in die Richtung keine C Sprachelemente mehr zu nutzen.

[… Du meinst: der OO-Teil von Objective-C …]Ja, und genau das ist doch das Fantastische! Ich habe die beiden grundverschiedenen Welten in ein und derselben Sprache zur Verfügung und kann so problemlos zwischen ihnen wechseln.

Ich schreibe oft mega-optimierten C-Code mit ganz viel Pointerartihmetik und anderem C-Low-Level-Zeugs für eine bestimmte Aufgabe, kapsle den in eine Objective-C-Klasse und kann ab da diese Klasse ohne viel Nachdenken, komfortabel, mit Late-Dynamik-Binding und mit toller Performance in meinen Anwendungsprogrammen als Lego-Baustein einsetzen.

Keine andere Programmiersprache auf der Welt kann das in diesem Ausmaß bieten, Swift schon gar nicht.

Genug geschwärmt, mein letzter Beitrag hier zu diesem Thema!

Ich hatte mir erhofft, dass Du eine Erklärung anführst, weshalb Du Pointerarithmetik in Applikationscode für notwendig erachtest. Ich sehe das halt nicht, und ich habe seit Jahren das auch nicht mehr gebraucht trotz hoch optimierten HPC-Code u.a. in Fortran (das erlaubt keine Pointerarithmetik). Letztlich musste ich es verwenden, weil ich einen C++ Allokator für Testzwecke schrieb, der die allozierten Speicher Chunks selbst verwaltete. Abseits solcher Szenarien sehe ich dafür nun einmal keine Notwendigkeit davon.