When I first started using computers, I did so on Microsoft Windows 95. The first applications that I used were Netscape Navigator and MS Paint, as well as a fe

When I first started using computers, I did so on Microsoft Windows 95. The first applications that I used were Netscape Navigator and MS Paint, as well as a few games. Being a child when I was introduced to computers, I did not have any notion about what was going on inside of the computer at all. All I knew was that there was a screen, a mouse and a keyboard, and that I could click on things on the screen and I could type on the keyboard. The first time I was confronted with the notion of a file was certainly when I had painted something in MS Paint and I had clicked the save button. I think I had been told to not click "My Computer", which makes sense -- you don't want a child to accidentally move, delete or rename files on your computer. Hence I had no notion of the file system. All that was know to me was the desktop, the start menu, and a select few programs accessible through either icons on the desktop or in the start menu. I had played a couple of games on the computer, and in those I could save the game and then the next time I could resume the game someplace near to where I had last been -- or rather, I could have my father help me resume the game. So when I managed to save the painting I sort of expected that it would just show up on screen the next time I started MS Paint. When it didn't I was a befuddled for a moment but I just concluded that I didn't understand what had happened and didn't give much more thought to it. I think this is pretty typical of how most children treat situations that confuse them. This is user level 0. You are able to move the cursor and to type a little bit on the keyboard and to run some specific programs, but that's it. During the next few years I learn how to work with files in MS Paint and other specific applications. However, not all files are equal. If I try to open a file that was made in one application with another application it will often either result in an error message or in garbage on the screen. This TIED my notion of a file to specific programs, and to the content that is shown on screen for the LONGEST time. It is a bit difficult to explain what I mean here but I think that to the majority of the population of a whole, this is what a file is to them. They view a file as an icon that you can open in a SPECIFIC program. And they call that file a "<name of program> file", or they call it by the extension, but they have no idea, or they have the wrong idea, about what is the contents of the file. If you give a regular Windows user two files which are both named say .dat, (a commonly used generic file extension for data,) then they will think that those two files necessarily must be of the same kind "somehow" and that they are to be opened, both of them, with some specific, unknown program. This is bad and harmful in my opinion. Likewise, I was quite confused for the longest time about "My Documents" and "My Pictures". I was confused by why things were being put in "My Documents" by default when those things were not things that I considered to be "documents". Furthermore it was quite mystical to me for a long time how "My Computer" could be on the desktop at the same time as my desktop was under a folder that was within "My Computer" itself. This however is not a huge deal. Just yet another thing that didn't make sense to me while I was trapped with the graphical representation of the system. The paper is arguing a point of view that a different abstraction should be used than the hierarchical file system. I agree to some extent but not for the same reason perhaps. I think that the desktop metaphor is inherently harmful as a first introduction to computing. The desktop is fine ONCE you've understood how the system works from a bit of a different point of view (though perhaps NOT necessarily a lower level as such), but until then the desktop metaphor will trick you into believing very many things that are simply not true, and which are going to come back and bite you in ways like those mentioned in the paper. As for the doing away with the hierarchical file system, I agree. Throw it out. I enjoy Unix, but I don't hold the hierarchical file system particularly dear. In fact, I think Unix has some very powerful ideas, and it sucks a lot less than Windows, but Unix is just a local optimum and nothing more. --- Finally, on a bit of a different note, I'd like to state how I tend to think of files now. To me, a file is data. Often that data will have been structured in a particular way, and sometimes it will have been structured in no particular way. A valid python program has a structure that allows the python interpreter to execute it. A text file that someone wrote using a plain text editor has a certain encoding but no structure beyond that. A file that was created by putting random data into it will not have any structure. A file that was corrupted will have some data that does not conform to the intended structure. I am aware that the order of the bytes and their property of being one single, continuous unit, in persistent storage might don't match the order that is presented to applications by the operating system, but in my use of computers this has not yet mattered so I choose to ignore that fact. So I too am living a bit of a "lie" with regards to how I think about files, I admit that. Some files are not really files, but they are convenient because they offer you a simple interface to some useful functionality. I am speaking of course of /dev/urandom and friends. Regular files are representations of "something". Like a text, or a photo, or anything else that you can create a meaningful representation of. You can load the data into a program as long as that program has been programmed to understand the structure that is used in the file that stores your representation of your data. If the program that you would like to use does not understand that file format you either convert the file to some other format if an acceptable conversion is possible with an existing piece of software. If none exists, you implement it yourself, either into the program that you are using, because it's open source as is the vast majority of the rest of your software, or as a standalone program that does just conversion, in both cases you are able to do this because the file format is sufficiently simple, or at least the subset of the format that you need is, and the format is open. If you are using proprietary software (including using multiple pieces of proprietary software) in combination with proprietary file formats, then either 1. The proprietary piece(s) of software is/are able to do absolutely everything that you need to do (or at least, you think so), or 2. The data is not sufficiently important to you to warrant building better tools yourself, or 3. It's so difficult to build these tools that you don't have an alternative. For example, the data might come from very complicated equipment that you couldn't build yourself even if given a million years to do so, and the data is so complex that you aren't able to understand it from inspection nor from reverse engineering, or 4. The requirements changed (see also point one about thinking that the software did everything that you needed it to do), or 5. You've done fucked up. You didn't do your research and now you've stuck with this. (See also point one about thinking that the software did everything that you needed it to do.) Anyway, once you've loaded your data into a piece of software that is able to read it, something happens, and it brings us back to what we were talking about. --- Once you've loaded your data into a piece of software that is able to read it, or "opened a file" as is often the way that this is achieved, I would argue that you are not operating on a file. You are working on the data that was in the file. This is a very important distinction. When you hit save, you are not saving the file. You are requesting that parts of the application state to persistent storage. Again, a very important distinciton. If people knew this and understood this, computers would make more sense to them. They are right in the paper that the mismatch between what developers, computer scientists and others think of as files is the cause of a lot of the kinds of problems that people have when they are dealing with files. But where did the users gain their misinformed ideas about files from? I've said it already, I think the desktop metaphor is to blame. Again, it's an ok metaphor as long as it's not the only metaphor.