... 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.)

From my experience, the hardest thing for a programmer that because code may look weird or ugly is NOT a reason by itself to change it. The only reason to change it is if it is buggy, or does not meet the current requirements.

I don't really agree 100%.

Often, code looking weird or ugly is a hint that the code is less easy to maintain than it might be. Changing code so that it's more easy to maintain can be a very big win in the long run.

If it's going to be weird or ugly, and there's a good reason for that, document it.

...I was hoping to avoid the 2038 bug.

For me, I think the hardest part is often "figuring out what to build in the first place". Sometimes that starts from a product idea. Sometimes it starts from an imperfect requirements document. (I have never seen a perfect requirements document.) Going from that to "what do I build?" is the hardest part.

If you are the sort of programmer who works on big projects and is handed a clear and unambiguous spec... then sorry, I have absolutely no idea what your hardest problem might be.

You are not going to write everything from scratch by yourself. You're just not. Not if you actually want to get anything done. You're going to reuse code.

So: figure out what code you're most likely to reuse, what frameworks are useful in the field you're interested in, and let that suggest the language.

If you don't know how to get started on that: asking the question of peers in the same scientific field will get you a more useful answer than asking the question on a wide-open generic technical forum.

Another angle: look at what network databases you want to integrate with (eg. protein databases at nih.gov), and look for sample code showing how to access 'em. That'll give you a clue what other practitioners are doing.

...that I do my best not to talk to gamers.

Now, will people who exclusive use PS/Xbox switch? I don't think so easily.

Some of us may.

I am not a regular Windows user, and haven't been for over a decade. (I try to use it a little, to keep my familiarity up, but I just can't really get work done on it.) I also have zero interest in going back to building systems myself. For my general computing, I use a mix of portable devices and MacOS and Linux systems.

I also just do not like gaming with a keyboard and mouse. I know lots of people do, I know the arguments in favor of that scheme, but I personally have less fun when I'm gaming with a keyboard and mouse.

So, I've been on game consoles for a while now.

But the PS4 and XB1 have put me off. I'd embrace the Wii U if I thought there was a realistic chance publishers would, but evidence seems counter to that.

If I can get a cheap pre-built Steambox, that may take over for my own gaming. I would not be getting a bleeding-edge machine, and would probably not be able to play "current" titles, but that's okay. I'd never have the display set higher than 720p anyway, and there's enough of a back-catalog there to keep me busy for a few years at least.

If they can put together a steambox that meets that kind of need for, oh, let's say in the area of $350, then I'm most likely in.

(Otherwise, I'll probably just keep my current hardware going as long as I can, set up WINE and DOSbox on my other systems, and try to wait out this generation. Or maybe Android and iOS will hold my answer.)

What's wrong with just letting every user delete their data on request? Then you don't have to worry about anyone's age.

From whose point of view?

From the site provider's point of view, for sites like Facebook and Google+: there's a huge economic incentive to not delete the data ever, since there's potential to monetize it. So they won't stand for that, and will lobby against it. Most places, that "wins". Apparently, in California, "it's for the children!" can sometimes trump that.

(We've got to come up with a new business model for internet content.)

I don't think it is reasonable to judge someone based on what they said many years ago. People change. People grow up and become adults.

IMHO, the only answer that will really work in the long term is to change the standards of judgment, not to change the mechanics of remembering.

(Working on it.)

If you define the scope of the right to be forgotten to include only information that you put out there on sites with which you have a relationship (e.g. Facebook, Google+, Twitter, etc.), then it's not only possible, it's easy.

That depends on the architecture of the system in question.

Consider a blog-like system that lets people post information, but it's not stored in a database. It's thrown into flat files without metadata linking it back to the author. The data from multiple users is intermingled.

Those flat files are then distributed to other users via P2P networking (perhaps with content checksums stored centrally for validation purposes).

How would you comply, given such a system?

What we've got here is a law that will have the side-effect of enforcing particular software architectures (by penalizing some more than others).

So you are saying you WANT push but your previous message for some reason excluded them. But iOS7 allows apps to respond to push notifications without the user being alerted, so there's no reason not to implement it that way.

A reason not to implement it that way is, then the software isn't all running on the device. You need additional infrastructure to support sending the push notifications.

If you had "full multitasking", you wouldn't need that. Jabber and IMAP do not (usually) come with those "built in". So I can't get a generic Jabber client and have it talk to my employer's Jabber server and have it work in the background without giving any credentials to a third party or running other off-device software.

Maybe you were just going a round about way to saying there is no way of making sure that a background is serviced every X seconds. And for sure that is right. By design. Polling is not a good way to design network apps for battery powered devices.

I am in full agreement. That's why it's a bad idea to put "full multitasking" on a battery powered handheld device.

I'm not saying "what Apple is doing here is substandard or bad". I'm saying "what Apple is doing here still remains pretty far from 'full multitasking'". (Some people seem to have a hard time taking that as something other than a value judgment, but it's not one.)

They're actually being pretty darned clever. There's a few more things they need to do, and I suspect they'll eventually do them.

(The biggie that I still see missing: on-device triggers. A third party app that interacts with contact information ought to be able to execute code upon the addition of a new contact, whether it's entered into the "Contacts" app, or picked up by background sync from iCloud or Exchange or something. For example. For another example, "OmniFocus" ought to be able to get a timeslice when a "Reminder" is created or modified.)

And of course, he's such a classy guy that his "surrender" communication basically drew an equivalence between "people said bad things about me on the internet" and "rape". What a charming fellow he must be!