Quite.

"Every day I find my bike tyre has gone flat, and my crappy pump takes 10 minutes to inflate it. So I'm getting a better pump."

Both rate-limiting and captchas protect against brute force password attacks.

Whether you need both (or either) is up for discussion, and probably depends on your application.

Security is often annoying. Entering passwords is annoying. Getting RSA keyfobs out of your pocket is annoying.

When it's used to protect against brute force password attacks, a captcha is definitely a security mechanism.

When it's used to discourage spam, well, it's on the edge of the fuzzy area most people understand by "security". It's protecting the availability of a service, against the threat of spam making it unusable.

Fine. Add that to the criteria.

"Just" get an API and some SLAs standardised, and it's fungible.

You don't care whether it's hosted in Elbonia or next door. You don't care how it's stored. You care about measurable things like transfer speed and disaster recovery performance.

I find it pretty easy to imagine fungible cloud services. Define some standard APIs. Define some standard measurements of quality/quantity. Done.

For corn it's more complicated than "corn is mostly corn no matter which farm you buy it from" - there are standards for grades.

But it is like coal -- or it can be made to be like coal.

You can't buy as much coal as you like at an arbitrary point in time - because there's only so much coal already mined, and it takes time and money to mine more.

If lots of people want coal at the same time, the price goes up. If you buy coal at a time when few other people want it, it will be cheaper.

Make computing resource fungible enough - by standardising the API and the measurements of quality/quantity, and you can certainly treat computing resource like coal. "I could chew through this dataset on Amazon's servers for £10, or on IBM's servers for £9."

Pointer arithmetic is missing (good).

I worked in Rexx on MVS and OS/2 in the early 90s. I'm astonished it's not dead and buried.

The smart thing to do is use Jython, JRuby, Groovy.

Then you can write in Java when the problem demands it, and in something more expressive when you're gluing it together. And you have access to all the thousands of libraries Java has.

I saw a JRuby presentation in which they said they expected JRuby to outperform native Ruby -- because the Ruby runtime is written by a few guys, whereas the JVM has half a campus full of incredibly clever people, just working on making it run Java Bytecode as fast as possible.

... and as OP said "If I want to develop games, I have all the tools necessary as well." -- there are cheaper ways to code games.

If you specifically find entertainment in programming within limitations - low RAM etc, then this could be a fun environment to play around in. You'd have to live with the fact that the potential audience for a game on this platform would be tiny.

If you want to to produce something for your portfolio - to show to potential employers - I guess this could be an option. "Look I wrote this game. I wrote it to be portable to demonstrate that I can do that. Here it is running on a PC. Here it is running on Android. Here it is running on Arduino. The last one shows that I can code for systems with limited resources."

I'm not sure it would be nice. All sorts of things are unrealistic in GTA. You can speed, run red lights, smash into cars and buildings, run over pedestrians (if there's not a cop right there, without becoming the target of a police manhunt. You can shoot someone dead, in full view of a policeman, and if you can hide in an alleyway for a few minutes, they'll forget you ever existed.

All of this is in the service of creating a fun game.

A mode of operation in which you can "come quietly" doesn't add to the fun.

(Although in earlier GTAs there was the "Busted" option, where a cop touches you. Instead of respawning at a hospital, poorer, you respawn outside a police station, poorer.)

SNES and Gamecube are two generations apart.

You could probably run MythTV on a series 1 TiVo. It would probably perform like a dog.

One of the closed-source proprietary pieces TiVo put into the software, was their filesystem optimised for PVR use patterns. The system could write a compressed SD stream to disk, while reading another, only with the help of a filesystem designed for the purpose.

Within about a year of the first TiVos coming out, commodity HDDs were fast enough to do the same job using an ordinary ext2 filesystem.

I don't think it's DRM that's stopping you from running MythTV on a TiVo.

I don't know where you're going with this. I think economics is a valid area of study. Whether it's a "science" or not is a matter of semantics.

Exponential economic growth has happened. I'm not sure it's sustainable. What does it have to do with anything?