You don't have a choice. A public record of your exploits will remain in the pocket of one corporation or another regardless of your willing participation. You cannot control what other people say about you or what information they share. The reality is that you can hold out and refuse to get a YouFace page and deride Zuckerberg for his disregard for your privacy; but the problem is he's not the only one who doesn't care.

These sites collect a lot of information. Other people can be the source of information about you. They're the ones posting the embarrassing photos, commenting publicly on your ideologies and actions, and making available a wealth of information about you regardless of your consent. So really it doesn't matter what dumb-sh*t posts what -- if you think NOT posting anything will protect you, you are sadly mistaken.

The only interesting question remains is whether joining the fray and creating your own profile will at least grant you the opportunity to do some spin-control.

The recent changes to YouFace's privacy settings and policies tell me... no.

Well I read the review and it seems that Jaron's just wrote another book full of ignorable generalizations and blow-hard postulating.

It's not his fault. He's just given into the same delusions as every other human being. He thinks he's smarter than you. We all do.

From what I can tell by the review, it's just another book on technology. Like most books on technology, it says a lot of things that don't really mean anything and hold only a tenuous grasp with reality. Sadly, it doesn't fall far from the generic-mainstream-technology-writing-tree. Most books written on the subject tend to be written by authors who think they know it all or know better than every one else. They think they can see the forest for the trees, but most of them fall into the same delusions and end up either rehashing the same points or showing their age.

Everyone wants to be a visionary.

I get the sense that Jaron's book is just this kind of drivel. Though he might have some salient points on Facebook and such, but I might just be seeing the glow after deleting my account. I might give the book a go if I happen across a copy at the library. I just won't expect much.

After using Wave preview for the past couple months, I don't think I like where Google is heading.

There is a lot of good and a lot of bad.

GWT so far is bad. Development of the compiler is slow and forces developers to target specific supported browsers. So far none of which except Google's own Chrome are well supported. Wave preview in any other browser than Chrome is horrendously slow and crashes regularly. Besides, who wants to go back to the mid-90s and have to put warnings on their site, "This site optimized for Chrome at 1900x1080"?

Yet they do contribute to a lot of open source projects and have made a number of their projects open source themselves.

This sounds more like idealism than anything. Their company is too big for any one stake-holder to steer the ship towards a single goal or at least navigate by certain guiding principles.

So to sum up, "meh."

I'm afraid I'm already familiar with your rhetoric.

All I am saying is that there has to be a better way to build web-aware networked applications.

Web browsers like FF, Chrome, Opera, Safari, etc -- they all treat the resources they fetch as documents. Sure it's archaic by our human notions; we've been building interactive applications inside of them for years. Yet the tools we build to do this are only tricking us and this is my major point. We see fly-out menus and pop-ups that insert information into the "page" when we close them; but even then we cannot escape the metaphor. No matter how many layers we make on top of it, there's an impedance mismatch between the language of an interactive non-linear application and a document model. So while we think of websites like Facebook or applications like gmail as rich application interfaces, the browser just sees them as documents and I see them as clever hacks.

In developing these applications with the current crop of technology we must constantly be aware of a cognitive dissonance. An application wants to pass data to the user and update its display but in order to do so another layer is required to map that data into a document model. We make clever abstractions to make it look very much like an intelligent interface widget for the application programmer's sake, but in the end it's not and we are forced to be aware of that.

For applications where the final representation does happen to match a document-model the impedance mismatch is really low and the application code tends to make a lot of sense.

But for more sophisticated application interfaces, these really complex abstractions are required. Tools like Morphic, GWT, Parenscript, and Pyjamas are written so that application developers can write programs that update UI code without having to translate their data structures into the document model. There's a point where maintaining that side of the application is cumbersome and not worthwhile. Yet even these powerful tools make their short-comings painfully obvious.

They make it hard to support all the different browsers. The compilers have to be extremely sophisticated. They're generating code that will be compressed and sent as plain-text to another compiler at the other end which has to interpret the results and which ultimately updates a document model. This is both brilliant because they got it to work and I doubt I'd be able to write such a compiler myself in any reasonable amount of time but it's also incredibly stupid IMO because so much effort was spent working around the problem instead of solving it.

(The evidence of how crappy this can be, try the Google Wave preview in any browser but Chrome. Then try it in Chrome. Google can't improve the JS-generating compiler in GWT fast enough that instead we're back in the mid-90s where sites are optimized to the browser).

There are better ways for delivering sophisticated interactive GUIs across the web.

X, VNC, XUL, SVG, Cairo; stateful application protocols.

It would be nice to be able to be sitting on my Ubuntu desktop to click on an application icon and run it like a local application in my native window environment. Then when I'm done I can close it. If later I want to return but I'm out and about I can open up my Macbook and open it up there. Same application, same state it was in when I left it, same data, and it happily lives in my native environment there.

