courtesy of one of its more successful businesses:

"No one shall engage in unprovoked ganks in Empire highsec, on pain of being CONCORDOKKEN'd."

/still checking through early drafts, looking for the page where they inserted the phrase "HARDEN THE F**K UP"

Granted. The most extreme example of this is embedded development, which is one of those "corner cases" I referred to where C++ is justifiable and languages such as Java are definitely contraindicated.

Of course, never forget the Laws of Code Optimization:

• The First Law of Code Optimization: Don't do it.
• The Second Law of Code Optimization (advanced experts only!): Don't do it yet.

That should really have been called "NullReferenceException" but Java baked that mistake in pretty early on, so we're stuck with NPE.

I've also opined that Java really needs to adopt the "safe navigation" operator from Groovy, which acts like the regular "." operator, but, if the left side is null, returns null rather than throwing NPE. In effect, the expression "a?.b" is equivalent to "a == null ? null : a.b". That alone would help eliminate a bunch of the NPEs I see on a regular basis.

Oh, granted, there's no substitute for good, careful design in any language. I just cleared up a problem in my company's massive Java application today which involved an extra object copy being created and then persisted to the database, resulting in a "concurrent modification" error message (as one copy in memory was no longer in sync with the one in the database). Sometimes it can be so easy and painless to create a new object, that you don't stop and ask whether you really should.

But simply due to automatic memory management, there are whole classes of bugs, some of them nasty, in C++ that simply do not exist in Java. (And, of course, Java probably has a few that C++ doesn't have. Perfection is nonexistent. You pays your money and you takes your choice.)

And, while C++ will always necessarily be faster to execute, there's no question that the other three languages will be faster and more straightforward to develop in. (Which, in general, makes them a net win, as programmer time is almost always more expensive than computer time, except in certain corner cases which should be obvious.)

Why? Three words: Automatic memory management.

No more worrying about whether you've allocated the right buffer size for your data...and maybe allocated too little resulting in an overrun screw, or allocated too much and wasted the memory. And no more forgetting to free that memory afterwards, resulting in a memory leak. You can write expressions like "f(g(x))" without having to worry about how the return value from "g" is going to be freed, allowing a more "natural" coding style for compound expressions.

I maintain that automatic memory management, while not great for code-execution performance, is probably the single biggest boon to developer productivity since the full screen-mode text editor. (Not saying "emacs" or "vi" here. Take your pick.)

Granted: You can retrofit a garbage-collecting memory manager onto C++...but that code will rob your C++ code of some of that enhanced execution performance which is probably the reason why you chose to develop in C++ in the first place.

I would think the iPad is a more Guide-like device than a smartphone. YMMV, though.

All I know is, if I ever get an iPad, I'm getting this case for it.

For more on this story, we switch you now to our special correspondents, the Flying Pigs.

More like "Houston...FUUUUUUUUUUU-"

"I hate temporal mechanics." - Miles O'Brien (and his doppelganger)

"Temporal mechanics always gave me a headache back at the Academy." - Kathryn Janeway

Split-screen multiplayer: Requires 1 console, plus 1 copy of the game.

Online multiplayer: Requires N consoles, plus N copies of the game, plus N online service subscription fees.

Which scenario do you think the console and game manufacturers like better?

I'm in Denver, and I've been with AT&T since they were originally AT&T (before they were Cingular for awhile). My fiancee and I both have iPhone 3GSs (32 Gb).

We haven't experienced a lot of trouble with the service. I get the occasional dropped call when I'm driving, but it's not enough to be more than a nuisance. I did see a significant network slowdown in terms of data while I was at a Rockies game, but, well, it was at Coors Field with thousands of people there, and many of them probably had AT&T phones, so the network was probably a leetle bit stressed. For the most part, the service is unobtrusive.

This time around, for some reason, one of our phone numbers was eligible for a full-subsidized upgrade to iPhone 4, but the other was not, so we elected to wait and stick with the 3GS another year; in the meantime, iOS 4 would give us many of the advantages of the new phone without having to switch hardware. We made this decision before the antenna flap started, which just made it look all the more intelligent afterwards. It's my opinion that the next iPhone will almost certainly do something about the antenna problems we've seen on the iPhone 4, and it's likely that Apple will take a look at all aspects of the unit's RF performance. When they do, and when they release a new model that incorporates these improvements, we'll upgrade.

Unacceptable response, Logan 5! Input contrary! Input contrary! Contrary! Contrary!

There isn't any.

Hm? I hack UNIX, but I have no facial hair.* I must have missed the memo.

* - And my fiancee prefers it that way, wink wink, nudge nudge, say no more...