Comment by JulianMorrison | Hacker News Reader

Comment by JulianMorrison | Hacker News Reader

Parent Full thread

Hierarchical filesystems are primitive ops. How you use your filesystem, that's a layer above - and a lot of it is convention not necessity, defined in the age of the Apple beige toaster and preserved by generations of don't-make-me-think. File, save, save-as: those are older than the commodity hard drive.

Lets imagine different conventions. As soon as you start typing it puts a file in $HOME/Documents (or a configurable alternative). If the application is amenable to guessing a title (like the first entry in Heading 1), then it uses that, otherwise it goes with the usual "untitled". The menu ops are File -> Open, File -> Save, File -> Save a copy, File -> Set name and File -> Move. The last file opens if you stop and restart. Every single operation gets lazy-queued for flush to disk on an activity log (more than just auto-save: preserve every undo-able op). Save means "commit my changes to the canonical copy and clear the activity log".

All of those still use the hierarchical file system. They just use it in a way that makes modern sense.

What if a box were provided near the top of the document with the document's current name? To rename the file you simply type the new name in the box.

Users should never really have to worry about saving. Google Docs does a good job of keeping documents saved without any need for user intervention.

A box with a name would be good, but you miss one important function of saving I took pains to preserve: it is the action which turns tentative changes to the file into permanent ones. You want to preserve those tentative changes, but you don't want to put them in the actual file until the user commands it.

True, with current software you don't want to save tentative changes but the only reason for that is that your "undo" history is lost the instant you close a program. If you could undo changes through the entire history of the document explicitly saving becomes pointless.

That works for a Word document, but what if you were editing a PHP file? You neither want your changes to be immediately applied while they aren't finished, nor can the PHP interpreter handle a special format with embedded undo.

Or, lets suppose you just log the undo in a hidden file alongside the original. Imagine you've edited a lot of files. All that eternal undo would pile up, and you'd end up with gigabytes wasted on useless undo logs. Plus plenty of stranded logs from moved files.

No, the ability to save, to not save yet, and to abandon the undo - those are useful features.

Reply on news.ycombinator.com