Supposedly the Bill of Rights was controversial in its day because many of the founding fathers thought it would be unnecessary: the population would zealously guard their hard-earned liberty and the various protections of the Constitution (representational government, separation of powers, etc.) would prevent tyranny. In fact, they feared that by enumerating freedoms they would inadvertently limit them, which is why they ultimately included the 9th amendment to say "hey, this isn't an exhaustive list" [though the practical effect of the 9th has been null].

Fortunately, the Bill of Rights was passed despite being "redundant", and the courts have brought it into play several times when lawmakers worked up particularly nasty bills. Unfortunately, the courts have also weasel-worded their way into listing several exceptions to these amendments (especially where 1, 2, and 4 are concerned).

Looks to me like there's also >1.4 billion Muslims who didn't do any of those things today.

1. Building large math API's aren't a priority for language designers.
2. To do what you're saying, you sort of have to add the operator overloading ability anyway, use it to implement a large math API, and then make the compiler "magically" treat that one API as special. If I were designing a language, I would rather--for both stylistic and practical reasons--just make a thumbs up/down decision on the overloading feature and let the community/marketplace develop their own math libraries.
3. Note that the implementation of a mathematical concept can vary widely. A stock matrix implementation isn't going to be suitable for dealing with huge sparse arrays, for instance. Other implementations may want to use OpenCL/CUDA, decimal math, specific rounding policies... the list is endless.
4. As others have pointed, there is a large range of mathematical ideas to which standard operators apply. Moreover, new maths are being added all the time and it's not unfathomable to invent your own idea to deal with a specific problem domain. (I've done this in production code, for instance, to enable set-like behavior of time-series data that is highly specific to the industry I work in. To be fair, I decided against operator overloading in that particular situation, but it could have gone either way.)
5. These days, there's no real harm in providing the feature. Yeah, it was abused back when C++ was new, but developers got over that. When word processors were new, we all went silly and put 10+ different fonts into our documents, but you don't see that anymore either.

Programmers are more used to structuring their code (using functions, modules, etc.) and using best practices (minimizing globals, separation of concerns, etc.). This was not so much the case in the late 60's. That, combined with the "goto stigma", means that average developers avoid goto usage and good developers know when it's worth it.

We saw a similar backlash with the concept of operator overloading. People abused it in C++, the Java designers overreacted and prohibited it, but most languages since then recognize that "yeah, operator overloading's really nice when you're building an API for mathematical constructs" (like complex numbers, quaternions, and matrices). So it's there in C#, Python, D, Rust, Scala, but (from the little I've seen) people seldom abuse it these days.

Bad marketing: make users feel guilty everytime they try to acquire your product, especially when you are just one of hundreds of derivatives of the same free product (viz. Ubuntu, Debian, and other Linux-based OS'es).

Good marketing: write a blog entry about some trivially controversial aspect of your product and get it posted to a major tech forum for Linux enthusiasts.

Long names are fine and even valuable. The real gremlin is in overly-abstracted API's, code generators, verbose XML configuration files, and other tools/libraries that have sacrificed usability while pursuing long feature lists and total control over a particular problem domain.

It is, in a funny way, the opposite usability trajectory that Gnome and many others in the UX crowd followed when they went off and started zealously reducing features in the name of simplicity.

Personally, I think that the underlying design principles should be the same whether you're designing application interfaces to be used by the general public or whether you're designing API's to be used by developers: in both cases you're trying to take something complicated and make it simpler. Sure, add those new/advanced features when you can, but do so in a way that doesn't raise the learning curve for the most common use cases.

Perhaps you would like to see a list of what really, really crappy government gets you. In country after country, peoples' entire life savings were eradicated by government printing presses. In Weimar Germany, banknotes were best used as firewood.

Does it serve a journalistic purpose?

No. A textual description is all that's needed to convey what happened.

Does it serve a persuasive purpose?

Yes. It's a visceral and concrete illustration of the ruthlesness of $THING. (Where $THING can be substituted with whatever religion, racial group, ideology, or institution that serves your persuasive purpose. For Fox's audience, THING="Islam"; for an atheist it's THING="religion"; for a Shia muslim maybe it's THING="Sunnis".)

Should Fox be censored or penalized by the government?

Hell on. Fortunately, nobody's making this argument. Yay first amendment!

Did Fox help ISIS by publishing the video?

Counterterrorist Malcom Nance (the "Waterboarding is torture, period." guy) thinks so, but I'm not seeing a description of why. Perhaps it's a combination of morale boost and being able to exert fear-control over their own territory. Perhaps (as another slashdotter speculated) they want to provoke the West into military intervention in order to further galvanize the Islamic world against Western influence. On the other hand, gratuitous violence is generally a great way to undermine your own cause; it's hard to imagine the video winning them any friends.These are boy-apes, demonstrating dominance and waving their guns at the cosmos, thinking that they somehow matter.