As an application developer I want my application to be the same kind of first-class citizen as any other in a users' environment. I don't want my interface to be limited by a document model or require large amounts of engineering effort to work around one. I definitely don't want to tell my users what browser they should use to access my application (then neither of us are in control).

Ultimately I think we both want the same thing.

I'm just not convinced that the tools currently popular and available are the best ones for the job.

I think we can do better.

Let's all remind ourselves what the acronyms HTTP, HTML, and the like stand for.

I think it's a classic case of over-engineering. We're building applications with rich interfaces over a stateless text-based protocol. The application UI is being delivered in source-format to be rendered by this "browser/application framework" that thinks of it more like a document (because technically it is). That the end result happens to look and quack like a duck doesn't change the reality. An interactive UI shouldn't be written with methods like "document.getElementById" — it doesn't make sense. However, with a number of layers of abstraction we can make it seem like we're programming a UI and then completely forget about the actual implementation. But at that point you've probably thought they said "trains" when they really said "brains," and hopped on for a ride.

The reality here is that the web browser is designed to retrieve, render, and transfer document-based data. It treats locations it can fetch and upload document data as resources. The interface treats these documents as pages. Pages have a sequential order to them, hence the "history" and famed "back" and "forward" buttons. "The browser" should be a short-hand reference to a more specific and clear name, "the document browser." Or perhaps, "the hypertext document browser."

However if we alter our perception a little we can, with a few tricks, call an apple an orange and turn the browser into an application framework. Documents become user interfaces and resources become APIs. Pepper in some false-pretenses and pretty soon a browser isn't an application but an operating system. For the web.

There have been many attempts at a cross-platform application framework. Some are built in Python and utilize GTK2 or Qt. Others built in C, Lisp, Ruby, whatever.

There are cross-platform protocols for delivering GUI objects over the network. There's a famous one called, X11. Check it out.

In the end however, there isn't likely to ever be a universal language and API. Try getting Lispers to write in Java or what have you. ;)

It might be worthwhile blogging your process and seeing just how pervasive google products are in your life. For some reason I have an eerie feeling that it's not as easy as just "quitting google."

It's pretty simple: Typewriters have become a fetish. They are unique, durable, and built for a singular purpose. There isn't anything that makes them superior as a writing instrument. People have just idealized and idolized them.

Myself, I prefer my typewriter for writing.

1. No distractions or temptation to distraction. No browser window sitting in the background or messaging service waiting to pop up a message at me.
2. Reduced dissonance. I sit in front of a typewriter to write and nothing else. No thoughts about who emailed me or what else I was working on (or at least those thoughts fade as I begin to write).
3. Automatic process documentation. I can see every single word I typed, every sentence I scratched out, and every note I took. I can physically see the evolution of my drafts. Sure I could use a VCS and some sort of key-logging solution in my editor, but why bother futzing around. The typewriter and a pencil do it with the least amount of effort... and won't ever require any software to use to read it.
4. It works even when the power is out. Sometimes I turn it out for the mood.
5. I don't edit as much when I'm typing. Sometimes I can't help myself and I rip out a piece of paper mid-paragraph, but that's far more rare than hitting the backspace or going back and correcting typos, editing grammar, and copying and pasting and everything else.
6. I get a more visceral and primitive connection to my work when I see it take physical form. I can eyeball my progress and see it take shape. There is no temptation to run wc on my text file after every few paragraphs. When I get mad at it I have something physical I can throw around and take my anger out on without regretting the damage it will do to my wallet.
7. Paper has a proven track-record as an easy to preserve archival medium.

This isn't to say that I never use a computer. I much prefer to edit my work on a computer. Scanning in my drafts and using OCR to convert them to plain-text files is a bit tedious but worth it I think. Emacs is a fantastic editing tool. That is the stage in which I indulge in fussing around with the order of things, correcting typos, and touching up grammar. Computers make that easy and its the part I least enjoy so any tool that makes it easier is okay with me (and bonus if it lets me distract myself with a slashdot break).

bah, forgot to log in. haven't had my coffee yet.

but seriously, don't need another rating system.

also -- lawsuit? talk about frivolous. what next? suing the Louvre because you can't see the paintings?

A neat comic by Warren Ellis which delves into a future-now scenario.

One concept he brings to light are a class of subculture hackers called "Shrieky Girls" which use lo-tech hacks to provide hi-tech wearable interfaces and networked haptics. They're a sort of sub-subculture derived from the "grinders" -- people who hack their bodies. I haven't been too deep in the series since its pretty hard to collect from my brick and mortar suppliers, but there is a wiki tracking all of the details.

Pretty neat stuff.

I look forward to a future with more passive/unconscious interfaces.

It's basically a multi-user real-time text editor.

It's a federated asynchronous OT protocol.

From the paper:

"Waves are hosted XML documents that allow seamless and low latency concurrent modifications.

To provide this live experience, Wave uses Operational Transformation (OT) as the theoretical framework of concurrency control."

