The whole purpose of these treaties are to carve out new opportunities for special interests and rent seekers to harvest wealth from the small folk like you and me. Whatever you think of the benefits of free trade, these treaties are created to prevent it, and for no other reason.

I used these things. They really existed. And they made modern IDEs like Eclipse and IntelliJ and Netbeans and Visual Studio look really crude and primitive. The Lisp machines were horrendously expensive, though. The last one that the nice Government bought me cost £25,000 at a time when a Sun workstation cost £4,000. And so we really have forgotten what was possible.

However, the machines we have now are enormously more powerful than the machines we had then. My Xerox 1186 in 1987 had (I think) 8Mb of real RAM and about 80Mb of disk, and ran at two MIPS. My desktop machine at home has 16Gb of RAM and runs at 18,000 MIPS. We really could begin to run the big software development environments of the 'golden age' again, on machines everyone can afford. Clojure and LightTable are a real step in the right generation; but they're still a long way behind where we were thirty years ago.

InterLisp (and a number of other things coming out of Xerox PARC in the early eighties) had the same feature. You saved the running state of your system to file, you invoked the function (sysout). To restore the running state of your system from a file, you invoked (sysin filename). Essentially this was a memory dump of the heap, but it had the special property that the 'spaghetti stack' - the branching stack structure through which InterLisp managed multitasking - was implemented in the heap rather than as a separate structure, so loading in the heap also loaded in the stack, for all threads.

Obviously, in InterLisp as in Smalltalk, everything in memory was inspectable and editable, and when you edited a function that didn't mean editing and reloading a file, the source code was an in-memory structure. It wasn't entirely without problems - there were small semantic differences between interpreted code and compiled code (if I remember correctly interpreted code implemented shallow binding while compiled code implemented deep binding), so that when you compiled your code its behaviour could change. Also it was possible, if you added a comment in the wrong place, that it could change the semantics of a function. For example if you added a comment as the last form in a function body, that function would always return nil. Nevertheless in terms of programmer productivity these environments were streets ahead of anything that's commercially available now; and although I love LightTable and hope that it is the shape of things to come, even LightTable isn't a patch on InterLisp's DEdit.

A small minority of companies, with very special needs, are using NoSql databases for a small proportion of their operations. Those companies do include some big ones, such as Google and Twitter, but still in absolute terms the numbers are small. A tiny minority of companies have moved away from relational databases altogether. But the numbers are statistically insignificant and are likely to remain so for decades. And the relational model does have some real and enduring benefits which will make it the right tool for many jobs far into the future.

Remember this is an industry that advances very slowly indeed. Your bank, and your utility companies, are still using programs written in COBOL - technology which is fifty years behind the curve.

RTFA! It's not used for storing manuals.

Not if you're even considering this legislation, you're not. Your state may not be corrupted by the commercial sector, but it is surely corrupted by the security sector. Not all corruption is financial.

OK, so a pedal bicycle is a very low powered road vehicle, but the same equation applies. To achieve a better power to weight ratio, you can either increase power or decrease weight - and decreased weight has the added bonus of lower loads on suspension and tyres in fast corners.

... that stocks have any intrinsic value?

If we continue burning coal at this rate, human life as we know it won't see 2100. Civilisation? Well, probably cockroaches will one day develop civilisation.

Actually, this is untrue. The world has never faced a technology which had the potential to take out the entire human ecosystem before. Fossil fuels certainly will become obsolete sooner or later - when 90% of the human population has died of starvation, they'll be obsolete. But it would be a much better thing if we could stop using them before we'd destroyed the atmospheric and ocean systems which we depend on for our survival.

OK, so, I'm a hero warrior with a really big battle axe. There's a flimsy door with a little lock on it...

Yes, locked doors can be useful and interesting parts of game puzzles, but make it believable, please! If your first person character is big, strong and well equipped, and you want to make it credible that he can't get through a door, the door also needs to be big, strong and well equipped.

Two things. Programmers are expensive, silicon is cheap. And really good low-level programmers (which I am not and don't claim to be) are (and deserve to be) very expensive indeed.

When you're writing a bit of code which is going to run on hundreds of thousands of processors all over the world (as OpenSSL is), the cost/benefit does move in low-level programmings favour. If you save just a few cycles on each of billions of operations on millions of processors, it's worth throwing resource at that optimisation. But OpenSSL (like the Linux kernel) is a special case. Most perfectly ordinary good programmers will write more cost-effective code using languages which don't require them (for example) to keep track of memory assignment.

Also, most human beings can't hold an effective map in their minds of the operating states of a moderately complex program. And people make mistakes - even the best of us.Software, by contrast, is very good at detail, repetitious, complex tasks like keeping track of what bit of memory has been assigned for what purpose, and noticing when nothing remaining in the system holds a pointer to that data. There are whole classes of programming error which good compilers will simply never make.

I was doing a post-accident audit on safety-critical (closed source) code a few years ago. The reason for the failure was that someone had used strcat to concatenate strings for an error message, where the strings being concatenated were stored in the data segment (yes, think about it for a moment). It cost millions of pounds worth of damage, and it was very lucky no-one died. If the software concerned had been written in (for example) Java, the accident wouldn't have happened. Yet the software had been written by a very senior C++ programmer, and had gone through four separate code reviews before being accepted into service - and all four had missed it.

Since it's intended for space walks, why the ${IMPRECATION} does it needs legs?

I was going to say 'why on Earth', but that's kind of the point. It's not going to be on Earth. It's going to be in zero-gravity, where legs are completely useless.

What, like this, you mean?

Given that the US is (as you correctly point out) among the most profligate and inefficient economies in the world, setting the tax so that it didn't affect the US would mean setting it so that it didn't affect anyone anywhere. which would be entirely pointless.