The Second Coming: A Manifesto | Hacker News Reader

The Second Coming: A Manifesto

edge.org

33 pointsdejan32 comments

42. To send email, you put a document on someone else's stream. To add a note to your calendar, you put a document in the future of your own stream. To continue work on an old document, put a copy at the head of your stream. Sending email, updating the calendar, opening a document are three instances of the same operation (put a document on a stream).

Sounds like a gap in Unix's file metaphor. Would it be reasonable to copy a file to /proc/mail/coworker@company.com/ and have the right thing happen?

57. Nowadays we use a scanner to transfer a document's electronic image into a computer. Soon, the scanner will become a Cybersphere port of entry, an all-purpose in-box. Put any object in the in-box and the system develops an accurate 3D physical transcription, and drops the transcription into the cool dark well of cyberspace. So the Cybersphere starts to take on just a hint of the textural richness of real life.

I think mobile phone cameras will be the "scanner" here.

> Sounds like a gap in Unix's file metaphor. Would it be reasonable to copy a file to /proc/mail/coworker@company.com/ and have the right thing happen?

Sound's reasonable. Though you would probably have to set write-new-files-only permissions in that directory, to capture the semantics of email. Reading and modifying files and even listing directory contents should not be allowed. Perhaps it would be better to make proc/mail/coworker@company.com a special file that you can write to, instead of a directory?

It's an interesting argument, but if you make it a file, will the system know that:

cat file1 > proc/mail/coworker@company.com

cat file2 > proc/mail/coworker@company.com

are two separate messages?

Good question. I don't know. That why I put the question mark in there.

I'm having a heated argument with a person who refuses to read past point 30, because he understands files and hierarchies and thinks that anybody that can't organize their computer files is just hopeless and shouldn't bother. He's the kind of person keeping this whole thing back.

The future of user interfaces is one without named files and directories, I'm 100% positive about that. Real-life hierarchies of information are more organic than named things belonging to one category. Ideas are not grouped so rigidly, and neither should last year's tax return (it's financial, and it's personal, and it's governmental, and it's a form, you created it about a year ago, etc. etc. etc.).

Pieces of information should be known for what they are, not what they are named. Naming them is tedious.

Maybe the person just doesn't understand that data doesn't need "human" organizing in first place. It's us, the users, who make a mess out of it.

Files and directories were fit when we had 1 GB drives. Now, with a 1 TB standard coming for laptops, sorting data is just as complex as SETI. It's not the problem in the programs as much as in the inherited cruft knowledge of rapid acceptance of personal computers. An intuitive solution doesn't have to be explained, while I spent so much time explaining folders/files although it should have been obvious.

Indeed, "the only "intuitive" interface is the nipple. After that it's all learned." Now, I am not saying filesystems == nipples, but it's one hell of a goal to aim to for such a foundation in information management.

