Comment by yew
13 years ago
Speaking of file conflicts:
I'm picturing an alternate universe in which 'the database' stands in for 'the filesystem'. Data is laid out in a manner logical for its origins. Most programs use the library-provided implementation, of course, but there is a little more variability than in our world.
People have spent the past fifty odd years writing utility programs for manipulating databases instead of files, so concerns like 'moving' data between programs are still basically trivial.
In that universe functions really are the basic building block of code, and the database engine's consistency guarantees handle editing conflicts implicitly (with logging for version control, of course). Too bad, perhaps, that we're here rather than there.
Thoughts, criticisms, elaborations?
Reminded me of something Jaron Lanier wrote... found it:
"For instance, there is the idea of the computer file, which was debated up until the early 80s. There was an active contingent that thought that the idea of the file wasn't a good thing and we should instead have a massive distributed data base with a micro-structure of some sort. The first (unreleased) version of the Macintosh did not have files. But Unix jumped the fence from the academic to the business world and it had files, and Macintosh ultimately came out with files, and the Microsoft world had files, and basically everything has files. At this point, when we teach undergraduates computer science, we do not talk about the file as an invention, but speak of it as if it were a photon, because it in effect is more likely to still be around in 50 years than the photon."[1]
http://www.edge.org/documents/day/day_lanier.html
wasn't micorsoft supposed to roll something out with Vista that was sql server standing in for the filesystem?
http://en.wikipedia.org/wiki/WinFS#Development
I don't use windows anymore, but I hang with some .NET developers, and they aren't raving about WINFS, or Power Shell, or Sharepoint. Generally they seem pretty miserable.