Well, all the other installations are being used to run five year old unpatched copies of WordPress. But the underlying PHP is totally up to date!

How many tax subsidies finance into your average power plant? How much are the indirect costs (ignoring CO2 emissions, let's just focus on locally increased health care costs from coal pollution, long term storage costs for nuclear waste, military adventurism for oil, etc.) of "traditional" fuels?

Demand for power is lowest midday? Funny how time of use metering charges you more for daytime usage due to high demand. Must be a scam.

More like the "personal privacy" bandwagon, which Slashdot (and most internet denizens) have been riding for over a decade.

Whoosh...

How is this even noteworthy technologically? He's assuming he can modify the router firmware. "If I completely replace the software handling my data, I can change the data!" Seriously? That's the dumbest, most obvious thing possible.

How does that make sense? The risk of brand theft is higher with a more widely recognized product. If I introduce Coca Cola branded headphones (to name one of the few things Coca Cola doesn't stick their name on yet AFAIK), my sales would be boosted by the brand name association Coca Cola built, not the merits of my product. That's why trademark protections exist; to avoid borrowing/stealing/damaging (if the product sucks) other companies' reputations unfairly.

Except mortality rates have stalled out in many first world countries; shitty nutrition is canceling much of the advances in modern medicine.

You're far more likely to win a big jackpot than to die on exposure to moderately increased illumination, near a casino or otherwise.

It means that 4% of the time, the results could occur by chance. How many different soda studies have there been?

Most high level scripting languages (can't speak for PHP, but it's true for Perl, Ruby and Python) implement simple user defined objects as dictionaries. That said, the lookup cost, while obviously much higher than pre-compiled v-tables, are not as expensive as you might imagine; attribute access uses interned strings, and strings cache their hash code on first hash. If you don't actually have to recompute the hash, and equality checks are (for attribute lookup) a simple reference identity test, the CPU costs are basically nil, you just have the issue of page faulting due to "random" access into the hash table (and Python at least optimizes for that case; the collision chaining algorithm in recent versions of Python tries to chain into the same cache line if it can, alternating with chains by "long steps" to avoid issues with consecutive hash codes).

Stuff that kills Python performance includes: Minimal optimization of code by the byte code compiler, and none by the byte code interpreter (while each hash table lookup is cheap, a loop will perform it over and over again, even if you're accessing the same attribute on the same object, because the compiler and interpreter aren't sophisticated enough to recognize what's happening); inability to parallelize CPU bound tasks using threads thanks to the GIL; lack of "primitive" types, so even basic math involves substantial memory allocator overhead and memory fragmentation, etc.

TL;DR: Python's performance problems aren't primarily a result of hash tables.

Gets worse if you own an electric vehicle. My power company has a neighbor comparison tool, where it compares my electric usage to similar neighbors (the nearest 100 houses of roughly the same size, same heat/AC systems, same number of occupants). I reliably came in between #2 and #5 lowest electric usage. Until I bought a Leaf. I'm still in the top 20% "most efficient", but only barely, thanks to the $20-30 of electricity it takes to fuel each month. Because I got rid of a 20 MPG rusting to pieces junker for a 115 MPGe vehicle, my performance on the one metric of "home electric use" went down.

The ability to seamlessly use + with mixed text and numeric types in a language without explicitly declared types is usually considered a design flaw, not a positive feature. Perl uses separate operators for strings vs. numbers to avoid ambiguity, while Python and Ruby require explicit type conversions. Java defaults to string concatenation, but Java requires explicit types, so you get a compile time warning if you make a mistake like adding a String and an int and expecting an int. Even PHP, the go to standard for poor language design, which explicitly rejects separating operators for strings and numbers, made a concession for addition vs. concatenation and borrowed Perl's approach of using + for addition and . for concatenation so the operator itself selects the operation.

The sole exception to this rule that I can think of is JavaScript, where + is type dependent, and it lacks explicitly typed variables. The fact that you're allowed to use addition with silent coercion to String if either operand is a string is explicitly called out as one of the Awful Parts in JavaScript: The Good Parts, which should tell you something. Basically, implicitly typed scripting languages should prohibit implicit type conversions when they use + for both addition and concatenation. The alternative is to behave incorrectly silently.

As for the ternary operator, really? That's your big gripe? The fact that it reads like an English sentence? Guido hates excessively concise/cryptic punctuation as language elements, so they chose something that reads a bit more like English; if you read it aloud, e.g. "a if a is not None else b", it makes sense. You could also view it as a stealthy attack on the ternary operator, which many people despise as encouraging cryptic code. Either way, we're not talking about something truly ridiculous here; it's a reasonable design decision. This isn't PHP's left associative ternary operator or anything.

Odd that Anders Hejlsberg's more recent (and at this point, probably more widely used) lead role in developing C# isn't mentioned. Turbo Pascal is ancient, and doesn't hold up so well.

I really hope 3.x, if only for the fact that your code tends to work with non-English text by default, because str supports the whole Unicode range, so it works with non-English input by default. Compare to 2.x where you have to make a conscious effort to work with Unicode. Particularly important for third party libraries, where they aren't producing a final application, and often don't think about Unicode at all even for text based APIs. Heck, the Python built-in csv module in 2.7 doesn't work properly with Unicode; you have to load or convert as UTF-8 bytes, parse, then decode to the 2.7 unicode type. It's a mess.

For teaching purposes 3.x is even better, since you have a proper distinction between binary data and text, rather than the mushy 2.x situation where str is sometimes binary data and sometimes handicapped text, while unicode is always text, and sometimes interoperates with str, while at other times it explodes. Teaching languages should be consistent, and 3.x is simply more consistent than 2.x (largely because of cleanup decisions like this).