But that's exactly what we do to airline pilots. The more automated the planes become, the more requirements we put on the pilots (to understand all the automation). And we still require them to take charge and solve the situation when the automation fails, even though they are now well and truly "lulled".

Why would/should cars be any different?

Let's try it on an airliner: "Either the airliner is autnomous, or it isn't. If it isn't autonomous I'll drive it myself and be in control the whole time."

Doesn't really work out. The pilot-in-command is always responsible for the safe operation of the aircraft, even when the aircraft is "flying itself". Now of course there are limits to this responsibility, if an engine falls off due to shoddy maintenance that's usually not considered a pilot error. But complex computer malfunctions are more often than not blamed on the pilot (too much so to my mind, but that's another question).

I foresee that we'll see the same development with "autonomous" cars (i.e. cars with advanced auto pilots). They'll do better on average than a human, but when the malfunction you (the "driver in command") will be left to pick up the pieces, if there are any pieces left to be picked up. As with piloting, you're average workload will decrease substantially, but when things to wrong, you now have a much more complex situation to deal with, and no time to do it. The maximum requirements on your performance actually increased even though the average decreased. If the NTSB can still say "pilot error" 99% of the time, then it'll be "driver error" 99% of the time with autonomous cars.

And like with aircraft you'll like it, since the average is long and dreary and malfunctions will be so few and far between that you can functionally ignore them.

"Sleeping in the back seat" will be just as much frowned upon as it would be in an airliner. Leaning back and having a cup of coffee would be about as far as you could stretch it.

So make one. Or is your argument that a) there might (big "might") be differences between regulatory structure and cost between Romania and the US that would make internet infrastructure in Romania cheaper to build, b) when observing that the rest of regulated high cost Europe also has much better and cheaper access to same, that "I'm right about Romania and I don't know about the rest"?

That's not an argument at all. Not even about the Romanian situation. Especially about the Romanian situation.

So what is your argument about the Swedish situation then? As you agree the supposed argument about the Romanian situation doesn't work to explain the differences between the US and most European countries when it comes to differences in internet adoption/cost/speed/caps etc.

No, that's something I've also only heard about as a cautionary US tale. If that's happening in Europe as well, I'd also like to know.

But of course the same is true about Sweden, and almost all European countries.

For example: I have 100Mbps/100Mbps + cable tv (basic) + phone (calls extra) for $50 (and that's just because your exchange rate sucks right now). No caps, of course, there are no caps on fixed line internet, and servers etc. are OK (no outgoing SMTP, that's the only limitation).

So you want to try that argument about standards and cheap labour again?

What? Are you seriously suggesting that we have less regulation and cheaper labour in my native Sweden than in the US of A?

That's a new one... And that's as far as I can tell the only merit that argument has.

Not really, it's more that you can make a game moddable without making it scriptable - for instance, I remember many different "packs" for Civ II which consisted of customised maps, updated graphics for units and terrain features, and its own copy of master XML file that listed all the units, technologies, buildings and more with all their data - costs, attack values, prerequisites etc. It's amazing what can be produced just by changing some data, and most games don't really need to be any more moddable than this.

Civ 4 does some of the AI in Python, IIRC mostly evaluating heuristics for moves, but most of it is C++. The SDK for customising the AI came out about six months after the main SDK, it wasn't originally designed to be exposed to Python.

But I agree that the hybrid approach is a good one, especially as I feel you're overstating the cost of using two different languages together - neither Python nor Lua are very hard to integrate with C/C++ at all, even without tools like SWIG that automate a lot of the boilerplate required. And if you're developing games in C++ you should probably be capable of picking up Python/Lua pretty quickly, my first coding job involved writing custom interfaces in Python for our CMS application, exactly the same thing as you're talking about, and I learnt Python as I did it - didn't take long to pick it up.

I was under the impression that the "plug" (called "freeze valves") concept worked really well in the MSRE, with sources even claiming this was the normal mode of shutdown over the weekends. Cut the power to the cooling fan and the reactor would drain the salt into the storage tanks quite undramatically. (See e.g.: http://nucleargreen.blogspot.s...).

Now of course in this design you didn't need cryogenic cooling, since salt freezes at a rather high temperature. So I'm wondering what the scoop is? Are proposed new designs operating in a region where simple "blow on a pipe" that worked so well at the MSRE not possible anymore?

Cheers for reminding me, I shall put it on my list of books :)

I've read the first two trilogies, got lost along the way after that... will have to pick them up again at some point if the third actually continues the first trilogy. It's been quite a few years though.

I enjoyed the Gap Cycle, but I'm not sure I'd re-read it.

Still not quite sure how that applies to the topic, but it has reinforced that my decision to stop reading Dune about 20 pages in was the right one :)

I have no idea what you mean by that...