smitherfield

IME, driving in Boston seems to involve the most potentially-deadly situations given the number of pedestrians and cyclists. Twice in the past year driving on Comm Ave I've had to swerve into the left lane to avoid hitting one, first a cyclist who blasted through a red light at an intersection, then a woman who, on her phone, dressed all in black at night, stepped directly in front of me in 30mph traffic, half a double-length block from the nearest crosswalk or stoplight.

If I had glanced at my phone, adjusted the radio, talked to a passenger or otherwise had less-than-instant reflexes in either of those moments those people might well be dead, or else severely injured. (Also, I and others could've been injured or worse if I'd swerved into another car).

If we had a time machine and brought an ordinary American from the 1950's to the present, or asked ~40% of Americans nowadays, chances are they'd be horrified by what they'd see as the legalized murder of tens of millions of children (abortion). I'm not trying to bring politics into this (I'm strongly pro-choice), just pointing out that the definitions of "crime," "violent" and even "child" are highly subjective.

In any society I can think of which left a substantial enough written and/or archaeological record, it's clear that people were particularly affectionate towards and protective of children, which is the only way it could be since our brains and emotional/hormonal responses are literally wired that way.

That's in turn because those instincts are necessary for the continuation of the species. Objectively, it takes well over a decade of near-constant, stressful labor before a child provides net-positive economic utility, which, at historical life expectancies (early 40's), would usually be after one parent's and shortly before the other's death. So if we weren't hard-wired to want to care for and protect children, babies would be left to die of exposure and we'd die out after one generation.

That's a separate issue from what you were (or seemed to be) saying in the post I responded to, that in the past criminal gang members would be considered more sympathetic victims than children.

I don't believe there has ever been a society anywhere or at any time where violent crime between rival criminal gangs (of adult males) was considered morally worse than violent crime where adults harm children, in both cases assuming no third parties were harmed, and there were no differences in social rank, blood or marriage relations, blood feuds, religious reasons etc. which that society and its laws considered wholly or partially mitigating factors.

Three possible explanations for the low fatality rate:

- Bars, nightclubs and stores that sell alcohol must close by 2 AM, plus our other state and local alcohol sales regulations (particularly on hard liquor) are among the most restrictive of any state.

- The additional fatalities caused by the relatively high number of bad drivers are more than offset by forcing the silent majority of good drivers (and pedestrians) to maintain concentration and alertness.

- Many elderly drivers move to warmer states, and the ones who stay tend to be in better health than the ones who leave.

Edit: A fourth possible factor is that we're one of the most affluent states and cars succumb to corrosion faster than average due to the long, harsh winters (off the top of my head, I can't think of any state that's both more affluent and has longer winters), so cars are newer (therefore, safer) than average.

When has this ever not been true? People instinctively (and reasonably[1]) consider crimes to be more serious where the victim is more sympathetic or vulnerable, and vice-versa.

[1] Though they might be unreasonable in their sympathies and/or assessments of vulnerability, like a misogynist who always assumes female accusers are liars, and claims a woman punching a man is as serious as the reverse.

Or, the identity of the victim might engender unreasonable, emotional reactions: a jury might vote to convict despite the prosecution not proving the case, or the evidence pointing to a tragic accident, because the victim was a child.

https://godbolt.org/g/MPs43x

For example, omega-3 fish oil became one of the most popular supplements since a 1970's Danish study showing it helped prevent heart attacks ... among the Inuit, whom it turns out are the only group that produce the enzymes needed to metabolize fish oil.[1]

That said this is far from the first or only study showing health benefits to vitamin D supplementation.

[1] https://www.nytimes.com/2015/09/22/science/inuit-study-adds-...

[1] https://upload.wikimedia.org/wikipedia/commons/thumb/7/72/NY...

Criminals skew young and overwhelmingly male.[1]

>Do we have numbers that show a higher population of males in the US than in Canada over that time period?

It appears the baby boom was about the same size or slightly larger in Canada than the US.[2] As you can see from my first post, there also was an increase in crime in Canada during the same time period as in the US, but not as pronounced.

Unlike Corn, who is claiming that leaded gasoline is the primary cause of crime, such that it explains the entire or nearly the entire late 20th-century rise and fall in the US crime rate, I am making the much more conservative claim that the ratio of young men in a population is a cause of crime.

Indeed, as I said, the Baby Boom was not large enough for it to have been the primary cause of the US crime wave. (Although it might be sufficient to explain the relatively-smaller Canadian crime wave over the same period).

