I would really like to see comments I have upvoted
I have used two strategies to go back to comments I have liked to read (whether or not I happened to upvote them when I read them). I either
a) use my brower's bookmarking capability to bookmark the exact link to the comment
or
b) I copy the exact link of the comment into a text file that I save for building FAQs.
I also make extensive use of HN Search and site-restricted Google search to find old comments on recurring topics here that are worth looking up again. Sometimes I find new good comments that way that I didn't see back when they were fresh. I try in general to upvote a lot, so the "saved stories" on my user profile here on HN includes hundreds upon hundreds of threads, way too many to be practical for going back to particular good comments.
It would be useful to be able to 'star' or 'favourite' a comment or submission, to have them accessible in a private list, and to see how many people had done this to your own comments/submissions.
I wouldn't like this to be generally visible though. As others have said, it creates a halo effect and discourages diversity of opinions.
I see no reason to use additional mechanism. Why not use upvote? I'm upvoting stories so I could see them later (as ColinWright noted), why not create a page I could see comments I liked?
Separation of concerns. You might want to be able to tag a post or comment as noteworthy but not want to upvote it. For example, to remind you to come back to it and add a comment explaining why its wrong or that you disagree with it.
Perhaps to address a limitation in browsers wherein it is not currently possible to scope bookmarks to a given site during a search for said bookmarks?
Really, could anyone handle more than a few layers at the same time? It is sometimes useful to know how hardware (I'm looking at you, L2 cache!) works, but even then a bit simplified version can do the job.
And from time to time there comes another layer on top of everything else, and you wish you could forget the lowest layer you know, just to not start going insane. Or at least to slow it a bit :)
Unfortunately you can't forget about the L2 cache. I love Radix sorting it's just so fast and elegant except it's not vary cache friendly so it can be rather slow when you least expect it.
You missed the point. This is why he talks about Plan 9. In Plan 9, everything IS a file. Including sockets, and windows, and processes. Several of these features have made their way back into linux.
I agree, but this should have been from the start, or at least from UNIX-Internet marriage. My point was little tongue-in-cheek, but I believe that during the years UNIX has got things that are not truly with their initial idea. Or little more interfaces than necessary.
/proc is an attempt to retrofit plan9 ideas back on Linux. Plan9's is far more powerful, because you can control the visibility of filesystem mounts per-process.
That does suggest the idea of implementing a FUSE filesystem that represents all clients connected to the X server (or Wayland). That could be interesting.
As far as I can understand, this was exactly the problem that Plan9 tried to fix. UNIX had started from the concept of "everything is a file", but then as new things got added, those didn't follow the philosophy. Plan9 was an attempt at a fresh start where such non-UNIXisms could be moved back to files.
You misunderstand: the parent interpreter is JavaScript, yes, but the child interpreter does not rely on the parent's evaluation semantics, which means it is not a metacircular evaluator, it's just a self-interpreter. See the Wikipedia article for more information.
It exchanges one form of duplication for another, not eliminates it.
The real "problem" is that textual code is generally one-dimensional in nature, but we are interweaving two dimensions of option combos. It's allegedly a limit inherent to textual code, regardless of paradigm used to write the code.
I'm currently thinking of language with "code" laying in database of sort, and text is just a view of real data. Of course, there would be some text serialization, but it wouldn't be the "true way" for programming it...
