"We had to destroy the village in order to save it."

This was one years before then, it used to be normal to be cross language. Ie, VMS was implemented in a variety of languages, Unix provided a common calling standard between languages, etc.

I remember things being very easy on Unix until the advent of C++. As long as you were careful, I recall no problems interfacing between C and FORTRAN and Pascal and such. (You had to be careful because, for example, FORTRAN didn't understand the concept of pointers and dereferencing, so C code that didn't respect that could confuse the bejezis out of FORTRAN's optimizers.)

My old startup company (mid to late 1990s) sold a product with a C API. We integrated it with Perl, Python, Java, TCL, and PHP.

TCL was glorious at this. Once h2xs came into being, Perl wasn't bad (at least back in the days when nobody expected to do OO Perl yet). Python (1.5) wasn't bad at all. Even PHP was doable with a little work (it got easier later).

But C++ stormed ahead with overloading, and without a care for ABI compatibility -- you couldn't even assume the products of two different C++ compilers, or even two different versions of the same compiler, could be linked with each other, and it's all gone downhill from there.

I was going to give my opinion on the best approach for dealing with this, but there isn't one. The problem is, the best approach for maintainability is bad for performance (and vice versa). But my preference when one can get away with it is basically to do "RPC" over an I/O channel instead of attempting direct linking.

Everybody's every move being tracked in the name of lower premiums or children safety is downright scary.

What's worse: safe, conservative drivers opting in to this in order to prove that they're safe and get lower rates, or forcing safe drivers to subsidize the insurance of reckless drivers because the insurer has no way to distinguish between the two?

(I think the answer depends on other factors, like privacy controls, consumer protection, and system security.)

This fellow needs to work on his self-esteem.

A thing that actually worked in our environment for a while was setting up a lounge with an XBox and "Rock Band" in it.

Very different people ended up playing together, at lunch time. There'd be offhand comments about what we did, and connections got made that remained useful for ages.

(Alas, new management thought it frivolous and discouraged this, and as a result, communications has been breaking down...)

Depends on where the heavy lifting is.

If you've got a JavaScript that implements web SQL and web GL, well, those are implemented in low-level languages and you're just going to call them from JavaScript. If that happens to be where the bulk of the work is for a given program, you might get better performance out of JavaScript than Java.

(The devil is in the details. I do not know the details in this specific case.)

The first time I saw this basic thing done, in a hacky way, was between the ham radio clubs of my university and our neighboring university, in... the late 1980s.

They took two helium-neon laser tubes (laser diodes not being as available to hackers yet), two photosensors, and two little shutter-like things that modulated light proportionally to some voltage. Then they took two acoustic modems. They hooked the sound-generation output to the thing that modulated the light and the sound input to the photosensors, lined up the beams, and got the modems talking to each other.

As I recall, they had a working 1200 baud connection from over a dozen blocks away. Didn't have any practical use, but it was kinda awesome.

(I think I've still got a box of old helium neon laser tubes in my basement somewhere.)

Sorry, that sort of acoustic coupling is bound to be loaded with errors. You might be lucky to get 16 BYTES per second, and even then, those speakers aren't powerful enough to transmit very far.

You know that ultrasonics are precisely how a modern Furby communicates with its companion iPhone app? (There's even perl code implementing it so you can hack them.)

How hard would it be to create a runtime environment for XP similar to WINE on Linux and MacOS that provides missing APIs and such so that things written to require newer versions of Windows could continue running on it?

Related point: is enough known about the OS that third parties could realistically provide their own security updates to it?

Did you try OnLive when it first came out?

Haven't had a chance to.

The point was simply that if you had tried it when it was new and also today, you could have observed that it's actually gotten better.

The theoretical bandwidth/latency problems are absolutely still there, sure. But the environment has been improving such that the practical real-world problems are shrinking on their own. (Not down to zero, of course. But more games are now more playable for more people. Which relates to why Sony is willing to bet on it.)

It's all going to become more viable over time, until at some future date the number of cases where it's a problem is small enough that most people ignore them.

That might work for turn-based games, but real-time games are far more sensitive to latency than the noninteractive movies and television series for which the Chromecast was designed. How much display latency does the Chromecast add?

Did you try OnLive when it first came out? Have you tried it recently? What exactly is Sony planning for backwards compatibility?

(We're talking about the future here. The problems you're talking about are getting better. At some point, they'll get better enough that for most people they won't be problems anymore. It may not be safe to bet on when that will happen, but it's safe to bet that it will happen.)

... in which case that still leaves room for a high-performance dedicated gaming rig to steal the show...

As Moore's Law gets to work on "casual" games, I'm not certain that in the long run there will always be a market for "a high-performance dedicated gaming rig" that's big enough for the console industry to cater to.

My experience has been, the more one is focused on "high-performance gaming", the more one is likely to tolerate the tradeoffs involved in gaming on a general purpose computer instead of a dedicated gaming appliance.

I also believe that some folks are "focused on high-performance gaming" only because they want a certain minimum level of performance that's not so easy to meet with the appliances. I'd say for a lot of people that threshold isn't as high as "60 fps at 1080p".

So, when incredibly cheap games on incredibly cheap gadgets are routinely able to do 1080p at 60fps, I think you'll have the cheapskates and the gearheads, and not an awful lot of room in between for today's AAA-focused console industry to survive in.

(I could easily be wrong. I expect to have fun watching the industry to find out.)

Will Nintendo survive?

Sure. Remember that they were founded in 1889. They had a business before video games, and if necessary, they'll have a business after video games.

I think that's where some of their behavior actually comes from. There's a certain level of autonomy that I don't think they're willing to give up, even if that means their video game business tanks.

The PC didn't kill consoles for the same reason that smartphones won't - People don't want to screw around with variable configurations and unknown levels of performance and controller compatibility. They want a known-working machine such that they can buy a game, put it in, turn it on, and have it work exactly the same way as it did last time, as it does for everyone else, as the manufacturer intended it to work.

I am less certain than you seem to be that smartphone manufacturers will be unable to adequately address that problem.

Let's say you use a succession of Android phones, and your TV has a ChromeCast attached to it, and some particular bluetooth controller becomes a de-facto standard. The experience begins to approach that of a solid console. If it's also extremely cheap...

(Would I bet on this? No, not with my own money. But I wouldn't bet against it either.)

While it's not a complete answer, the degree to which a framework is open source is a significant factor.

If you use a proprietary framework, then it is possible that it won't get updated to support future platforms or that it'll be yanked out from under you entirely.

If you use an open source framework, it may become unpopular and difficult to support, or may even never get very wide support to begin with (cf. "GNUstep"), but the option to "keep it going" is there. Your future is more firmly in your own hands (or the hands of hired experts). It stops being "we have no practical choice and must stop using this" and instead becomes "the cost of using this is going up".

Does this mean "always pick open source"? I won't assert that it does. But, when all things are otherwise equal, some risks are certainly lower with open source.

Another factor is picking a runtime that's got demonstrated portability. You could be running open source all up and down in your own software, but if you were targeting Windows Phone 6 or Blackberry as your target platform, nothing would have saved you. But if you're running in an extremely portable interpreter (potentially including things like the JVM or CLR) that hides the underlying system from you, again, you have options you wouldn't otherwise. (Heck, a lot of Java code can even be portable between the JVM and Davlik.)