[1] https://i.imgur.com/2WscI1P.jpg — The chart understates the correlation between youth and crime, because prisoners might be serving multi-year sentences, they may have got away with other crimes prior to those they're serving time for, and first-time offenders are more likely to receive a shorter or no prison sentence than recidivists are.

[2] https://imgur.com/a/NFLfm

The "lead-crime hypothesis" is a very obvious example of correlation not implying causation.

For example, rock music causes crime. Rock music grew in popularity in the late 50's and early 60's, peaked between the late 60's and early 90's, and declined thereafter. Just like crime! In fact, the harder they rocked the worse the crime rate got. I guess Tipper Gore was right all along. Rock music causes crime.

Margarine causes crime. Johnny Carson causes crime. The Boston Celtics cause crime. The Japanese economy, big hair, VHF television, polyester, yearly Oldsmobile sales: all cause crime.

During the period leaded gasoline was sold, Canada allowed 0.77 grams of lead per liter of gasoline, nearly three times the US limit of 0.29 g/l.[2] Yet the crime rate in Canada was (and continues to be) far lower than in the US.[3]

In Mexico, leaded gas remained commonplace much later than it did in the US, and yet crime fell dramatically during the period leaded gas was sold, and increased dramatically after it stopped being sold.[4]

One thing we could look at is people who had the highest lead exposure. Lead miners, paint factory workers, house painters, fuel refinery workers, gas station attendants, auto mechanics, etc. I would confidently bet the farm that, adjusting for sex and income, there was no statistically-significant correlation between these professions and crime.

Aviation gasoline, as used in small propeller planes, still contains lead. We could also look at present-day flight instructors, airplane mechanics and people who live near general aviation airports. I would likewise expect there to be no relationship.

