Neither of the hostages were "operatives" to be compromised. The U.S. citizen worked for USAID; he was a foreign aid worker (USAID administers the distribution of U.S. foreign aid money). Calling them "operatives" that were "compromised" (when they were both aid workers working entirely above board) makes it sound like some CIA cover op gone wrong. Please at least read the article before blaming people for ops gone wrong when nothing in fact went wrong.
Pedantic: Neither Pakistan nor Afghanistan are typically considered part of the Middle East. Aside from the majority religion, they have little in common with the Middle East.
Which is likely why electric car manufacturers are adding artificial noise at low speeds and letting tire noise handle it at higher speed. My Leaf emits a "strobing" sound below 18 MPH; above that, it stops on the assumption that the tire noise is enough.
Also, there are arguments to be made that roads are a public good and should be paid for by the public as a whole, not as a premium good for the wealthy. I'm personally opposed to express lanes and toll roads in general; I can (to a limited extent) support tolls on bridges and tunnels that are unusually expensive to build and maintain, but otherwise roads should be funded by gas and car registration taxes and available to all on an equal opportunity basis, no special access for the wealthy.
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?
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.
The reason I don't like gambling is because statistically I know I will lose. I mean sure you could hit a big jackpot or something but you have better odds of being hit by lightening and killed when you step out of the casino . I don't play against odds like that for the same reason I don't expect to get struck by lightening.
You're far more likely to win a big jackpot than to die on exposure to moderately increased illumination, near a casino or otherwise.
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).
I wouldn't have normally bothered, but the distinction is relevant given TFA. The switch to an acellular version of the pertussis inoculation is what reduced the duration and efficacy of protection. It's not that the old pertussis vaccine was ineffective, it's that we've been using a different vaccine for the last 20 years, give or take, and the new vaccine ended up losing a lot more efficacy than they expected.
I agree that a good shared standard might allow for efficient production of batteries by removing the market fragmentation that dissuades people from starting up "gigafactories".
That said, Tesla hasn't demonstrated a superior battery technology. The 2013 Leaf's range was rated lower than it really should have been. It offered a "Long life" charging setting, where it would stop charging at 80% instead of 100% to extend battery life. The EPA decided to base the estimated range on a 90% charge to split the difference between the two options, because the 80% charge was "recommended". Tesla allows you to stop charging at any 10% increment between 50% and 100%, but because lower charges aren't "recommended" the EPA assigned a range based on a 100% charge.
Factoring that in, at 100% charge, the 2013 Leaf should have a range of ~84-85 miles. Assuming 84, on a 24 kWh battery pack, that's 3.5 mi/kWh. The Tesla gets ~3.1 mi/kWh. The Tesla is heavier thanks to all those extra batteries, which is a big part of the difference; I suspect that if you made a Tesla with a 24 kWh pack, it would have similar efficiency to the Leaf. Battery tech is hard to improve; Tesla and Nissan are using the same basic tech.
TL;DR: Stacking more batteries is hardly a demonstration of superior technology.
Not according to Nissan's website. The base S model has a 3.6 kW charger. You can add a charge package for $1250 that upgrades it to a 6.6 kW charger and adds a Quick Charge port, but the base model doesn't support 6.6 kW charging or a Quick Charge port by default (similarly, the mid-level SV model comes with a 6.6 kW charger, but requires an add-on package to get Quick Charge). Might be hard to find a completely base S model without the charge package, but Nissan claims it's an option.
Slashdot Mirror
Neither of the hostages were "operatives" to be compromised. The U.S. citizen worked for USAID; he was a foreign aid worker (USAID administers the distribution of U.S. foreign aid money). Calling them "operatives" that were "compromised" (when they were both aid workers working entirely above board) makes it sound like some CIA cover op gone wrong. Please at least read the article before blaming people for ops gone wrong when nothing in fact went wrong.
Pedantic: Neither Pakistan nor Afghanistan are typically considered part of the Middle East. Aside from the majority religion, they have little in common with the Middle East.
Yeah. Cause sending more guns into impoverished neighborhoods has always led to good things. It's not like they'd, I don't know, get stolen?
Methane is CH4. The C is for carbon. Come on people!
we died in snowstorms for decades without shutting down at the mere hint of a blizzard
FTFY.
Which is likely why electric car manufacturers are adding artificial noise at low speeds and letting tire noise handle it at higher speed. My Leaf emits a "strobing" sound below 18 MPH; above that, it stops on the assumption that the tire noise is enough.
Man, if Maryland public education is that bad, how bad must the other 49 states be?
Also, there are arguments to be made that roads are a public good and should be paid for by the public as a whole, not as a premium good for the wealthy. I'm personally opposed to express lanes and toll roads in general; I can (to a limited extent) support tolls on bridges and tunnels that are unusually expensive to build and maintain, but otherwise roads should be funded by gas and car registration taxes and available to all on an equal opportunity basis, no special access for the wealthy.
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.
The reason I don't like gambling is because statistically I know I will lose. I mean sure you could hit a big jackpot or something but you have better odds of being hit by lightening and killed when you step out of the casino . I don't play against odds like that for the same reason I don't expect to get struck by lightening.
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).
I wouldn't have normally bothered, but the distinction is relevant given TFA. The switch to an acellular version of the pertussis inoculation is what reduced the duration and efficacy of protection. It's not that the old pertussis vaccine was ineffective, it's that we've been using a different vaccine for the last 20 years, give or take, and the new vaccine ended up losing a lot more efficacy than they expected.
I agree that a good shared standard might allow for efficient production of batteries by removing the market fragmentation that dissuades people from starting up "gigafactories".
That said, Tesla hasn't demonstrated a superior battery technology. The 2013 Leaf's range was rated lower than it really should have been. It offered a "Long life" charging setting, where it would stop charging at 80% instead of 100% to extend battery life. The EPA decided to base the estimated range on a 90% charge to split the difference between the two options, because the 80% charge was "recommended". Tesla allows you to stop charging at any 10% increment between 50% and 100%, but because lower charges aren't "recommended" the EPA assigned a range based on a 100% charge.
Factoring that in, at 100% charge, the 2013 Leaf should have a range of ~84-85 miles. Assuming 84, on a 24 kWh battery pack, that's 3.5 mi/kWh. The Tesla gets ~3.1 mi/kWh. The Tesla is heavier thanks to all those extra batteries, which is a big part of the difference; I suspect that if you made a Tesla with a 24 kWh pack, it would have similar efficiency to the Leaf. Battery tech is hard to improve; Tesla and Nissan are using the same basic tech.
TL;DR: Stacking more batteries is hardly a demonstration of superior technology.
Not according to Nissan's website. The base S model has a 3.6 kW charger. You can add a charge package for $1250 that upgrades it to a 6.6 kW charger and adds a Quick Charge port, but the base model doesn't support 6.6 kW charging or a Quick Charge port by default (similarly, the mid-level SV model comes with a 6.6 kW charger, but requires an add-on package to get Quick Charge). Might be hard to find a completely base S model without the charge package, but Nissan claims it's an option.