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?)?

Der Grund ist trivial, weil man nur so Namenskollisionen vermeiden kann. Es gibt z.B. von CDs diverse Versionen und insbesondere Sammler haben alle verschiedenen Versionen, die aber alle gleich heißen. Wenn man die Musiktitel von Hand importieren würde, würde man die Kollision von Hand auflösen. Ein Programm kann das nicht. Daher ist das technisch notwendig. Ich hatte das Problem bei einer Firmenlösung, die Mailattachments in einer Datenbank ablegen musste. Mir blieb nichts anderes übrig als solche kryptischen Namen zu generieren und die Namen der Attachments in der DB abzulegen.

Das könnte man doch aber auch, indem man einfach an einen schon vergebenen Namen ggf. eine laufende Ziffer anhängt? Der Finder macht das z.B., wenn er aus einem Archiv eine Datei entpackt, die bereits existiert. Oder Safari, wenn wiederholt dieselbe Datei heruntergeladen wird.

Das erscheint mir wie mit Kanonen auf Spatzen geschossen.
Aber gerade iTunes ist ja nun das eine Programm, das es noch transparent macht und keine kryptischen Namen vergibt.

Nun, die Ordnernamen und die Links klingen doch sehr nach Devonthink. Wird eine Datei innerhalb der Datenbank verschoben, bleibt die Datei im Grund an Ort und Stelle. Möchte ich extern zugreifen, gibt es "Verweise", um die Datei auch dann zu finden, wenn sie innerhalb von DT an einem anderen Ort ist. Alternativ kann ein Ordner indiziert werden, dann werden auch tatsächlich die Dateien physisch verschoben, wenn sie innerhalb von DT verschoben werden. Durch die Indizierung wird bei DT zudem verhindert, dass ich eine Mail zweimal importieren kann.
Ich habe übrigens Deine Idee mit Text-Bundles als Anregung aufgegriffen und nutze nun Scrivener für Text-Pakete zu einzelnen Projekten.

Kann die Überlegung eine Rolle spielen, dass die Wahrscheinlichkeit, zwei gleiche Dateinamen zu vergeben, gegen Null tendiert, wenn man Dateinamen a la "B10DD3E2-629B-4E19-874E-EEC93FB2FFB1" vergibt?

Weia:

Warum?
Evtl./wahrscheinlicher Grund: Größere Sicherheit des Systems.

Um z.B. Angriffe durch Schadprogramme etc. zu erschweren und wichtige Dateipfade zu randomisieren und zu individualisieren (z.B. auch mittels Hash oder einer individuellen ID) statt immer identisch aussehen zu lassen und somit die Vorhersagbarkeit bewusst zu erschweren. Die, wenn sie dem Angreifer/Schadprogramm vorher genau bekannt sind ("kennste einen, kennste alle"), ihm ein Leichtes sind, sie ins Visier zu nehmen – er weiß somit vorher genau, wo was Bestimmtes abgelegt ist und exakt wie der Pfad dazu heißt. Das ist mit individuellen, randomisierten Pfaden oder Teilpfaden, die bei jedem Nutzer im Detail oder in Teilbereichen anders lauten, um Einiges schwieriger.

Der Firefox-Browser z.B. legt schon seit Urzeiten seine Benutzer-Profile in teilrandomisierten Pfaden ab (z.B. /Users/$USER/Library/Application Support/Firefox/Profiles/uvr04aus.default). Aus genau diesem Grund.

Apple macht es seit einigen Jahren inzwischen genauso und legt bestimmte Verzeichnisse und Dateien in randomisierte Pfad-Bereiche bzw. legt die Verzeichnisse/Pfade dazu randomisiert an. Ein großer Ort, wo sich diesbzgl. viel tummelt, u.a. auch diverse vom System und anderen Programmen genutzte Cache- und Temp-Verzeichnisse und Dateien, ist unter /var/folders zu finden. Teilweise sind die absoluten Pfade dazu mit einfachen Funktionen ermitteln und erreichbar, z.B. der user-spezifische Temp- oder Cache-Ordner mit

Der Ordner T am Ende des Pfades steht für "Temp"

(der Pfad ist i.d.R. auch in der Umgebungsvariable $TMPDIR gespeichert, wenn diese gesetzt)

oder


Der Ordner C am Ende des Pfades steht für "Cache".


Geh' mal spaßeshalber in diese beiden genannten Bereiche, hangele Dich da mal durch, und schaue, was da alles zu finden ist und abgelegt wird. – bzw. überhaupt nach /var/folders.
Teilweise sind die Ordner nur via sudo einsehbar, teilweise gehören sie einzelnen System-Komponenten, teilweise gehören sie aber dem Nutzer, wie obige beiden Beispiele.


Oder habe ich Deine Frage missverstanden, meinst Du was völlig Anderes?

Es gibt sehr unterschiedliche gute Gründe für die Dateiablage mit "kryptischen" Namen. Bereits genannt worden ist die Eindeutigkeit der Dateinamen bzw. Kollisionsvermeidung.

Sehr häufig anzutreffen sind auch Filenamen, die aus Hashes des Fileinhalts oder von Metainformationen über das File bestehen. Das macht man zum Beispiel, um ein File schnell auffinden zu können: Wenn ich den Inhalt oder bestimmte Metainformationen kenne, kenne ich auch den Namen - git z.B. macht das so. Wenn ich einen derartigen Mechanismus nicht habe, muß ich ein Verzeichnis unterhalten, in dem ich zuerst den tatsächlichen Dateinamen und Ablageort nachschlagen muß, bevor ich auf die Datei zugreifen kann.

Bei git ist noch ein anderer Sinn damit verbunden: So wird bei der Ablage einer Datei sichergestellt, daß Dateien mit gleichen Namen mit an Sicherheit grenzender Wahrscheinlichkeit den gleichen Inhalt haben (Kollisionen bei SHA1-Hashes sind zwar nachgewiesen, in der Praxis aber extrem selten).

