Excellent article, especially the detail to which it goes into how TRON handles files. This is pretty cool:
BTRON’s core idea was that the user-visible primitive on a desktop computer shouldn’t be a file or the application, but the typed document part. In other words, a block of content with a stable identity and a declared type. Parts can contain other parts, and the same mechanisms that embed a figure in a report can also embed a report in a workspace, meaning that there was no special case for a top-level file.
This model could be found across the interface as well, and you can browse a container in 1B/V3 and see each entry carries its type in parentheses after the name. For example, a document called 中国・韓国料理ガイド（図形）, meaning “Chinese and Korean Cuisine Guide (Graphics)”, describes this file as an image. In comparison, DOS would have given you an extension.
…but I’m curious as to how BTRON handled multiple file versions (backups, revisions, etc) if there’s not a top-level file.
Imagine there was no Explorer or Finder, and the only way you accessed files was through the apps that use them.
There’s still bytes on disk, but they are accessed as documents not files.
Which is how most Android and pretty much all iOS apps do it.
