> Your contention is that if something failed in the 1990s, it will necessarily fail in 201x?
Nope; the reasoning for the inadequacy is based on the fact you can't please users by including just 80% of features.
Sure they use 80% at most, but everybody has different 80% [1].
A collection of objects (here: files) can only (reasonably) be a: 1) set, 2) directed acyclic graph - a.k.a. tree, 3) relational database (in the general sense)
1) is pretty much pointless,
2) is what my mom and little sister understand and use as it requires little querying,
3) requires a powerful query language (that's what right & comfy for us nerds, right?).
So far the filesystem-less software has been two-prong: mounting filesystems at certain pre-designated mountpoints (Windows & friends), nevermind that;
and presenting a querable database with a bunch of predefined queries -- AND NO WAY OF CREATING ANY MORE QUERIES.
That's the 80% your users aren't looking for.
Now if you come up with a query language that's quick and easy to use from GUI,
I'll buy you a week-long supply of your $FAV_BEWERAGE, cross my heart.
(drop me a line at dexen.devries + the usual gmail suffix).
But it will not `look like' -- semantics-wise -- as the curret breed of Symbians and iOSes.
QED.
Well, how I could I possibly argue with a guy who worked at Microsoft and by extension, with the argument that produced the design of Microsoft Word? Is that what you are selling me, a future where every tablet includes every feature of a PC right down to having a filesystem I can format? I don't want one. You go ahead, be my guest.
This argument attempts to bludgeon me with logic into believing that filesystems are somehow natural, when nearly forty years of hands on experience with computers tells me otherwise. They aren't natural for a guy like me, only a mathematician would suggest that a DAG is the right answer for storing all the world's information. Your argument falls into the Turing Tar Pit of embracing a single design where everything is possible but nothing of interest is easy.
Now about my sister. Consider iTunes: She can type the name of a song and listen to it right away, that's my own Joel Spolsky quote. She can look at her albums. She can look at her artists. She can look at the songs she's purchased. She can look at the songs she has added to iTunes in the last few weeks.
If you want to call it a database, fine. If you want to call it a hierarchal filesystem, fine. If you want to call it a set, fine. I don't care what you call it under the covers, from my sister's POV, iTunes is NOTHING like looking at song files in the Finder.
My sister also likes her third generation iPod. She has never once complained that it doesn't have music files on it. If your sister wants a filesystem, I'm sure somebody makes music players with visible filesystems where she can be comfortable, and I'm ok with that.
Now I think I am going to go my own way and wish you much happiness as you go yours. If you would like something pretentious to ponder, here is my post on what's wrong with OOP:
I suggest to you--with absolutely no justification whatsoever--that organizing programs as towers of classes all inheriting from each other is isomorphic to organizing deeply nested hierarchies of files.
Another poster [1] in this thread made better argument than mine: it's not that non-hierachical file organization is bad. It's good (especially for small, homogenous data sets, I guess).
For other data sets it can be improved, and it will be: by adding support for somewhat hierarchical structure. They did it a few decades ago and it will happen again and again.
The example of music is very, very specific [2] -- all files come with diligently filled-in metadata, and all files have same metadata fields. Each song can be uniquely addressed by (artist, title, version) and mostly uniquely by some other tuples.
But that won't work very well for average Excel and Word files, at least not in the way they are created right now; they largely miss metadata or it differs from file to file.
MS Word? Creeping featurism, bullet-point engineering, yea. They painted themselves into a corner. They broke out of it with Ribbon UI. I like it :D
--
raganwald, I'm terribly sorry for being irritating in the above posts; I'll try to social up :-)
Comments
> Your contention is that if something failed in the 1990s, it will necessarily fail in 201x?
Nope; the reasoning for the inadequacy is based on the fact you can't please users by including just 80% of features. Sure they use 80% at most, but everybody has different 80% [1].
A collection of objects (here: files) can only (reasonably) be a: 1) set, 2) directed acyclic graph - a.k.a. tree, 3) relational database (in the general sense)
1) is pretty much pointless,
2) is what my mom and little sister understand and use as it requires little querying,
3) requires a powerful query language (that's what right & comfy for us nerds, right?).
So far the filesystem-less software has been two-prong: mounting filesystems at certain pre-designated mountpoints (Windows & friends), nevermind that; and presenting a querable database with a bunch of predefined queries -- AND NO WAY OF CREATING ANY MORE QUERIES. That's the 80% your users aren't looking for.
Now if you come up with a query language that's quick and easy to use from GUI, I'll buy you a week-long supply of your $FAV_BEWERAGE, cross my heart. (drop me a line at dexen.devries + the usual gmail suffix).
But it will not `look like' -- semantics-wise -- as the curret breed of Symbians and iOSes. QED.
--
[1] http://www.joelonsoftware.com/items/2006/12/09.html
Well, how I could I possibly argue with a guy who worked at Microsoft and by extension, with the argument that produced the design of Microsoft Word? Is that what you are selling me, a future where every tablet includes every feature of a PC right down to having a filesystem I can format? I don't want one. You go ahead, be my guest.
This argument attempts to bludgeon me with logic into believing that filesystems are somehow natural, when nearly forty years of hands on experience with computers tells me otherwise. They aren't natural for a guy like me, only a mathematician would suggest that a DAG is the right answer for storing all the world's information. Your argument falls into the Turing Tar Pit of embracing a single design where everything is possible but nothing of interest is easy.
Now about my sister. Consider iTunes: She can type the name of a song and listen to it right away, that's my own Joel Spolsky quote. She can look at her albums. She can look at her artists. She can look at the songs she's purchased. She can look at the songs she has added to iTunes in the last few weeks.
If you want to call it a database, fine. If you want to call it a hierarchal filesystem, fine. If you want to call it a set, fine. I don't care what you call it under the covers, from my sister's POV, iTunes is NOTHING like looking at song files in the Finder.
My sister also likes her third generation iPod. She has never once complained that it doesn't have music files on it. If your sister wants a filesystem, I'm sure somebody makes music players with visible filesystems where she can be comfortable, and I'm ok with that.
Now I think I am going to go my own way and wish you much happiness as you go yours. If you would like something pretentious to ponder, here is my post on what's wrong with OOP:
https://github.com/raganwald/homoiconic/blob/master/2010/12/...
I suggest to you--with absolutely no justification whatsoever--that organizing programs as towers of classes all inheriting from each other is isomorphic to organizing deeply nested hierarchies of files.
Another poster [1] in this thread made better argument than mine: it's not that non-hierachical file organization is bad. It's good (especially for small, homogenous data sets, I guess).
For other data sets it can be improved, and it will be: by adding support for somewhat hierarchical structure. They did it a few decades ago and it will happen again and again.
The example of music is very, very specific [2] -- all files come with diligently filled-in metadata, and all files have same metadata fields. Each song can be uniquely addressed by (artist, title, version) and mostly uniquely by some other tuples.
But that won't work very well for average Excel and Word files, at least not in the way they are created right now; they largely miss metadata or it differs from file to file.
MS Word? Creeping featurism, bullet-point engineering, yea. They painted themselves into a corner. They broke out of it with Ribbon UI. I like it :D
--
raganwald, I'm terribly sorry for being irritating in the above posts; I'll try to social up :-)
--
[1] http://news.ycombinator.com/item?id=2301548
[2] http://news.ycombinator.com/item?id=2301942