4 ms·

> You can conceivably copy-paste a file you've been working on in one app into another, but what if you want to retrieve a file you last interacted with a year

by zrm 8y ago

> You can conceivably copy-paste a file you've been working on in one app into another, but what if you want to retrieve a file you last interacted with a year ago? How will you find that file? With searchable tags, or whatever other thing you can come up with which is better than trying to remember a file path. But that doesn't mean you should get rid of file paths, because they're each good for different things and there is no reason you can't have both. Here's another example. On a desktop you can open a static web page from a local .html file along with all the associated content. You'll have a directory containing an HTML file, maybe some associated .png, .gif, .webm or .js files and so on. A complicated one may have its own hierarchy because it's useful within the context of that document. Then that HTML file is going to have the names of the other files in it, including their relative paths if they're in subdirectories. The same thing can happen with InDesign documents or any other composite document like that. Now how does the user find that HTML file a year later? Using some kind of tags or search function. But the way the HTML file then finds its associated pictures/scripts/videos is using something like filesystem paths. The alternative would be to combine them together into some kind of tarball, which is what some things do (like PDF), but then that's worse -- how do you edit a photo which is embedded in a PDF? Your average image editor will either not support it or will be inclined to do something horrible like rasterize the whole PDF first.

darkpuma 8y ago
As I've detailed here (https://news.ycombinator.com/item?id=19523901 https://news.ycombinator.com/item?id=19523901), the idea is not to remove the traditional hierarchical file system from the low level, but rather to remove trace of it from nearly all human interaction. At the least, interaction with it should be opt-in, not opt-out. You're touching on a broader subject than file organization though, and that is humanist software design. Your static web page example is a good example. That's not humanist software design, it's design that serves the computer. When you save a web page you get an html file and a directory next to it that contains the images, css, etc of that webpage. The user is now burdened with keeping that html file and resource directory next to each other for the rest of the lifespan of that [meta-]file. Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.) This unburdens the user; they no longer have to worry about keeping those files next to each other when copying it, sending it to other people, etc. Epubs are humanist design (and not only for this reason, but I'll save that for another discussion.) Of course inside that epub is a hierarchy of files. And that's fine. A hierarchy of files serves the ebook reader well. While strict hierarchies are poor for user interaction, they're great for software. The details of a file format need not be humanist because the user is not meant to pick it apart. Of course there may be perfectly valid and common use-cases for the user to pick it apart, to pull images out of it for instance. Software that facilitates pulling data out of documents, into a format that is generally useful to the user, is humanist. Consider your common desktop web browser for instance. It allows the user to easily pull an image out of a webpage by right clicking on it and saving it, or perhaps dragging the image out of the browser onto their desktop, or similar modes of interaction. The user needn't save the entire webpage, then poke through a directory filled with numerous files looking for the image they wanted. (At least, not unless the website and browser are conspiring to behave in a manner that is hostile to the user, for example by blocking right clicking....) PDFs and PDF readers are shoddy in numerous ways of course, and strict hierarchical file management has done little to alleviate that.
- zrm 8y ago
  > the idea is not to remove the traditional hierarchical file system from the low level, but rather to remove trace of it from nearly all human interaction. But that's the issue. You can make it easier to use tags, you can make it so that they are what most people use most of the time, but you still want everything to be able to use paths, in a way which is still as universal and intuitive as possible, so that it still works properly everywhere when you do have a good reason to use them instead. > Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.) Here's something even better -- what macOS does with applications. You look in /Applications and see a bunch of programs. Those are really directories with the application's files in them, whose names are the names you see but with a .app extension. If you click on one, you don't see what's in the directory, you cause the application to open. But you still can see what's in there, by using the actual path with anything that accepts file paths, and that is still useful. Because sometimes there is a .plist file in there or something else you want to modify, or you just want to see what's really there. This is better than a zip file because it's still native. You get the behavior you want, but if you want to see or modify what's in there, you don't need to use a special program or go through the extra steps to unzip the file and zip it again, you just access it using the real path. Windows at one point did somewhat the opposite and exposed the contents of .zip files as folders, but that doesn't seem to work as well, e.g. modifications are not permitted or are inefficient or have other issues because you have to repack the whole file with every write.
  - darkpuma 8y ago
    The way MacOS handles Applications is indeed humanist, but there is nothing about that user interface that intrinsically relies on strict file hierarchies. Furthermore, the implementation of it isn't generalized. The substance of what I think you're getting at is record-oriented files systems, which I consider orthogonal to the matter of tagging vs strict hierarchies. With a record-oriented files system, files are no longer seen by the OS as mere byte streams, but actually have meaningful structure. It needn't be implemented carelessly like Windows with it's zip support in Explorer. It's a very compelling idea, but as I said, orthogonal to the matter of hierarchies or tagging. Say for instance you want to edit the .plist file of Blender.app. Where is Blender.app? Probably at /Applications/Blender.app but maybe it's in /Users/zrm/Applications/Blender.app To dive into that file/directory, you must first find it. How the user is meant to find it is the question that needs to be addressed. That's a simple example of course because there are only two likely locations for it (and the later is unlikely), the file/directory you're looking for has a name you remember off the top of your head, and because either of those directories probably has no more than a few hundred entries (probably a fraction of that.) In this case the user of a hierarchical system doesn't run into much trouble because the situation is virtually ideal, but even so a tagging system would have simplified the query. The further you get from ideal circumstances, the larger the gap between tag systems and hierarchical systems grows. Additional thoughts on record oriented file systems: one example is Files-11 from VMS. An interesting property of Files-11 is that it allows files and directories to have multiple parent directories, which is similar to Unix's hard links except that directories, not only files, are allowed to have multiple parents. This gives the system the same expressive power of tags (consider each full path a file can be found at to be a tag on that file.) This allows all of your books to simultaneously be in /Books/ while still allowing you to have them in other locations like /School/cs/cs101/textbook.pdf However a system capable of expressing these relationships is the easy part. The important part is giving the human users a clean user experience, allowing them to take full advantage of the power of such a system without requiring them to manually create and maintain a web of nested links.

by zrm 8y ago

darkpuma 8y ago

As I've detailed here (https://news.ycombinator.com/item?id=19523901 https://news.ycombinator.com/item?id=19523901), the idea is not to remove the traditional hierarchical file system from the low level, but rather to remove trace of it from nearly all human interaction. At the least, interaction with it should be opt-in, not opt-out. You're touching on a broader subject than file organization though, and that is humanist software design. Your static web page example is a good example. That's not humanist software design, it's design that serves the computer. When you save a web page you get an html file and a directory next to it that contains the images, css, etc of that webpage. The user is now burdened with keeping that html file and resource directory next to each other for the rest of the lifespan of that [meta-]file. Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.) This unburdens the user; they no longer have to worry about keeping those files next to each other when copying it, sending it to other people, etc. Epubs are humanist design (and not only for this reason, but I'll save that for another discussion.) Of course inside that epub is a hierarchy of files. And that's fine. A hierarchy of files serves the ebook reader well. While strict hierarchies are poor for user interaction, they're great for software. The details of a file format need not be humanist because the user is not meant to pick it apart. Of course there may be perfectly valid and common use-cases for the user to pick it apart, to pull images out of it for instance. Software that facilitates pulling data out of documents, into a format that is generally useful to the user, is humanist. Consider your common desktop web browser for instance. It allows the user to easily pull an image out of a webpage by right clicking on it and saving it, or perhaps dragging the image out of the browser onto their desktop, or similar modes of interaction. The user needn't save the entire webpage, then poke through a directory filled with numerous files looking for the image they wanted. (At least, not unless the website and browser are conspiring to behave in a manner that is hostile to the user, for example by blocking right clicking....) PDFs and PDF readers are shoddy in numerous ways of course, and strict hierarchical file management has done little to alleviate that.

zrm 8y ago
> the idea is not to remove the traditional hierarchical file system from the low level, but rather to remove trace of it from nearly all human interaction. But that's the issue. You can make it easier to use tags, you can make it so that they are what most people use most of the time, but you still want everything to be able to use paths, in a way which is still as universal and intuitive as possible, so that it still works properly everywhere when you do have a good reason to use them instead. > Consider instead the epub format. It too is one or more html files with images, css, etc. However unlike the traditional local static copy of a web page, all of those files are zipped together and stored as a single file (an epub is a glorified zip file with a special file extension. You can extract them with `unzip`.) Here's something even better -- what macOS does with applications. You look in /Applications and see a bunch of programs. Those are really directories with the application's files in them, whose names are the names you see but with a .app extension. If you click on one, you don't see what's in the directory, you cause the application to open. But you still can see what's in there, by using the actual path with anything that accepts file paths, and that is still useful. Because sometimes there is a .plist file in there or something else you want to modify, or you just want to see what's really there. This is better than a zip file because it's still native. You get the behavior you want, but if you want to see or modify what's in there, you don't need to use a special program or go through the extra steps to unzip the file and zip it again, you just access it using the real path. Windows at one point did somewhat the opposite and exposed the contents of .zip files as folders, but that doesn't seem to work as well, e.g. modifications are not permitted or are inefficient or have other issues because you have to repack the whole file with every write.
- darkpuma 8y ago
  The way MacOS handles Applications is indeed humanist, but there is nothing about that user interface that intrinsically relies on strict file hierarchies. Furthermore, the implementation of it isn't generalized. The substance of what I think you're getting at is record-oriented files systems, which I consider orthogonal to the matter of tagging vs strict hierarchies. With a record-oriented files system, files are no longer seen by the OS as mere byte streams, but actually have meaningful structure. It needn't be implemented carelessly like Windows with it's zip support in Explorer. It's a very compelling idea, but as I said, orthogonal to the matter of hierarchies or tagging. Say for instance you want to edit the .plist file of Blender.app. Where is Blender.app? Probably at /Applications/Blender.app but maybe it's in /Users/zrm/Applications/Blender.app To dive into that file/directory, you must first find it. How the user is meant to find it is the question that needs to be addressed. That's a simple example of course because there are only two likely locations for it (and the later is unlikely), the file/directory you're looking for has a name you remember off the top of your head, and because either of those directories probably has no more than a few hundred entries (probably a fraction of that.) In this case the user of a hierarchical system doesn't run into much trouble because the situation is virtually ideal, but even so a tagging system would have simplified the query. The further you get from ideal circumstances, the larger the gap between tag systems and hierarchical systems grows. Additional thoughts on record oriented file systems: one example is Files-11 from VMS. An interesting property of Files-11 is that it allows files and directories to have multiple parent directories, which is similar to Unix's hard links except that directories, not only files, are allowed to have multiple parents. This gives the system the same expressive power of tags (consider each full path a file can be found at to be a tag on that file.) This allows all of your books to simultaneously be in /Books/ while still allowing you to have them in other locations like /School/cs/cs101/textbook.pdf However a system capable of expressing these relationships is the easy part. The important part is giving the human users a clean user experience, allowing them to take full advantage of the power of such a system without requiring them to manually create and maintain a web of nested links.