Should Fox have self-censored themselves for the sake of civic duty?

Ah: that seems to be what the debate's really about, isn't it? Those who think Fox abandoned their civic duty long ago will be tempted to "yes". Those who think of Fox as "too liberal" will say "no". Those of us with a good selection of defense industry stocks in our portfolio will also say "no", while trying to stifle a sudden case of the giggles.

Foreign aid is a vehicle for exerting influence: for instance, to open foreign markets to US exports. You'd be a fool to think there were no strings attached. It's logical (at least in terms of game theory) for the US to exploit it's influence to its advantage, and we certainty do: take, for instance, our strong-arming intellectual property laws into numerous countries. Those laws support US exports (which tend to be soft on tangible goods and heavy on services and content).

I'm not criticizing any of this BTW, just describing the ground in front of us. The concern arises where maybe we're consuming accumulated good will for short term gains. Obviously, ISIS is going to view us as the great satan no matter what we do. But there 7 billion other people out there, and our long term ability to shape the world rests in part on their perception of our government.

The US drops to the bottom of the list once you account for GDP. To be fair, that doesn't account for military presence [which saves Europeans a bundle on defense spending], military intervention [when it's not, um, massively misguided], and the generosity of the American public itself (thru churches and humanitarian organizations).

Yeah, I know what you mean. In talking to several doctors, I get the distinct feeling that I'm on the flip side of what happens when my mother-in-law has a computing problem: she hands me the computer and starts offering endless way-off-the-mark suggestions which I have to forcibly ignore while trying to concentrate on troubleshooting the real problem.

Being listened to makes us feel better (in pretty much any human situation, but especially when our health is on the line). However, we as patients are generally dumping a load of crap on the doc when it comes to listing a "constellations of symptoms". It takes great patience and integrity for a doctor to diligently listen through all of that verbage for the 1-in-a-million gem, and most docs don't have that sort of time.

I'm still learning how to use doctors effectively, and the best thing I've learned over the past few years is that... if you've got a disease that's poorly understood, find the docs who have the expertise on that condition. (And hope they aren't just pill-pushers, I guess.) My general internist thought I needed a pacemaker, the cardiologist controlled the worst symptoms with drugs, and the dysautonomic disease specialist knew what my problem was and established a treatment plan to fix it. Something that was a complete mystery to the first two doctors was a routine case for the third.

While I agree with your general line of reasoning, these numbers look considerably worse when adjusted for deaths/MWh or YPPL/MWh.

In addition, 70 years may be too short of a time period for evaluation. AFAIK, nuclear plants aren't designed to withstand war, and we also haven't see that many plants retire.

(1) Your average user would not be able to implement this hack. Technical users would have to research/experiment/tinker and/or wait for other technical users to do the same and publish their results. This buys time (see point 2).

(2) It makes the drone maker look good and reduces the risk of kneejerk legislative responses.

(3) Anyone who modifies their device to do this will receive the blunt of the blame. Blame will be apportioned less to the manufacturer, the regulations, or the general concept of consumer drones and more to the individual. Instead of being portrayed as a drunken fool doing something dumb but ultimately harmless (like the guy in the recent White House incident), the media will portray them as a shady hacker with possible terrorist intentions.

(4) Prosecutors who want to hang the operator out to dry will probably find more legal hooks to do so, since the operator intentionally disabled a "security" feature.

(1), (2), (3), and (4) are all good things for the manufacturer, who's market lives or dies by legislative and regulatory edict. That makes this worth doing, even if there's a jillion ways of undoing it.

The cost is paid for by some combination of shareholders, employees, customers, and insurers. You can't really say what that combination is. If you magically eliminated all ATM thefts/fraud, most of that benefit would go to either shareholders or top-level management. However, if the labor market were tight, that benefit might go to higher salaries for ordinary employees. Then again, if competition is fierce, the savings might be used to lower fees or pay higher dividends on interest-bearing accounts. Perhaps something more complex would happen, like hiring additional programmers so more work process could be automated, thereby resulting in layoffs for other personnel. All of these outcomes have more complicated second level effects, since they would ripple through the economy at large.

What you can say is that we as society pay at large, since the damage to the machine/building is a net loss for humanity, and the effort of participants (police, bank personnel, ATM designers, and even the burglars themselves) could have been better spent on their next best opportunity cost. (The one exception might be if these were subsistence burglars, in which case the overall cost to humanity can be harder to calculate.)

Easily solved:

BUY NOW!! Super-fast-ultra-speed internet** is available in your area!!

**Up to 1Mbps or beyond!
(And oh yeah, we'll still hijack DNS NXDomain responses, throttle Netflix/bittorrent, keep connectivity records, and spy on your traffic w/o a warrant.)