But the warlord gives everyone a free frogurt.

But the forgurt is cursed.

But you get your choice of toppings.

But the toppings contain potassium benzoate.

Please define "much more efficiently". Sure, it's more efficient from the computer's standpoint to run native code, but that's only part of the equation. From the user's standpoint, running something like this as a web service rather than a stand-alone executable means not having to install, never having to upgrade, and automatically having their documents available from any other computer that has an Internet connection. Yes, it may be slightly slower, but that slowdown may be well within tolerable limits, and there are added benefits. Whether those benefits outweigh the costs is up to the individual to determine for their particular circumstances, and what's "much more efficient" in a technical sense may not be more efficient from the user's point of view.

The thing to take away from this (and everyone should already be aware of this if they're making claims as to the usefulness of a JavaScript) is that JavaScript is Turing complete. So it clearly can be used to develop an Office-like suite of tools.

The only real concerns are:

• Is the language easy enough to develop in?
• Do programs written in the language run quickly enough on the target systems?

Since the Google toolkit is converting Java to JavaScript, the answer to #1 seems obvious. And while it's not quite as clear-cut, recent (and ongoing) improvements in browser JavaScript interpretation speed seem to indicate that #2 is likely true, too.

I think we're talking about two different things, here. The application that was demonstrated in the linked article is not a screen scraper in the traditional sense. It doesn't read any values from the widgets. It doesn't care what the widgets represent. All it does it recognize that the widgets exist, and causes the cursor to either slow down over, or snap to, widgets.

So moving widgets around doesn't faze it, because it was never differentiating between them to begin with. All it cares about is locating the widgets in the window so it can manipulate the mouse cursor relative to them. So your example of adding checkboxes is moot, because the app never knew or cared what any of the checkboxes represented in the first place. All it cares about is, "Hey! The mouse cursor looks like it's moving over a checkbox of some sort! Better slow it down!"

Screen scrapers fail when the UI is updated because they need to be able to find and scrape specific bits of data. They need to know which widgets map to which values. By contrast, this software only cares about locating standard widgets on the screen. End of story. It doesn't care what values are represented by those widgets, because that's not relevant to its functionality. So it should work just fine for any application that uses a known set of widgets, since all it needs to do is be able to say, "Ah, that looks like a checkbox!" and "Oh, that's clearly a text input box". Changing widget graphics would likely break it in a similar way that rearranging them would break a screen scraper, but just moving them around would have zero impact (unless you start overlapping them or something else funky like that, I guess).

Doubtful.

Before it slips "that much"? A traction control system can notice the same slippage, and it can react to it a hell of a lot faster than you can. Maybe not in as nuanced a manner, but sometimes a brute-force approach is a better choice.

I'm assuming you mean in the context of cars? If so: Anti-lock brakes. There's no way a human driver can replicate the reduced stopping distance provided by anti-lock brakes. We just can't react quickly or precisely enough.

So the highlighting of speed limit signs looks like it's intended to be used to highlight signs when they display a speed limit that is lower than your current speed. Sounds pretty useful for all those little "speed-trap" towns that litter state routes.

Because the other alternative is . . . . not waiting for Sony to fix it? Forcing Sony to hire a team of time-traveling coders to travel back in time and fix the bug before it happened? I fail to see what alternative there is besides waiting for a few days. Deciding to sue Sony won't make your PS3 work any sooner than just doing something else for a few days and then coming back and installing the update that they put out to fix this.

Look, I know you're upset that a bug in the PS3 calendar has managed to trigger some sort of DRM switch. Sony is rightly at fault, and is guaranteed to fix this in a matter of days. But your over-reaction is well outside the realm of what is reasonable.

Ask, and ye shall receive.

The Lord of the Rings was actually written as a single book (or more accurately, a single novel composed of six internal "books"), but the publisher decided to split it into three physical parts for economic reasons. So Fellowship of the Ring was not originally written to be part of a trilogy.

"Making the game work" isn't too hard for Blizzard. Rather, people who have their accounts compromised by phishing, trojans, keyloggers, etc place an undue burden on Blizzard thanks to their (the players') incompetence.

The addition of an authentication token is how Blizzard is "making the game work" despite users who manage to have their password compromised.

To play Devil's Advocate: Why do you think you deserve everything you want?

Except that you already stated that you "spend most of [your] disposable income on media of various sorts." Perhaps at some point you were presented with two options, and could only afford one of them. Further, perhaps one was easy to pirate, and the other was not. This is not unexpected if you're comparing a single-player vs. multi-player game, for instance (or a console vs. a PC game). Now, without the ability to pirate one of them, perhaps you'd get the single-player (or PC) game because you like it more. But when you add in the ability to pirate, you might instead buy the multi-player (or console) game, and pirate the single-player (PC) game.

Or we could compare types of media. Maybe you're more scared of the RIAA than of various game companies, so you pirate all your games, and buy all your music, even though you'd buy a sampling of each were piracy not an option.

Thus, even though having the ability to pirate media doesn't cause you to spend less money, it can affect where you spend your money. It adds artificial pressures to the market, and skews sales figures, based on what is easiest or least risky to pirate.

Then the prospect of unskippable ads blocking a 911 call are really no more worrisome than the prospect of any other random software bug causing the phone to mis-function during a 911 call. This simply becomes a case of one more thing that can go wrong, which can be said of virtually any new software feature.

Oh give me a break. As horrible an idea as I think this patent is, you and I are both fully aware that no one would ever block a 911 call with ads. Even if Apple were completely, 100% evil (and that looks more and more possible every day), they'd still want to avoid lawsuits caused by their devices blocking emergency calls.

So lay off the "ZOMG what if they block 911 calls?!" FUD, because only an idiot would consider that to be an actual possibility.

The fact that they state that their flattened prints are able to integrate with the FBI database clearly means that this isn't a problem. Hell, real-life fingerprints flatten differently against different objects, so it's not like this is some new constraint, and at least the flattening process of the 3D scanner is predictable and repeatable. In short, I don't think this will be an issue.