Here's something that's known to cause crime: young men. The Baby Boomers were the largest generation ever, which means between the late 60's (oldest Boomers entering their late teens) and early 90's (youngest Boomers entering their 30's), there was a particularly large population of young men. This doesn't explain the entire rise and decline in crime (the Boomers weren't that much larger than other generations), but it's a better starting place than lead paint.

[1] https://news.ycombinator.com/item?id=16025762

[2] http://www.columbia.edu/itc/sipa/envp/louchouarn/courses/env...

[3] https://ourworldindata.org/wp-content/uploads/2013/03/homici...

[4] http://www.slate.com/content/dam/slate/articles/news_and_pol...

The Sahara desert is extremely sandy, and extremely windy, which makes it a pretty terrible, or at least prohibitively-expensive place to build a solar farm.

It is also extremely complicated and extremely expensive to transmit large amounts of power over long distances, particularly across national borders (everyone's on a different AC standard), particularly across many national borders.

The analogue with software development, I'd say, is when people periodically point out that nuclear power plant or ICBM control systems still run on 8-inch floppy disks!!1! and therefore allegedly need to be completely rewritten. That rationale likewise fails to meet my tempting fate threshold.

[1] https://en.wikipedia.org/wiki/2001_anthrax_attacks

I believe this is incorrect and small-vector optimization is in fact disallowed by the C++ standard. In any case, standard or not, no implementation is ever going to do SVO because it would require a branch on every access, making them incompatible with SIMD instructions.

>Rust also has a concept of zero sized types, which C++ does not

No, C++ allows this optimization too, it just requires that the "sizeof" operator always returns an integer >= 1.

>the class of high-level dynamic languages that were on the rise in the mid-00s (Python, Ruby) lost a lot of steam to newcomers like Swift and Go due to the language designers' hesitation around embracing parallelism.

Quite the opposite, Python has a dominant and rapidly-growing market share (as the developer-facing API wrapping Fortran/C/C++ libraries) in CPU-bound, massively-parallel applications (NumPy, Tensorflow, etc).

Swift and Go are odd examples to make your point: Swift's support even for concurrency[1] is a low-level and unergonomic Objective-C library, and for parallelism (or implementing other concurrency primitives) an even lower-level and less ergonomic paper-thin Objective-C wrapper around pthreads.[2] That's still better than Swift on Linux, where the only option for either is plain pthreads.

Go has excellent concurrency support (with goroutines, aka fibers, aka green threads, which execute one-at-a-time on a single CPU core and from within a single actual OS thread), but for multi-core parallelism its standard library also offers nothing more than a paper-thin wrapper around pthreads.[3]

Even C++11 offers a substantially higher-level and more ergonomic parallel-threading API than either Swift or Go.[4] Among recent, relatively mainstream, general-purpose languages, the examples that come to my mind as exemplifying strong parallelism support are Rust, Julia and recent versions of Java (Streams) and C# (TPL, PLINQ).

[1] https://developer.apple.com/documentation/dispatch

[2] https://developer.apple.com/documentation/foundation/thread

[3] https://golang.org/pkg/sync

[4] http://en.cppreference.com/w/cpp/thread

The advantage of multithreading in a web application is not "using all cores" but rather that the application can spawn a thread to "asynchronously" wait for a response from the network or database while it continues doing other work in the main execution thread, instead of "synchronously" blocking all work while it waits.

In other words, web applications leverage concurrency with their use of multithreading, not parallelism.

I will caveat that having more cores can give concurrent applications a small performance improvement, because even though each thread is only using a CPU core at around 0 to 15% (in short bursts) of capacity, switching between two threads on the same core is a context switch, a fairly expensive operation. More cores means fewer context switches.

But, unlike with parallelism, making use of more cores is not the reason concurrency offers performance benefits. ~99% of the performance benefit of concurrency is realized on even a single-core machine, whereas parallelism by definition requires multiple cores to offer a speedup. Concurrent applications such as web servers (e.g. Apache, Nginx) typically spawn hundreds or even thousands of threads per CPU core.

Which is a bit unfortunate, because (APL-like) array languages, of which Q appears to be one of the more approachable/popular, have a lot of very interesting ideas that I think mainstream languages could benefit from. Their unpopularity is self-inflicted due to the wacky syntax, of course.

Software version schemes are often started at 0, or other times 1, so why not any other integer? I don't expect software version numbers to mean anything except that higher is (probably) chronologically later. That said I would probably still start numbering internal/beta versions at 1 or 0 and use 2 for the first release.

It's not even in the same league of dishonesty as ubiquitous practices by blue-chip tech companies such as using trial pricing in advertisements, selling "new versions" of software with only trivial changes, selling "extended warranties" on hardware that don't cover the most common causes of breakage, or claiming customers have access to "expertise" developing intelligent zero-downtime SaaS solutions on the blockchain with the deep learning algorithms powering our global AR/VR-enabled IoT cloud.

[1] amplitude

[2] amplitude * frequency

[3] frequency

Of the "bad Larry Ellison" anecdotes ITT, most of which do paint him in a very bad light, this one doesn't offend me at all; more like smart marketing advice you can use.

In C++'s defense it's not like the language or the compilers encourage you to use shared_ptr, but it's also true (mainly for legacy C-interop cruft) it doesn't do enough to nudge you to write code in a proper RAII style, nor to enforce correctness WRT ownership.

I like that Rust forces you to explicitly opt out of RAII and/or single-owner semantics. (Those are the "defaults" in C++ too, but too easy to implicitly or accidentally opt out of). On the other hand you can write Java in any language, and from the little Rust I've read, newcomers from managed langs will often daisy-chain enough smart pointers in a row to put any 13-year-old who just downloaded Unreal Engine to shame.

The last time I took a serious look at Rust I thought it took things too far in the other direction; you weren't able to use two (nonoverlapping!) data members of the same struct in a function, and the suggested workaround was to wrap it in a smart pointer. Has that issue been fixed now?

See my reply to kllrnohj above: https://news.ycombinator.com/item?id=15872509

>Why not [write sink functions that] take by value?

That could work in the case where the parameter is a class which is movable but not copyable, but I'd still prefer an rvalue reference in that case because it makes your meaning obvious without having to refer to the class definition or documentation.

Sometimes, but not in this case, because

- Smart pointers are nullable, which should be opt-in and not opt-out behavior.

- Smart pointers have pointer-like interfaces, which do not read like idiomatic modern C++. A wrapper class `GadgetHandle` can define conversion operators for `Gadget&` and `const Gadget&` so their interface reflects their semantic meaning (a `Gadget`) and hides irrelevant or unsafe implementation details (the operators and methods belonging to the smart pointer class).

- As a corollary to the above, you can create several classes `UniqueGadgetHandle`, `SharedGadgetHandle`, `CustomGadgetHandle` and so forth, which enable you to very easily and transparently intermix or alter allocation strategies (even on the stack or statically) for your `Gadget`s, usually without needing to alter any public APIs or more than one section of your codebase.

- When your heap-allocated data [structures] don't semantically correspond to the containers provided by the STL or your other library dependencies, I find that chances are you have or may add some custom constructor/destructor logic beyond just new and delete.

I'm not against smart pointers where they make sense, it's just whenever I see them I start bracing myself for the horrors that seem to inevitably follow.

[0] Whether a resource is allocated on the heap or elsewhere, or, whether a heap-allocated resource has owned or reference-counted semantics, are implementation details that should be abstracted away from your top-level APIs, so you have the flexibility to change them later.