Although I wrote (long time ago) about sets/tags as a possible solution [http://news.ycombinator.com/item?id=709814], I think it's just the tip of the iceberg. Lifestreams make more sense to me with each thought, as I can see how I would use it.

Thinking aloud - naming files doesn't make sense as 1) information can have multiple names dependent on the perspective, 2) information is divisible, so naming should be too.

You are right. Current file systems already try to address these. E.g. you can have multiple links to the same file (and even mount directories on top of each other). And for divisibility: Reiser4 brought the idea that e.g. /etc/passwd can be at the same time a directory with a bunch of files (say, one per line), or a single file that is automagically aggregrated (via a plugin that understands the format).

A filesystem is just a special purpose database, and there are a lot of interesting approaches left to be explored. For example, transactions would also be nice.

"the only "intuitive" interface is the nipple."

Actually, even that is learned, it's just that most babies learn the key skills a week or two before birth and are able to move right to the application. Preemies often have trouble with putting "suck" and "swallow" together, so they need to be taught how to use a nipple.

-------

Files shouldn't require names, but they should accept them. After all, we're looking for good ways to describe the contents of a file, directory, or database entry. Sometimes a set of tags and associations is the way to go, but sometimes the name "2008 tax return" is a perfectly fine description. Data doesn't always need human organizing, but sometimes human organizing is useful.

You didn't name but tag that file: - "2008" - all files from/related to year 2008 - "tax" - all documents related to tax - "return" - all documents related to "return"

Now, your file should be in the intersection of those tag- sets.

I quoted about the nipple, it's a well know quote, but the insight in nipples is always worth recording, kids are coming. :D

I know it's not a new idea, but I wonder if the time has come when the filesystem model is replaced with the database model. I realize that a relational database simply trades one hierarchical structure for another, but it seems that the schema-free and arbitrary structure of a "NoSQL" model might make a better fit for the globs of data that comprise a modern storage drive. The key is in having a powerful and intuitive enough searching algorithm that you can actually find what you need.

Yes.

Naming and tagging and hierarchies can still be useful. They should just be optional. E.g. searching works quite well in gmail, but I still use labels for some functions (most of the time my labels are just defined as the result of a search, but not always).

Relational databases are not limited to hierarchies. You can create complex graphs if you want. It's all how you model your information. They were created due to the limitations of hierarchical and network db systems.

There was an interesting discussion on Artima ("Software Development Has Stalled") last week that touched on the schema-free idea. One of the participants suggested that computers could use inference to determine data relationships. (In his words, the computer is hypothetical and would need to be infinitely fast.) Presumably by computer he meant some agent doing machine learning on top of the "infinitely fast" hardware.

If your idea is along the inference line, then it would be interesting to see how far inference could go. However, if you mean to simply encode relationships into each program (or into a library), then it's just a re-invention of a schema.

Maybe a solution will lie in adaptive neural networks.

Pieces of information should be known for what they are

However, to be able to get to them, you will always need a unique identifier for each piece of information. I have a file named 'expenses-2010-03.ods' on my machine. I can imagine a 'file system' where this piece of data doesn't have a filename, but where it has a set of tags (or whatever other name you would like to give to the pieces of meta-information identifying the piece of information). I'll type, say, or think 'expenses' and then 'select' '2010'. Then I need to be given the choice between 'january', 'february' and 'march'. Is that much of an improvement? There is no indication that, in the foreseeable future, machines will be able to automatically provide correct meta-information. Is tagging them really less tedious than coming up with proper filenames?

If I may hazard a guess, I think that in your heated argument, you are defending your position with vague ideas of futuristic sounding things that may come. However, without concreteness, you can defend your idea against anything by hiding in the vagueness. This 'person' is trying to drag you back to earth by stating a simple fact: to be able to get to information, you need to be able to identify it. You can only do that by a unique set of computer encoded units of meta-information.

This is all a little bit out there for me, but Gelernter is a great mind. I still think Linda will take over the world. The most interesting part of this, for me, was this quote: "The computer mouse was a brilliant invention, but we can see today that it is a bad design. Like any device that must be moved and placed precisely, it ought to provide tactile feedback; it doesn't." It's only funny as hype builds for the ipad and mobile internet devices, almost all based on touch screens. Even before that, trackpads and membrane keyboards were all slow and steady movements away from strong tactile feedback. The "minority report" interface that people love so much is even further along, there is no contact at all. None of this is to say Gelernter is wrong, but, if he is right, I wonder when we will see the movement towards increased and/or more intelligent tactile feedback.

At least touch interfaces remove a level of abstraction that currently exists between moving a mouse on a desk and moving a pointer on the screen. A touch screen with tactile feedback (the iPhone already has vibration... more apps should make use of this) would be nearly ideal.

Prediction:

Touch interfaces will comprise the new end-user interface vocabulary. As happened with mouse/keyboard/overlapping windows, a de-facto standard set of UI conventions will be established as a new mainstream.

Apple will be a trailblazer of this with the iPad. They will be too greedy with their IP and their closed corporate policies will drive the creation of a different but similar standard that they do not directly control. Hopefully, it won't be Microsoft that jumps in and does it this time.

Interesting.

Could you put any money, some odds and a timeline on your prediction?

The most interesting part imho is the lifestream he talks about, as well the implied "eternity service" for information management. I wonder besides Linda, why more of these ideas didn't see implementation. I am assuming the Internet and the open source collaboration came too late.

Linda for sure will see reincarnation, but can't stop thinking how funny it is that old technologies are coming back in big fashion, as "innovations". PG might be right, all languages seem to be evolving into Lisp. :D

Regarding a return of Linda, I couldn't help but note similar themes when first learning about Amazon's Dynamo and later, the Apache Cassandra Project. I'm not saying that there's a perfect match, but when one's imagination has academic roots in the era of Linda, it was easy to see a connection through that lens.

Anyone else see the potential there?

At the very least, it influences how I might use something like Cassandra (or dbm files for that matter), and I've been planting the meme for others to approach their designs that way too.

19. The power of desktop machines is a magnet that will reverse today's "everything onto the Web!" trend. Desktop power will inevitably drag information out of remote servers onto desktops.

20. If a million people use a Web site simultaneously, doesn't that mean that we must have a heavy-duty remote server to keep them all happy? No; we could move the site onto a million desktops and use the internet for coordination. The "site" is like a military unit in the field, the general moving with his troops (or like a hockey team in constant swarming motion). (We used essentially this technique to build the first tuple space implementations. They seemed to depend on a shared server, but the server was an illusion; there was no server, just a swarm of clients.) Could Amazon.com be an itinerant horde instead of a fixed Central Command Post? Yes.

Now the network 'edge' is physically the the carrier owned physical location nearest the end user. This suggests that edge will be moved to the physical location of the end user. Financially this makes sense since it would move some of the carrier hardware and compute costs to the customer thus lowering the service costs as well as decreasing latency. It could be the next step in development of the compute cloud.

I believe he is talking about large scale, generalized p2p and finally merging the web app benefits with supercomputer's power of our desktops, coordinating power across the net, and having information "fly around" in cyberspace.

sexy.

Yes I agree he is talking about p2p. ISPs could start deploying devices on customer premises to provide caching, storage, compute and wireless network services. In densely populated areas this would essentially be a local CDN.

1. No matter how certain its eventual coming, an event whose exact time and form of arrival are unknown vanishes when we picture the future. We tend not to believe in the next big war or economic swing; we certainly don't believe in the next big software revolution.

2. Because we don't believe in technological change (we only say we do), we accept bad computer products with a shrug; we work around them, make the best of them and (like fatalistic sixteenth-century French peasants) barely even notice their defects — instead of demanding that they be fixed and changed.

Collorary: If you want aim for something world-changing, you need to aim high enough that most Slashdotters won't immediately get it and say "meh."

I think this level may be out of the reach of most startups now. (Google, Facebook, and Twitter are notable exceptions. But I think the low-hanging fruit has been largely picked from the current set of user interface kit.)

Very fascinating vision. It isn't clear when this was written. Also, for some odd reason, number 15 is missing.

June 2000, deducing from the dateline of the quoted/linked NYTimes piece, which mentions "last week".

Amusing typo in the collected reactions: "Feeman".

I was struck by this paragraph in John McCarthy's detailed critique that followed the manifesto and thought it pointed out a real issue for many systems:

   "Unfortunately, the making of computer systems and software is dominated 
   by the ideology of the omnipotent programmer (or web site designer) who 
   knows how the user (regarded as a child) should think and reduces the 
   user's control to pointing and clicking. This ideology has left even the 
   most sophisticated users in a helpless position compared to where they 
   were 40 years ago in the late 1950s.

57: Compiz actually has a small hint of part of this with their rain effect. A "butterfly effect" would be awesome. References to chaos theory included.

I appreciate #30-34, on file names, which opens up with

30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don't bother.

The count of "eight possibilities" on #34 puzzles me a bit.

I also sympathize with the (time) streams idea further down. Archeological strata are a very efficient concept for storage, and not the worst possible one for retrieval ...

Actually, I thought the cattle analogy missed the point - surely the reason we don't give names to each of our 10,000 cattle is that we don't care which one is which? I don't find that to be true of data. Also, file names are often used to describe the data to which they relate; in that sense, we actually do give names to each of our 10,000 cattle - we call them 'cows' - it just happens that we use the same name for each individual because they are identical at the abstraction level we care about.

Or maybe it's me who missed the point? :-)

actually it's not true of cattle either.

We care about the individual cattle when we process it.

I.e. when it goes to the slaughterhouse we want to make sure it's not contagious, that it's not a kid cattle etc.

We might even group them males or females.

The answer is context not categorization.

Processing cattle is a kind of filter/map operation: walk the list of cows, assessing each one on a set of criteria, and then processing the cows that meet the criteria.

Reply on news.ycombinator.com