Die "bedeutungslosen" Namen der Dateipfade verfolgen einen ähnlichen Zweck. Die meisten, insbesondere ältere, Filesysteme haben Performance-Probleme, wenn zu viele Dateien in einem Verzeichnis stehen, also werden Unterverzeichnisse angelegt, die dann nur eine Teilmenge der Daten enthalten. Um die Dateien zum einen gleichmäßig zu verteilen und zum anderen wiederum schnell auffindbar zu machen, bestehen die Verzeichnisnamen dann aus Teilen des Hashes, der den Dateinamen darstellt - wiederum sehr effizient beim Auffinden der Dateien.

Beispiel: Der Dateiname ist
und es sollten zur Verteilung 65536 (mögliche) Verzeichnisse genutzt werden. Ein möglicher sinnvoller Unterpfad ist dann z.B.

Vorteil: Man muß sich nicht merken oder nachschauen, in welchem Verzeichnis eine Datei liegt, sondern man weiß es sofort und muß nur noch darauf zugreifen.

Das Sicherheitsargument ist allerdings unsinnig, das wäre security by obscurity und hat noch nie wirklich funktioniert.

Es handelt sich hier um eine sogenannte UUIDv4. Wie meine Vorgänger bereits gesagt haben geht es um Kollisionsvermeidung.

Natürlich könnte man das auch anders machen mit einem Algorithmus den ein Mensch besser zurecht kommt, aber das ist bei diesen Anwendungsfällen nicht das primäre Ziel.

Das ganze stammt auf Zeiten bevor es SSDs gab und die Zugriffszeiten aufs Dateissystem noch unerträglich waren.

Stell dir mal vor du müsstest 1 Mio Dateien in iTunes importieren und bei jeden Dateinamen müsstest du prüfen ob der Pfad schon belegt ist um dann eine 2 anzuhängen und falls das auch belegt ist eine 3 und so weiter.

Bis alle Daten importiert wurden vergeht dann eine sehr lange Zeit da der Prüfaufwand bei so großen Datenmengen sehr hoch ist.

Zufällige UUIDs sind so gut wie immer eindeutig. Das auf einem System zwei mal die gleiche UUID generiert wird ist zwar nicht unmöglich, aber statistisch so unwahrscheinlich, dass man als Entwickler davon ausgeht dass der Pfad noch nicht existiert und man deshalb den Prüfschritt überspringen kann. So beschleunigt man den Import von großen Datenmengen extrem. Damit die Dateien später wieder gefunden werden können wird der Pfad dann als Referenz nurnoch in eine Datenbank geschrieben und schon ist es fertig und effizient

Als Softwareentwickler würde ich behaupten, dass das nichts mit absichtlicher Intransparenz, Sicherheit oder Eindeutigkeit zu tun hat. Eindeutigkeit kann man auch bei lesbaren Namen erreichen, sicherer wird das dadurch auch nicht, und die Intransparenz ist irrelevant, da man für den Zugriff ja die Software hat.
Der Grund ist viel trivialer: Einfachheit. Als Softwareentwickler ist es deutlich einfacher, mit UUIDs (Unique Unified Identifier) als Name zu arbeiten (was das oben im Titel übrigens ist) oder anderen Alphanumerischen Ids, die einfach hochgezählt werden. Das Unternehmen, in dem ich arbeite, stelle eine Software her, in der auch von Anfang an die Namen der "Objekte" als Id genutzt wurden. Aktuell sind wir allerdings in einem sehr langwierigen Prozess, diese IDs alle auf einfache numerische oder alphanumerische Ids umzustellen, da das alte System mittlerweile zu massiven Problem führt. Klar wäre es möglich, das zu behalten. Aber der Aufwand für die Wartung dieses alten System rechnet sich nicht mehr.
Mit solchen "kryptischen" Ids hat man deutlich weniger Aufwand als Entwickler in einem komplexen System, und kann seine Ressourcen so deutlich sinnvoller verwenden.

Danke für die vielen aufschlussreichen Antworten! Manche Aspekte kannte ich, andere noch gar nicht.War aber aus MacJournal. Ist, wie aMacUser schon schrieb, halt einfach eine UUID, wie sie von vielen Programmen verwendet wird.
Ah, OK, Dateisystemoperationen zu minimieren könnte ein valider Grund sein, den ich nicht bedacht hatte. (Wobei man einwenden könnte, dass das Dateisystem selbst ja auch nichts anderes ist als eine Datenbank mit Verweisen auf den beim Verschieben unverändert bleibenden Speicherplatz auf der Festplatte.)Ja, das ist ja auch eine meiner Vermutungen. Aber das wäre halt security by obscurity, ein, wie Peter Eckel zu Recht anmerkt, problematischer Ansatz.
Ja, /var/folders/ ist mir wohlvertraut und war, wenn auch nicht eingangs erwähnt, einer der Hintergründe für meine Frage bzw. auch meinen Verdacht mit der Sicherheit als Motiv.
Nönö, genau richtig verstanden.
Diese Aspekte waren mir überhaupt noch nicht bekannt/bewusst – sehr aufschlussreich, danke!
Dieser Aspekt allerdings steigert meinen Blutdruck in medizinisch unverantwortbare Regionen.

Die Transparenz für Millionen von Nutzern wird geopfert, damit es ein paar wenige Entwickler leichter haben? Das ist ein Denkansatz, den ich wirklich hasse, und der IMHO allem zuwiderläuft, wofür Apple zumindest unter Steve Jobs stand.

Steve Jobs war derjenige, der darauf bestand, dass Platinen (aus menschlicher, ästhetischer Sicht!) gut aussehen, auch wenn sie kein Anwender je zu Gesicht bekommt, geschweige denn, dass das ihre Funktion verbessern würde. Weil er überzeugt war, dass bedingungsloser Perfektionismus am Ende eben sehr wohl auf das Produkt insgesamt ausstrahlen würde. Eines der Kernprinzipien, die mich zum Apple- (oder besser: Steve-Jobs-)Fan gemacht haben. Wer eine Software nicht mit diesem Arbeitsethos schreibt, schreibt aus meiner Sicht keine native Mac-Software.