http://www.waveprotocol.org/whitepapers/operational-transform

Common Lisp.

I'm still really new to the language having more than 12 years or so experience programming with the Algol-decendent languages like C, etc. I went the Assembler -> C -> dynamic languages (Perl, Python, etc) route. However once I started delving into it I started realizing that if I had to chance to start over, I'd much prefer to learn CL first. It's much easier to understand my programs and syntax is nearly a non-issue. I find it is a very pleasing language to work with.

The homoiconic structure of the language removes most of the cognitive dissonance between representation and execution. More often when I was starting out I wouldn't catch many errors until I ran the program. Finding optimizations became an exercise in juggling the syntactic representations of language primitives which were different from language to language. As I improved over the years I started creating a divide in my mind between program representation and AST... which is sometimes fun (I had a lot of fun just poking around with Perl early on) but at the same time was a pretty difficult hurdle to overcome.

The prefix notation and minimalist syntax of CL is also pure bliss. My editor takes care of syntax for me. No need to memorize precedence tables or the syntactic differences between statements, definitions, calls, etc. The uniformity of the language means there are far fewer rules, irregularities, and exceptions to keep track of. More mind space for programming and problem solving.

Some people think simplicity is procedural instructions and infix syntax. "Open the file," they say, "read the next line and apply the word count function to it." We're so used to infix notation from elementary mathematics that it's second nature. These sorts of languages usually start with the premise that a program is represented as a series of statements that are executed by the interpreter/compiler/etc. Yet the novice doesn't have to proceed far in their tutelage before exceptions to this rule are introduced (such as a definition, usually a block of statements that are executed in series when the name of the definition is called in another statement... whoa). Further complexities are added by layering the exceptions.

Whereas Lisp's uniformity allows the novice to start with one simple atomic unit of knowledge, the humble list, and evolve complexity as they learn more. Rules learned as one proceeds in learning Lisp are almost never (if ever at all AFAIK) excepted by the addition of new knowledge. One of the first bits of knowledge you learn early on is, "everything in Lisp is a list," tends to remain true throughout. There are only a handful of special forms to be aware of and that's all. I think for a novice this is a much more natural way to learn... start small and grow from there.

Of course choice of language is quite personal. I certainly had a lot of fun (and still do from time to time) working with Perl (sometimes just for the sake of fun). I thought assembler was pretty cool when I started out using the graphics routines in the Lisa assembler on a dusty old Apple II (right when some of my friends were lucky enough to be getting the new 80286s). But in retrospect is was pure curiosity which drove me: something that cannot be taught.

I can sympathize. I prefer fountain pens because India ink is proven to weather hundreds of years if the paper that holds it can survive. However, when I first started using them the smudges got really annoying.

I adapted though. It takes a little extra muscle effort, but tilting the writing hand back and curving the arm to write at an angle has alleviated the smudging problem for me. Though I do find that my hand cramps up faster if I apply too much pressure (as I tend to do when writing fervently).

However being left-handed does have its advantages elsewhere from writing. Statistically we're more intelligent than right-handed people (though I have no source to cite so take the statement with a grain of salt) and in pugilism we have the advantage versus right handed opponents. :)

Best of luck, lefties rule!

There was a time when I actually had a handwriting/cursive class.

It was removed from the curriculum pretty early on in my educational career.

Not long after assignments were not allowed to be hand written.

The type-setting requirements of teachers became picky enough that the only way to write an assignment was with a computer.

It's sort of hard to test how long digital records will last and how recoverable they will be in the future. Paper and pen have already proven themselves: no special equipment is required to extract their data... only perhaps to maintain them after they reach a certain age.

Hence why I prefer to write my journals and notes by hand. I know they'll still be around when I'm just some ancient ancestor and they won't have to dig around EBay for an equally ancient x86 based computer and LCD display to read it.

The authors of the text on Wikipedia do not retain copyright.

Neither should the people who take the photographs.

The public license is a benefit, not a detraction.

For the good of public knowledge, not your personal gain.

You'd think altruism was slowly being bred out of us.

Writing a "Hello, World!" script is trivially easy. Programming today isn't as technically difficult as it once was. I can write full desktop applications in the same high-level language I write web applications and servers in. However, once you get past the tutorials in your books, nothing is ever easy. Expertise is necessary to progress beyond amateur.

This isn't a technical problem. The solutions have been there before this problem came to be: irc, nntp, ftp, sftp, ssh, vnc, x11, http, etc. This is more of a stigma. Using the browser as a delivery platform for interfaces to networked applications was a work-around to proprietary OS vendor lock in. Delivering cross-platform applications was once a very daunting task, even for seasoned programmers, and made very little sense to businesses: who wanted to maintain a new version of the same software for every possible mainstream OS? But that has become a problem of the past and in the meantime the work-around has become the norm. That's the real problem: a generation or two of new developers simply don't know anything else.