That's ignoring the indirect subsidies. For example, how much has the government spent on diplomatic, military, and economic pressure on the middle east to try to keep oil prices stable? How much was spent on subsidising the federal highway system, which promoted demand in petrol? How much was spent on the tax system that incentivised US car manufacturers to produce fuel-inefficient vehicles by treating SUVs as trucks and giving them a lower tax rate?

GFLOPS by themselves are a pretty meaningless way of assessing any processor. If it's bottlenecked by memory bandwidth in common usage, then it's no good. For example, the PowerPC G4 beat any Intel chips at launch in terms of FPU throughput numbers and Apple was happy to shout about this, neglecting to mention that it was only really true if your workload was almost 100% fused multiply adds and your data fitted into L2 cache. In a modern GPU, the performance of the compiler, the threading model and the memory controller can more difference than the raw floating point throughput on the optimal path. Of course, that's not to say that the Tegra 4 GPU doesn't suck at these as well, just be careful when comparing a complex system by a single value.

They're only useful if you can guarantee that there will never be any frames on the stack that were not written by you (and therefore may contain __attribute__((cleanup)) in C, or exception catch / finally blocks in other languages), and if this is the case then there are far cleaner mechanisms for achieving the same thing.

You're missing the point. Developers may pick the language, but if you've only hired a tenth as many programmers for language A than as for language B (because those who use language A are ten times more productive), then when you come to start a new project you'll have ten times as many advocates for language B as you do for language A. Which language will your development team pick?

The designers or Ruby wanted Smalltalk with Perl syntax. I find it amazing that anyone could look at Smalltalk and think 'the one thing this needs to make it better is Perl syntax'. And you can substitute pretty much any language for Smalltalk in the last sentence.

You have to invent your own strings with C++ too. Qt, WebKit, LLVM, and ICU, for example, all have their own string classes. And they don't interoperate in any clean way because (for performance, in that special C++ sense that means microbenchmarks only) they don't use virtual functions and so you can't use an adaptor to turn one into the other, you must copy the data (yay, O(n) operations) at the boundaries between libraries.

As long as you don't nest them and you never need to do any cleanup (e.g. release locks) on the stack frames in between the longjmp and setjmp...

This is one of the sayings that's always bugged me. It's true, but that's because the first thing that a good workman does is pick appropriate tools, or build them if they don't exist. Many of the great scientists, artists and craftsmen over the decades have been as well remembered for the tools that they created as for the things that they did with the tools, yet this saying is often used to mean 'put up with crappy tools, their limitations are your fault,' when it should mean 'if you are failing because of bad tools, it's your fault for not using better ones.'

There was a point made at the 30-year retrospective talk at last year's European Smalltalk conference. If you have two languages, one of which allows developers to be more efficient, then you will end up needing fewer developers for the same amount of work. Unless your entire company uses this language and never experiences mergers, then this group of developers will be outnumbered. When you begin a new project or merge two projects, management will typically decide to pick the language that more developers have experience with. If you have a team of 100 C++ programmers and another team of one SilverBulletLang programmers, then it seems obvious that you should pick C++ for your next project because you have vastly more experience within the company in using C++. The fact that the one SilverBulletLang programmer was more productive doesn't matter. In the real world, languages tend not to be silver bullets and so the productivity difference is more in the factor of two to five range, but that's still enough that the less-productive language wins.

The first C book I read spent most of the first chapter justifying why you'd use a high-level language like C instead of assembly. How times change...

And yet you'll frequently see ordinary Americans vocally defending the rights of a small subset of the population to control the vast majority of the country's assets, which naturally leads to this same subset being much more able to influence the political process.

Not even remotely true. A full explanation of why you are wrong would take up far more space than a slashdot post. Please read at least the first chapter of a textbook on UK politics.

The UK has a written but not codified constitution. If you don't know the difference, then pick up a politics textbook and learn something before you start trying to sound knowledgeable in discussions about the subject.

Not really. In a species with a relatively long gestation period and few offspring per litter, the limiting factor in population growth is the females. A primate female can only produce a very limited number of children over her lifespan (especially compared, for example, to rodents) and a significant fraction of those won't survive to adulthood anyway. A reproductive strategy that involves killing even more of them off is going to leave the tribe very weak and so the survivors may have benefitted from the process, but that only matters in evolutionary terms if they survive long enough to breed, and do so in comparable quantities to others with different strategies.

If you think this means that it's not evolved behaviour, then I can only assume that your education in evolution stopped just after Darwin. Try picking up a textbook written in the last 30 years. I'd recommend The Extended Phenotype (published in 1982).