(Steve Jobs hatte dieses Ethos nach eigener Aussage übrigens von seinem Adoptivvater übernommen. Ich erinnere nicht mehr, wo ich das gelesen habe, aber er hat mal eine Geschichte erzählt, in der er als Kind seinem Adoptivvater zusah, wie der einen Schrank restaurierte (oder sogar neu baute) und dabei auch die Rückseite sauber abschliff und lackierte, obwohl sie ab da an der Wand stehen und sie niemand mehr sehen würde. Auf seine Frage nach dem Grund hatte der Adoptivvater gemäß obigem Ethos geantwortet. Jobs beschrieb das als eine der Episoden in seinem Leben, die ihn im Kern geprägt haben.)

Randomisierte Pfade:

Es ist aber, und nicht ohne Grund, u.a. inzwischen ein zentraler Bestandteil von Apples Sicherheitskonzept für macOS und iOS – Stichwort: App Translocation (u.a. benutzt dazu: /var/folders/s3/mtz6gwsa6r7zrr0f04bceqdr0000gp/T/AppTransloc ation) sowie Gatekeeper Path Randomization , , .
Vorgestellt von Apple auf der WWDC16 2016: Session 706: What’s New in Security (PDF) (PDF), (Video)

Einfach aufhören in Dateien und Ordnern zu denken. Ich mache das schon lange nicht mehr. Es wird nur noch grob sortiert. Den Rest erledigt die Suche. Ich öffne Dateien höchst selten durch manuelles Suchen im Finder. Ich benutze Spotlight. Oder wenn man sich die Mühe macht, alles mit Tags zu versehen, geht das auch.

Das hilft mir doch aber nichts, wenn ich herausfinden will, was in meinem System vor sich geht oder wie ich an Daten gelange, die mir ein bestimmtes Programm nicht herausgeben will?
Und wie bemerktst Du dann verdächtige Dateien, die Dir irgendein Programm unterschiebt?
Dazu muss man aber wissen, wonach man suchen will.

Bei mir ist es exakt umgekehrt: Ich sehe mir an, was sich alles in einem bestimmten Ordner angesammelt hat und stoße dann auf Dinge, die ich vollkommen vergessen hatte. Wie hätte ich nach denen suchen können?

Ist mir ja klar. Mag ich aber trotzdem nicht.

Mir geht Sicherheitsdenken sehr leicht auf den Wecker; jedenfalls ist mir Transparenz und Verständnis dessen, was vorgeht, viel wichtiger. Das ist natürlich eine Mentalitätsfrage.

Nein, hier ist unter anderem auch ein Sicherheitsgedanke gemeint, der in Richtung Datenschutz geht.

Neben den schon vielen erwähnten technischen Vorteilen, die eine UUID bietet, erhöht sich der Datenschutz in dem Sinne, dass ein Systemadministrator, der den Dateinamen zufällig in einem Ordner oder in einem Protokoll sieht, nicht mehr auf den Inhalt der Datei oder Personenbezüge schließen kann.

Es wird damit z.B. rechtlich zulässig, eine Protokolldatei, die Dateinamen enthält, im Rahmen von Debugging an Dritte (wie einen Software-Hersteller) zu senden, ohne dass mit diesem Hersteller erst ein Auftragsverarbeitungsvertrag zur Einhaltung von Datenschutzmaßnahmen abgeschlossen werden muss.

Das ist in der Praxis wichtiger als einige denken. macOS ersetzt z.B. auch in allen Systemprotokolleinträgen, die variable Texte enthalten, und bei denen das erstellende Programm nicht durch einen speziellen Marker zugesichert hat, dass es sich um datenschutzrechtlich unbedenkliche Elemente handelt, den entsprechenden Textabschnitt durch das Wort "<private>".

Und genau solches Verhalten darf man zurecht hassen denn so kann man im Falle eines Falles nicht mehr einfach kontrollieren was auf dem eigenen Rechner so vor sich geht. Ich will hier nicht vor mir selber schützt werden! Ich nenne solch Verhalten schlichtweg Bevormundung.

Apple muss sich selbst und die Kunden davor schützen, verklagt zu werden. Ansonsten wären die Funktionen "Analysedaten mit Apple teilen" und "Analysedaten mit App-Entwicklern teilen" illegal.

… aber das ist jetzt weit hergeholt. Das ist realistisch betrachtet nur eine willkommene Nebenwirkung beim Einsatz von UUIDs. Neben den rechtlichen Aspekten spricht eben auch technisch einiges dafür.

Nur weil Steve Jobs wollte, dass Platinen schön aussehen, hießt das nicht, dass das auch sinnvoll ist. Das ist eher Ressourcenverschwendung (je nachdem, wie weit man es treibt).
BtT: In der Regel ist es ja nicht notwenig, über das Dateisystem auf die Daten zuzugreifen. Und wenn man das regelmäßig macht/ machen muss, dann heißt das entweder, dass die Software kacke ist oder du ihr nicht traust. In beiden Fällen empfehle ich dir, eine andere Software zu suchen. Für den Fall, dass du einfach mal(!) gucken willst, was die Software so speichert, ist das vollkommen vertretbar. Und falls eine Software so alt ist, dass sie nicht mehr funktioniert, sollte das in der Regel vorhersehbar sein. Spätestens wenn der Hersteller den Support einstellt, sollte man sich eine neuen Software suchen. (Und in der Regel passiert es ja nicht, dass ein Hersteller heute die Software einstellt und morgen tut nichts mehr). Und für den Fall, dass du eh lieber mit dem Dateisystem arbeitest, bräuchtest du gar keine Software, sonder legst dir einfach so alle Verzeichnisse in Selbstverwaltung an.

Doch!
Das bezweifle ich eben. Es gibt endlos viele Beispiele von Kleinigkeiten, wo der Entwickler zu faul/zu latschig war. Nimm irgendeine Einstellung, die nicht der Default, aber die auch nicht persistent ist, weil der Entwickler sich die paar Zeilen für die Persistenz sparen wollte.

Meinetwegen hat ihm das eine halbe Stunde (eine sehr großzügige Annahme!) gespart, weil er mit Bindings usw. auf dem Mac nicht so vertraut ist.

