I don't really like the article, but I will grant the author the benefit of the doubt as he's the creator of CouchDB. Maybe his ideas are right, but worded badly.
I lost my interest at "PHP to the Rescue". I understand the point he tried to make, but he's wrong.
PHP (or CGI/FastCGI for that matter) only works because the computation done on each request is very light and it maps well with the HTTP protocol which is at its core a stateless protocol. But it only works because the real work of indexing, searching and retrieving of documents gets pushed to the database server, a piece of software that does serious gymnastics to serve the results you want. The database server does give you ACID and it does this precisely because it can UNDO and once the database server crashes, all hell breaks loose.
A better example in this context would be Chrome, which sandboxes each tab inside its own process, such that the crashing of a tab doesn't affect the whole browser. But tabs themselves have to be long-running and stable, and those tabs are still crashing and valuable work may still be lost, not to mention the whole browser still freezes because of plugins that haven't been fully sandboxed.
Also, it doesn't warm my heart when I lose an hour's work, even if the other tabs haven't crashed.
Don't Undo Your Actions, Just Forget Them
... Use a Functional Language
This doesn't address the bigger and most important issue - some resources are inherently mutable.
Once a file is changed, it stays changed (sorry, you'll have to replace the OS to avoid it and what can I say, good luck with that). Once an email is sent, it stays sent. Once a phone call is made, you can't really pretend that it isn't. Once a bank transaction is made, you have to undo it if anything went wrong, otherwise you're facing serious penalties.
Not dealing with mutable data only works insofar you're dealing with dumb logic and not everything is as simple as an HTTP request that returns rows of comments in a simple blog.
Also, I find an article bitching about OOP and about UNDO weird at best if it doesn't reference THE OOP recipe for undoing whatever you changed -- http://en.wikipedia.org/wiki/Command_pattern
Boy, you missed the point. Undo here isn't about user-undo. It's about when the program can't continue, you need undo all incomplete state changes and return to a previous state. Really this article is about the lack a transactions in programing languages, and how error conditions cause problems for software with long lived state.
The point about PHP is that it successfully does that precisely because the way it's architected. The state is kept the DB server where the transaction problem is solved.
When using long lived server processes, things tend to get in invariant states on error conditions unless you are very careful about how you are programming and dealing with state mutation and error condition. As ugly as it seems, PHP style development frees you from that.
I like your point about Chrome, it's a great architecture and it's actual quite similar original Apache PHP combo with the process isolation.
Anyway user level undo is still an important concept, but orthogonal to creating reliable software systems.
You could just tl;dr the article as "Use transactions". Transactions don't have to be tied to a database, and anyone with a CS background should know what they are.
God, I never get tired of the condescending "I lost my interest at" or "I stopped reading at". Always strongly reinforces in my mind how irrefutably confused and misguided the original article is, and how thankful I am to be shepherded into the light by so wise a poster. I myself am not typically able to dismiss everything someone has to say by the reading of a single point, but I've noticed a lot of other people seem to be able to.
Look, this is a very long article, it really wasn't worth reading and to be honest bad_user summed up a fundamental flaw.
And I'm saying that having read it. Three times. I wish I'd taken bad_user's comment on face value but your comment and the author's comments made me read it.
Whole chapters were squirming before my eyes that seemed to make a single tiny point. Was I missing some gem of knowledge to unlock the shockingly badly written conclusion (otherwise known in writer circles as 'Um, what was I saying?')? Whole rambling diatribes could have been cut down to single sentences ('Building a Deck' and 'The Miracle Deck', I'm looking at you.). A little of my soul died inside. I thought I was missing something because he waffled so much.
I wasn't.
And 'I lost my interest at' perfectly sums it up.
This is an old article by someone who at the time wasn't a very good writer.
The core points of the article are sound, the author is right about programs being too brittle, but he took a lot of words to say it and his conclusion buried unconventionally in the middle of the article is way, way, way, way, way, way, way off the mark and the article is a massive chore to read. This is from 2006 and it shows.
Not really. I didn't see the author ever claim you could magically control external mutable state, indeed he explicitly acknowledged that:
> Unfortunately, adding the toolbar bar to the window may not truly be an atomic operation down deep, but from your perspective it is, since you can't make the mutation operation any smaller. You may not have completely eliminated the chance of things going into a bad state, but you've minimized it as far as you can.
He just says "do the best you can with your own software, and here are some ideas about it". It's an old article, appropriate for its time (detailed because many people were new to functional concepts) and yet surprisingly prescient (the rise of functional languages did occur). Nobody forced you to read it if you happen to be some whiz-functional programmer to whom all the points are intuitively obvious. Honestly, I don't understand the negative tone in many of the comments.
I lost my interest at "PHP to the Rescue". I understand the point he tried to make, but he's wrong.
PHP (or CGI/FastCGI for that matter) only works because the computation done on each request is very light and it maps well with the HTTP protocol which is at its core a stateless protocol. But it only works because the real work of indexing, searching and retrieving of documents gets pushed to the database server, a piece of software that does serious gymnastics to serve the results you want. The database server does give you ACID and it does this precisely because it can UNDO and once the database server crashes, all hell breaks loose.
A better example in this context would be Chrome, which sandboxes each tab inside its own process, such that the crashing of a tab doesn't affect the whole browser. But tabs themselves have to be long-running and stable, and those tabs are still crashing and valuable work may still be lost, not to mention the whole browser still freezes because of plugins that haven't been fully sandboxed.
Also, it doesn't warm my heart when I lose an hour's work, even if the other tabs haven't crashed.
This doesn't address the bigger and most important issue - some resources are inherently mutable.Once a file is changed, it stays changed (sorry, you'll have to replace the OS to avoid it and what can I say, good luck with that). Once an email is sent, it stays sent. Once a phone call is made, you can't really pretend that it isn't. Once a bank transaction is made, you have to undo it if anything went wrong, otherwise you're facing serious penalties.
Not dealing with mutable data only works insofar you're dealing with dumb logic and not everything is as simple as an HTTP request that returns rows of comments in a simple blog.
Also, I find an article bitching about OOP and about UNDO weird at best if it doesn't reference THE OOP recipe for undoing whatever you changed -- http://en.wikipedia.org/wiki/Command_pattern