Quoting the Wikipedia article on seed banks:

The bad news is that recalcitrant seeds can't be stored this way, so no cocoa, mango, avocado, or rubber.

Came here to say that. I remember one study/book that concluded people "naturally" have a 25-hour clock. Study participants lived in a (working) hospital with randomized staff schedules and all the clocks taken down, so it may not have been as pure as some other experiments on the matter. The participants had to wake up and go to sleep as a group so their schedules stayed in sync.

That and bad PR. I had to do a job at an industrial site in a room with very poor chairs. We wheeled in better ones from an adjacent conference room, but then had to put them back and suffer back pain for ~2 days until the union could be bothered to wheel some over from a storage facility. A woman I know got written up for moving debris out of the path of her cart... debris that had been placed there by union members to purposely bait her (as a somewhat dumpy, absent-minded individual she was a natural target for practical jokes). Another man had the audacity to plug in his own telephone at a new job, and had to lie-lie-lie about it to the union guy who showed up to do it ~3 days later.

I know that unions hold charity events and make other positive contributions to the workplace, but extreme nitpicking on trivial work and fraternalistic pranks won't help reverse America's trending negative sentiment toward them.

I've come to like the flatter look. How many bevels, gradients, shadows, and reflections do you need to show that a button is a button? In an Android app, a simple black and white icon is usually sufficient. Desktop apps may benefit from a little more polish, but the long term trend has been to use less and less "chrome" to indicate that a screen region is actionable. (If you're old enough, you'll remember how simple/lightweight hyperlinks were when you encountered them for the first time... just some blue text and an underline!)

If anything, these Windows 10 icons aren't flat and "iconic" enough. They should be aiming for something even simpler, like how the Visual Studio 2012/2013 designers used mostly simple silhouettes, with a handful of subdued colors for visual separation and emphasis. (The proposed Windows 10 icons are also just ugly. And what's up with turning the folder sideways?)

I think there's a parallel here to Edward Tufte's aesthetic that every piece of ink on a graph/chart must convey something meaningful about the data to the user. Any unnecessary element is chartjunk. Smartphones have forced us to apply the same thinking to UI design, and while some designers will inevitably take it too far (like Android did with the triangle/circle/square thing in KLP), we're headed in the right direction. Our chief scarcity is human attention, so it makes sense to generally de-empasize UI elements to the point where they don't ask for more of the user's attention then they deserve.

Noah's Ark is an especially good example of proto-SciFi: it's got a technically advanced ship that the hero uses to survive the disaster, saving the world [though not the human population] in the process. Of course, god instigating the disaster and the hero becoming a drunk afterwards aren't exactly hallmarks of the genre, but it's really easy to imagine ancient egyptians/mesopotamians being plagued by flood and thinking "you know, what if we built a really large boat?". Many sci-fi stories today seem to center around the same two-part idea of (1) imaging a real-life concern growing out of control [thereby radically altering the world] and (2) using a novel technical artifact to surmount those circumstances.

I've heard that "element hiding helper" can assist with this. However, it's also easy to right-click on an item in FireFox, select "Inspect Element" and then figure out a rule to hide the content (though you'll have to consult the documentation). For instance, Slashdot has a "Site Notice" that will appear at the top of every page (unless you accept the cookies/whatever to suppress showing it). I added the rule "slashdot.org##div#sitenotice" to suppress it (though it has since been added to EasyList).

For those who are unfamiliar with it, Request Policy works a lot like NoScript... it lists the domains that the page is trying to load *any* content from (not just scripts), and you whitelist which cross-domain loads you want to allow. On slashdot, for instance, I'm allowing requests to fsdn.com, but disallowing them to gstatic.com and scorecardreasearch.com.

I use it myself, but I can't recommend it. Too much of the web breaks. Credit card payments that bounce to a payment processor's website are especially problematic (I've gotten double-billed at least once). And using it in front of other people is especially awkward when I have to fiddle with a new site for a few minutes to get it to work. Also, I don't know that this provides that much better privacy than AdBlock+EasyPrivacy or some of the host-file blacklists.

Maybe with some extra development Request Policy could be a lot easier. Integration with (or incorporation into) NoScript and/or a community of well-maintained whitelists would make a big difference.

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.