Jetzt nimm an, die Software hat 10.000 Nutzer, von denen 10% Power-User nicht die Default-Einstellung nutzen wollen. Die müssen jetzt bei jeder Nutzung 2 Sekunden für einen zusätzlichen Mausklick aufwenden. Selbst wenn sie diese Funktion nur einmal werktäglich nutzen, sind das im Jahr pro Nutzer ca. 600 Sekunden, also 10 Minuten. Bei 1.000 Nutzern also 160 Stunden pro Jahr. 160 Stunden verschenkte Lebenszeit, damit ein Programmierer ½ Stunde eingespart hat. Und sowas begegnet mir an allen Ecken und Enden, bei praktisch jedem Programm zigfach.

Dass hier Ressourcen effektiv eingesetzt wurden, ist eine Illusion, die wie so oft nur entstehen kann, weil die externen Kosten ausgeblendet werden (können).
Ich traue keiner Software, deren Source Code ich nicht habe.

Duplikate vermeiden ist ein weiterer valider Grund. Oft habe ich ein und dieselbe Datei in mehreren Verzeichnissen. Beispiel: Je Unternehmen lege ich Dateien in Verzeichnissen ab, die ich dem jeweiligen Unternehmen gesendet habe. Und das ist noch ein Fall, bei dem ich absichtlich Duplikate angelegt habe. Oft ist das eher unabsichtlich durch hin- und er kopieren entstanden.
Devonthink dupliziert nur den Verweis auf die Datei, aber speichert diese nicht zweimal. Um Duplikate zu vermeiden und Übersicht zu behalten, ist das ein enormer Gewinn.
Wenn ich aus DT exportiere, entsteht eine Dateistruktur, wie sie an der Oberfläche von DT angezeigt wird.
Der einzige Nachteil, den ich erkennen kann, ist, wenn ich eine Datei direkt lösche, die in DT gespeichert ist, dann zeigt DT diese Datei weiter an, obwohl sie nicht existent ist. Passiert zum Beispiel, wenn ich in Pages ein Datei bearbeite, die ich unter "letzte Dateien" aufgerufen habe und dann durch Pages an einen anderen Ort verschiebe.

Ich weiß zwar nicht, ob du selbst Software Entwickler bist oder nicht, aber aus deiner Antwort lese ich heraus, dass du es eher nicht bist. Zumindest nicht für weithin eingesetzte Software.
Das hat nichts mit Faulheit zu tun. Das ist tatsächlich mit einer sinnvollen Ressourceneinteilung zu begründen. Ich erlebe das Tagtäglich. Und ja, ich kenne solche Nutzer wie du, die auch jeden noch so kleinen "Mist" konfigurierbar haben wollen. Aber am Ende tut man sich damit als Entwickler und als Anwender keinen Gefallen. Die Software, die das Unternehmen, in dem ich arbeite, herstellt, ist bis zum Erbrechen konfigurierbar. Der Effekt: Ein Großteil der Kundenanfragen resultiert daraus, dass man sich irgendwas so konfiguriert hat, dass am Ende irgendwas nicht mehr tut (und nein, dass hat nichts mit schlechter Software zu tun). Und in der Wartung ist solche Software einfach zum Kotzen. Die Software wäre schon viel weiter, wenn da nicht so viele überflüssige Konfigurationsschalter drin wären, die immer und überall bedacht werden müssen.
Und bei sowas wie den Ordnernamen ist das genau das selbe. Klar spart man sich vielleicht in der initialen Entwicklung bei manchen Sachen vielleicht nur ein oder zwei Stunden (aber es kann sich durchaus auch über Tage und Wochen hinstrecken für "Kleinigkeiten"), aber langfristig gesehen, ist es eine enorme Zeitersparnis, weil auch die zukünftige Wartung und Weiterentwicklung deutlich einfacher ist.
Als Anwender will man sowas natürlich nie hören. Ich kenne das nur zu gut. Anwender sind, meiner Erfahrung nach, bei Software immer nur auf ihren persönlichen Komfort beschränkt. Was tatsächlich langfristig sinnvoll ist, interessiert einen Anwender eigentlich nie. Natürlich will ich als Anwender alles genau so konfigurieren können, dass es genau für mich perfekt ist. Und natürlich ist das auch machbar, aber für welchen Preis? Das Ergebnis rechtfertigt den (langfristigen) Aufwand einfach nicht. Und dann ist es aus Sicht eines Softwareunternehmens auch vertretbar, wenn der Anwender eben nur zu 95% glücklich ist. Am Ende ist es auch für den Anwender besser, weil er eine bessere und stabilere Software bekommt.

PS: Versuche gar nicht erst, mit das auszureden. Dagegen bin ich mittlerweile immun. Denn aus Anwendersicht sind wir Softwareentwicklung immer nur die bösen Idioten

Wir arbeiten beim MacStammbaum-Paketformat auch intern mit solch identifiern, da es erheblich sicherer bezüglich zukünftigen Änderungen am Dateisystem ist. Wenn wir frei vom Nutzer vergebene Identifier für Dateien nutzen würden, hätten wir extrem viele Probleme: Zum Beispiel Sonderzeichen des Dateisystems ( / und : ) wie auch Probleme mit Kollisionen (gleiche Namen) und Groß-/Kleinschreibungs- sowie Längenprobleme. Bei von uns errechneten, zufälligen Identifiern verwenden wir nur ASCII-Zeichen, die höchstwahrscheinlich auch noch in kommenden Dateisystemen valide sind.

Es geht hier ja nicht um die Vergabe von Ordnernamen vom Benutzer, sondern um irgendwelche Apps/Prozesse, die solch unleserliche Ordnernamen vergeben. Und die Eindeutigkeit muss ja nicht auf Kosten der Lesbarkeit gehen. Was hindert die Entwickler, zu Beginn des Ordnernamens etwas Identifizierendes zu stellen und anschliessend die Eindeutigkeit zu erzeugen? Im Zweifelsfall doch nur die Tippfaulheit

Ich verweise mal auf meinen Thread auch wegen dieser langen UUIDs in den Verweisen/Links von Programmen wie Devonthink und Evernote. Als Ergebnis des Threads habe ich über "Yourls" meinen eigenen URL-Shortener aufgebaut. In diesen Short-URLs nutze ich nun meine Systematik.
(ab 13:27 Uhr)

Dazu muss man zuerst versuchen, die Datei zu schreiben. Ich hatte damals UNIX Epoch+PID+System-IP+fortlaufende Nummer verwendet (außer den eigenen Admins bekam das nie jemand zu Gesicht). Da wusste ich vorher schon, dass das eindeutig ist. Wozu dann noch testen? Hinzu kommt, dass man niemals einen Dateinamen nehmen darf, der in einer E-Mail drinsteht. Dazu fällt mir wieder Little Bobby Tables ein.

Zu glauben, man kann etwas über das System anhand von Dateinamen herausfinden, ist heutzutage eine Illusion. Und unter macOS gibt es zum Glück nicht auch noch eine Registry, die das von vornherein unmöglich macht.
Das würdest Du ohnehin nicht merken. Denn unterschieben ist fast immer das bereits vorhandene Daten ersetzt werden. Und außerdem müsstest Du im Grunde ziemlich oft machen. Also das was Schlangenöl schon seit Äonen versucht und dabei eine erbärmliche Trefferquote hat.
Ich weiß es einfach. Wenn ich eine alte Kündigung suche, dann tippe ich "Kündigung". Dieses Wort befindet sich zu 100% in allem, was damit zu tun hat. Ich kann noch weitere Suchbegriffe wie den Namen der Firma verwenden. Und den Zeitraum eingrenzen, und, und, und … Metadatensuche ist schon was feines.
Ich würde einfach nach Änderungsdatum sortieren. Und schwupps ist das älteste oben bzw. unten. Aber warum sollte ich das tun?

Das weiß ich schon besser als Du, dass ich das kann. Über man mache ich keinerlei Aussage.
Doch, ich merke das. Schon x-fach geschehen.

Ich weiß z.B. genau von allen Programmen, welche merkwürdigen Dateien an merkwürdigen Orten sie anlegen und zu verstecken suchen, um sich als lizenziert zu betrachten. Dieses Wissen kann sehr hilfreich sein.
Nö, nur systematisch. Viren etc. fange ich mir sowieso nicht ein.
Das ist ja schön für Dich. Das wiederum weiß ich eben absolut nicht.
Ja, bei solch simplen Dingen mag das ja so sein.

Mir geht es aber um viel komplexere Zusammenhänge. Querverbindungen zwischen philosophischen Ansätzen, die sich nur in der Parallelität des Gedankengangs erschließen, aber nicht in spezifischen Begriffen, nach denen ich suchen könnte, z.B.

Oder die Band, von der ich schlicht komplett vergessen habe, dass es sie gab und ich deren Musik toll fand.

Oder ein Programm, was ich brauche. Ja, oft erinnere ich nicht einmal die Namen der Programme, die ich dringend benötige. Dazu sind es zu viele. Wären die nicht in Ordnern sortiert, wäre ich verloren.
Das hat damit doch nichts zu tun. Die beiden Dateien, deren Querverbindung sich durch die Ablage im selben Ordner zeigt, können in ihrer Entstehungszeit beliebig weit auseinanderliegen. Zeitliche Ordnung hilft da überhaupt gar nicht weiter.
Für mich ist das eines der elementarsten Arbeitsprinzipien überhaupt. Warum Du das tun solltest, kann ich Dir nicht sagen. Wenn für Dich eine andere Arbeitsweise gut funktioniert, ist doch alles wunderbar. Nur verallgemeinere das bitte nicht und erkläre mir, Ordner seien stets überflüssig. Für mich sind sie absolut unersetzlich.

Jedem das seine. Du glaubst ja auch, Swift sei eine akzeptable Programmiersprache.

Interessante Diskussion, aus der man durchaus Einiges lernen kann.
Wollte ich nur mal sagen.
Es ist bei mir schon länger her (20 Jahre), seit ich Software geschrieben habe, und daher habe ich als User die Tendenz, Programmierern und Software-Architekten wohl eher leichtfertig Dinge wie Schlampigkeit oder zu wenig Motivation für Userorientierung wenn nicht gar begrenzte Kompetenz zu unterstellen. Sowas mag es zwar auch geben, doch jetzt merke ich zwei Dinge:
1. Haben sieh die Anforderungen an Software in den letzten zwei Jahrzehnten doch deutlich geändert (sind komplexer geworden) und
2. sind Aspekte dazu gekommen, die wohl wirklich faktisch zu Kompromissen hinsichtlich Usability/Understandability und anderen Anforderungen wie Tempo, Datenschutz und so weiter nötigen.

Wie weit, kann ich nicht beurteilen. Ich selber bevorzuge meine Ordnungen und lasse daher nicht mal Software, die meine Bilder sortieren will, an meine selbstgebaute Ordnerstruktur - sonst würde ich nie mehr wieder was darin finden, denn sie bildet meine Art der Suchstruktur ab. An Verschlagwortung für Abertausende Dateien denke ich nicht im Traum
Immer verstehe ich jetzt, dass es auch andere Kriterien gibt...

Und ich habe mich auch immer gefragt, warum moderne Entwicklungswerzeuge für ein einfaches Hello Word gleich mehrere MB auf dem Massenspeicher verbraten, bzw. warum ein modernes OS locker 10 GB mit Millionen an Dateien belegt. Danke also für den Einblick in meine eigene Sentimentalität, die gelegentlich dazu tendierte nach dem Motto "früher war alles besser" OS9 für das Optimum zu halten (wenn es Multitasking und mehrere User beherrscht hätte. Der Fortschritt ist also mit Komplexität und Ausdifferenzierung auch in dieser Technik korreliert - was eigentlich ja logisch ist.
Also werde ich jetzt etwas weniger über die Eigenheiten moderner Software fluchen

Also wenn ich mir meine Dateien in Devonthink so anschaue, kann ich über die Parallelität der Gedankengänge sinnieren, ohne dass mir eine einzige UUID über den Weg läuft.

Ich bin, allerdings im akademischen Kontext, was Deine Vorurteilesogleich bestätigen wird.
Doch. Mit Denk- und/oder Handlungsfaulheit.
Ich habe Dir doch vorgerechnet, dass diese Begründung nur funktioniert, wenn Du die für Dich als Programmierer externen Folgen ignorierst.
Der „kleine Mist“ summiert sich im Laufe der Zeit eben zu einem großen Misthaufen.

Ich gebe Dir ein ganz simples Beispiel von Apple selbst, im Finder.

Ich nutze dort sehr regelmäßig die Spotlight-Suchfunktion, aber die Dinge, nach denen ich suche, bringen es mit sich, dass ich fast immer die Option Systemdateien einschließen wählen muss. Diese Einstellung ist aber nicht persistent. Ich muss also bei jeder einzelnen Suche erst auf das Plus-Zeichen für Suchoptionen klicken, dann im linken Popup Systemdateien wählen und dann im rechten Popup einschließen. Wenn ich das schnell mache, dauert das 5 Sekunden (gerade gestoppt). Wenn ich auch nur 6 mal am Tag suche (und das tue ich mindestens), verliere ich durch die fehlende Persistenz eine halbe Minute. Im Jahr sind das 3 Stunden. In den 15 Jahren, seit es Spotlight gibt, sind es 45 Stunden.

Ich habe 45 Stunden meines Lebens verloren, weil es die fucking Finder-Programmierer nicht fertiggebracht haben, diese Einstellung persistent zu machen – was jemanden, der sich mit Bindings auskennt, ein paar Minuten kosten würde. Und ich bin ein einzelner Anwender. Jetzt multipliziere mit den vielleicht auch nur 10.000 Anwendern weltweit, denen es so wie mir geht, und dann wage es nochmal, mir zu erzählen, das sei ein sinnvoller Einsatz von Ressourcen.

Das ist Unfähigkeit von Programmierern, und sonst gar nichts.
Den Anwendern täte man einen Gefallen.
Wäre in dem Finder-Beispiel garantiert nicht der Fall, da die Einstellung ja deutlich sichtbar ist und bleibt und auch nur für mehr Suchergebnisse sorgt.
Doch, das hat ausschließlich mit schlecht konzipierter Software zu tun, wenn das zum Problem wird.
Na und? Wenn das die Sache für die Anwender erleichtert, dann müssen die Programmierer halt kotzen (oder die Architektur gut genug konzipieren, dass das unnötig ist). Besser, der Programmierer kotzt eine Stunde als die Anwender 10.000 Stunden …
Lass mich raten: Ihr verwendet keine Bindings und vielleicht nicht einmal die MVC-Architektur?
Macht’s zur Abwechslung halt mal besser.

Falls Du dich damit auf meinen davorliegenden Beitrag beziehst: Zweifellos, aber der Beitrag war ja eine spezifische Antwort auf die These von PaulMuadDib, man solle generell einfach aufhören in Dateien und Ordnern zu denken und hatte nichts mehr mit UUIDs zu tun.

In der GUI von DEVONthink finden sich ja sehr wohl wiederum Dateien und Ordner, wenn auch nicht 1:1 im Dateisystem abgebildet.

Die zugehörigen UUID-Ordner im Dateisystem würden in diesem Fall nur relevant, falls DEVON Technologies irgendwann die Grätsche macht. Oder wenn ich mit einem anderen Programm auf denselben Datenbestand würde zugreifen wollen.

Weia
Was ich damit sagen wollte, ist Folgendes: Wenn ich mit Devonthink usw. arbeite, ist es weitgehend irrelevant, wie DT die Dateien intern in der Datenbank ablegt. Ich sehe ein Dateisystem in DT, welches mir mit Tagging, Duplikate-Erkennung, einer Darstellung ähnlich dem von Mail usw. die Arbeit erleichtert.

Die UUIDs sehe ich erst dann, wenn ich im Dateisystem von DT wühle, was ich gar nicht möchte und sollte, was auch normalerweise gar nicht sichtbar ist. Problematisch wird es nur, wenn ich eine Datei aus einem Programm über "Benutzte Dateien" aufrufe, welches aber innerhalb von DT abgespeichert ist. Diese Datei speichere ich nun woanders oder ändere den Namen. Hier kommt DT durcheinander.

Die UUIDs sehe ich zudem, wenn ich Verweise erstelle. Hier stört nur die Länge des Links. Dafür habe ich einen Link-Shortener erstellt.

Falls DT irgendwann die Grätsche macht, werde ich sämtliche Dateien exportieren. DT wird die Ordner-Struktur mit allen Dateien sauber erstellen, wie es sein sollte. Danach kann ich DT löschen.

Falls ich aber jetzt schon die MacOS-eigene Ordnerstruktur habe möchte, weil ich oft außerhalb von DT auf die Dateien zugreife, dann importiere ich die Dateien nicht nach DT, sondern indiziere diese nur mit DT. Auch das funktioniert gut. Die UUID gibt es dann bei Verweisen allerdings trotzdem.

Also in der Tat sollte man aufhören, darüber nachzudenken, wie Programme wie DT (oder MacJournal) Dateien und Ordner ablegen. Ansonsten denke ich selbst immer in Dateien und Ordner. Daher mag ich keine Fotobibliotheken wie Lightroom sie anlegt (Struktur über Stichwörter) oder eine Mailbox von Google (keine Ordner, nur Tags).

Also bis auf die Länge der Verweise/Links sehe ich jetzt das Problem nicht. Da ist nichts unsauber programmiert, da kostet nichts unnötig Zeit.

Ja, dass ein- und dasselbe Dokument von unterschiedlichen Programmen bearbeitet wird, ist so ein Punkt, wo das Dateisystem auf macOS-Ebene wichtig wird. Ist bei mir zwar kein Problem bei den Daten, die ich in DEVONthink speichere, aber allgemein schon, da ich sehr oft verschiedenste Programme auf ein- und dasselbe Dokument „loslasse“.
Das ist ein guter Hinweis, danke! Diese Möglichkeit verliere ich leider immer wieder aus den Augen.
Eben, und das war ja mein zentraler Punkt in meiner Antwort auf PaulMuadDib (der gerne den Bilderstürmer gibt ).

Falsch, Du hast 45h Deines Lebens verloren, weil Du Dich weigerst das Terminal zu nutzen, wie das alle anderen Power User tun. Deshalb besteht auch nicht wirklich die Notwendigkeit den Finder anzupassen.

Wie gesagt, Du machst Dir was vor.
Wieviel Zeit geht dabei drauf? Vor allem bei dem ganzen Zeug, was in ~/Library liegt? Denn Du musst ja im Grunde jede einzelne Datei des ganzen Systems analysiert haben.
Ok, dann mache mal ein konkretes Beispiel, wie du sowas mithilfe von Ordnerstrukturen und Dateinamen anlegst. Und ich vermute, das musst nur Du durchblicken, und nicht noch ein anderer.

Wenn die App eine Exportfunktion hat oder die Datei bei Bedarf auf dem Desktop anzeigen lässt, wie das bei iTunes trotz der aufgeräumten Ordnerstruktur der Fall ist, wäre das Verstecken in kryptischen Ordnern sicher das geringste Problem.

Wenn aber wie in Books in Catalina die Datenstruktur noch nicht mal einheitlich ist (Unterschiedliche Ablage von eBooks und Audiobooks) ohne Exportmöglichkeit und ohne Anzeigemöglichkeit auf dem Desktop und ohne Beeinflussung des Ablageortes, ist das für uns Nicht-Poweruser - die nicht Terminalbefehle aus dem Hut zaubern können - eine Erschwernis, die das Programm als nicht brauchbar abstempelt.

Dipl.-Psych. Paul Muad Dib, 1A Ferndiagnosen aller Art
So gut wie keine. Ich habe dafür kleine Helferlein, auch Programme genannt.
Ich weiß jetzt nicht genau, auf welchen der Fälle Du dich mit sowas beziehst.

Aber um mal das simpelste Beispiel mit den Programmen zu nehmen: Ich nutze davon Hunderte und kann mir insbesondere wenig intuitive Namen oft nicht merken.

Es gibt z.B. ein Programm für diverse Farbberechnungen mit dem ungemein intuitiven Namen CT&A. Obwohl ich das Programm des öfteren verwende, vergesse ich diesen blödsinnigen Namen immer wieder. Würde ich ihn in einer ungeordneten Liste von Hunderten Programmen in /Applications/ finden? Wenn überhaupt, dann nur nach langem Suchen.

Finde ich ihn unter den 17 Programmen in /Applications/Wissenschaft/Physik/Kolorimetrie/ schnell? Aber sicher!
Stimmt, auf meinem Computer muss nur ich durchblicken. Nicht sonderlich originell, oder? Wenn aber jemand anders an meinem Mac arbeiten würde und Programme zur Farbphysik bräuchte: die würde er so ziemlich schnell finden. Würde er CT&A direkt in /Applications/ bemerken, ohne erst jedes einzelne von Hunderten von Programmen zu starten? Wohl kaum.

weia:
Exkurs: endlich noch jemand der sich dem Swift-Virus entziehen konnte. Swift ist für mich ein Rückschritt in die prozeduralen Programmiersprachen, ob OO oder nicht. Ich werde nicht verstehen, warum Apple die wunderbare Kreuzung von C mit Smalltalk wieder in die Tonne tritt. Das Late-Dynamik-Binding von Objective-C ist einfach genial und hat NextStep zu einem herausragenden System gemacht. Nur weil David Lattner sich zu, Johny Ive der Programmiersprachen machen wollte?
Ärgerlich nur, dass man nur noch mit Swift Chancen hat einen neuen Job zu finden - weil Objective-C auch vom Markt verkannt wird.
Exkurs Ende

Ich möchte meine Daten auch selbst verwalten können und sortieren können. Gerade als Softwareentwickler. Dateien zu einem Projekt gehören in ein Projektverzeichnis, egal was für Daten das sind. Schon allein wegen git...

Da rächt sich leider bitter, dass Steve Jobs zu diesem Zeitpunkt schon tot war.

Oft wurde Jobs ja mit einer gewissen Häme vorgehalten, im Gegensatz zu Bill Gates könne er nicht programmieren. Aber Jobs hatte – was für einen CEO weit wichtiger ist – eben dieses untrügliche Gespür für herausragende Technologien und hätte Swift niemals durchgewunken.

Dass Lattner Swift durchboxen konnte, liegt einfach daran, dass fast die gesamte Riege von Entscheidungsträgern bei Apple zu diesem Zeitpunkt aus BWLern und Marketing-Fuzzis ohne technisches Verständnis und mit, berauscht vom Erfolg des iPhones, starkem Hang zum Mainstream bestand. Craig Federighi war nach dem, was ich höre, die Ausnahme, konnte sich allein gegen die anderen aber nicht durchsetzen.

Ich würde mich nicht wundern, wenn sich retrospektiv Swift als die nachwirkendste Fehlentscheidung der Cook-Ära herausstellen sollte.

Woran ich gar nicht denken darf, ist, dass ohne diese Fehlentscheidung eines technisch verständnislosen Managements aufgrund von Apples Bildungsinitiative jetzt rund um die Welt junge Menschen in (einer dann wohl weiterentwickelten Version von) Objective-C geschult würden.

Mehr braucht man nicht lesen. Da du ja nach eigenen Angaben kein Vollzeit-Software-Entwickler bist (was auch immer du mit im akademischen Kontext meinst), hast du nicht das nötige Wissen und die Befähigung, meine Aussage (die die Aussage eines langjährigen Vollzeit-Software-Engineers ist), so zu beurteilen. Denn das ist lediglich das Urteil eines angepissten Anwenders, keinen Deut mehr. Und ja, ich bin gerade auch etwas genervt, da hier jemand, der keine Ahnung vom Fach hat, und scheinbar alles hier in dem Thread ignoriert, meint mir vorschreiben zu können, wie ich meine Arbeit zu tun habe.
Ich bin dann mal raus hier.

Na, was kann ich wohl damit meinen? Ich schreibe (primär, nicht ausschließlich) Software für Forschungszwecke, nicht zum kommerziellen Verkauf.
Bellt da ein getroffener Hund?

Ich wüsste nicht, warum mir dieses Wissen fehlen sollte, bloß weil die Software in einem anderen Kontext entsteht. Sie ist deshalb ja nicht weniger komplex, und die Anforderungen an ihre Robustheit sind eher höher.
Ein angepisster Anwender könnte schwerlich beurteilen, mit welchem Zeitaufwand sich welche Probleme mittels korrekt eingesetzter Bindings erledigen ließen.
Menschen, die wissenschaftlich arbeiten, verstehen nicht, was sie tun?
Ich schreibe Dir überhaupt nichts vor. Von mir aus lädst Du alle Müh und Last zugunsten Deiner eigenen Bequemlichkeit auf dem Rücken Deiner Nutzer ab. Aber dann musst Du auch mit deren Kritik leben.

Objective-C war immer ein schwerer Designfehler, die Linearkombination der Nachteile von C und Smalltalk. Smalltalk war ideal für diese Art von Softwareentwicklung, weil hier Duck Typing mit einer schwachen Typisierung und möglichst vielen Laufzeitchecks kombiniert wurde. Dazu empfehlenswert sie die Artikel und Bücher von Kent Beck. C ist passt dazu überhaupt nicht. Wenn man C mit dem ähnlich altem Ada83 vergleicht, dann sieht man einmal wie schlecht C entworfen worden war.

Insofern ist die Entscheidung Objective-C zu entsorgen und durch eine bessere Programmiersprache zu ersetzen sehr zu begrüßen. Ob Swift nun das Optimum ist, darüber kann man vortrefflich streiten, besser als Objective-C ist es definitiv.

Wir müssen das nicht neu aufwärmen. Ich weiß, dass Du nichts von Objective-C hältst. Und Du weißt, dass ich Objective-C für einen genialen Wurf halte, insbesondere aber Swift für ein intellektuelles Desaster. Da werden wir beide in diesem Leben den anderen auch nicht mehr bekehren. Im nächsten vielleicht.

Naja, da habe ich gestern erstmals erlebt, dass dann der 2. Download nach Abschluss wieder verschwindet. War nicht sicher, ob in verschiedenen Mails die exakt gleiche Datei verlinkt war. Aber ist dies der Fall, wird neuerdings anscheinend die Datei nur 1x in den Downloads abgelegt, egal, wie oft man diese lädt, was ich aber eh gut finde. Sind die unterschiedlich, nur mit gleichem Namen, wird wohl weiterhin nummeriert.

Es gibt objektive Gründe, weshalb Objective-C für diese Art von Softwareentwicklung eine schlechte Wahl war und ist. Swift versucht das zu reparieren, um die Produktivität bei der Softwareentwicklung zu verbessern. In der Vergangenheit gab es noch das Argument, dass reines Smalltalk langsame Programme bedingte, aber mittlerweile mit JIT Compiler ist das Argument nicht mehr wirklich valide.

Und über die Probleme von C muss man nicht mehr sprechen. Wenn die Betriebssysteme nicht so stark davon abhängig wären, könnte man es sofort entsorgen.

Na, wenn das tatsächlich zuverlässig funktioniert, dann wäre das doch sogar eine sehr intelligente Lösung …

Hihi, Du kannst es nicht lassen.

Schon klar, Deine Gründe sind objektiv, meine fehlgeleitet oder was auch immer.

Fehlt nur noch, dass Du behauptest, Pascal sei gelungener als C, dann springe ich von der nächsten Diskursbrücke.
Das stimmt. Es lohnt sich einfach nicht, über non-existente Dinge zu reden.
Tja, warum sind sie das nur? <grübel/>

Pointerarithmetik, fehlende Out-of-Bounds-Checks, Formatstring Unfug bei den IO-Funktionen, fehlende Typsicherheit bei den Casts, fehlende Typsicherheit bei Pointer generell, keinerlei Resourcen Tracking (Objective-C hat das GC relativ spät bekommen und RC nur per Konvention), … sind objektive Nachteile von C, die Objective-C geerbt hat.Ich schrieb von Ada und nicht Pascal, der Unterschied ist gewaltig.Das sind historische Altlasten und wohl nicht mehr wegzubekommen.

Jaja, objektiv. Aus Deiner Sicht.

Ehrlich, das ist an dieser Stelle müßig. Jemand, der Pointerarithmetik als Nachteil empfindet (objektiv natürlich), hat völlig andere Vorstellungen von einer gelungenen Programmiersprache als ich. C ist sowas wie ein standardisiertes High Level Assembler, und genau dafür schätze ich es. Das kombiniert mit OO für Modellierungen in einer einzigen Sprache ist für mich ein Programmierschlaraffenland. Für Dich halt offenkundig nicht.
Unbestritten. Ich hätte Dir das nur auch noch zugetraut.

Ich kenne keinen erfahrenen Softwareentwickler, der Pointerarithmetik in einer Hochsprache gut fände. Die Literatur ist voll von Kritik daran. Für was meinst Du sei das gut?

Mein Punkt ist doch gerade, dass ich C nicht als reine Hochsprache ansehe, sondern als einen (aus meiner Sicht äußerst gelungenen) Zwitter aus Hochsprache und Maschinensprache. Ich möchte auf die damit verbundenen Möglichkeiten nicht verzichten. Und ich sehe in diesen Möglichkeiten (und nicht etwa in „Altlasten“) auch den Grund, warum praktisch alle relevanten Betriebssysteme in C geschrieben sind.

Für alles „Höhere“ nehme ich dann den Smalltalk-Teil aus Objective-C.

Übrigens: In welcher Sprache wohl ist das supderduperhippe Swift geschrieben? In C/C++. Na sowas …

Aber sollten wir das jetzt nicht wirklich mal auf sich bewenden lassen?