For various reasons, it was decided that all engineering students had to learn mobile app development in their first year of the degree. Every single person in the faculty who had any experience with Android told them it was a terrible idea.
Your guy is disliked by a far bigger proportion of the population than the proportion that like him. He is disliked far more than Hillary Clinton, according to the polls.
Your guy has little acquaintance with facts in his public rhetoric, but that doesn't make them go away. Trump will lose the general election to Hillary. The remaining question is whether his negative impact on the Republican vote will cost the GOP the House and Senate as well.
Scratch largely removes the barrier of remembering syntax and dealing with syntax errors. This gets people who might have otherwise been put off over a significant hump.
However, there are two other barriers to becoming an effective programmer that Scratch doesn't help with at all.
Scratch doesn't help one iota with any of the above.
My interest is prompted because I plan to do some testing related research that requires building the code many times. My working assumption was that systems are fast enough these days that you could build pretty much anything in a short reasonable amount of time by throwing a big enough set of compute nodes at the problem. Worth knowing that isn't always the case.
In 2012, there were 0.55 deaths per 100 million road vehicle kilometres travelled. For business and private flying in GA aircraft, (which is mostly A to B, but does include a few riskier activities such as cattle mustering) the death rate is about 40 deaths per million flying hours, and if you assume that the average speed is something like 200 km/h, that comes out to 20 deaths per 100 million aircraft kilometres travelled.
GA aviation is much riskier than driving a car, and comparable to riding a motorcycle.
Do you think you've reached the realistic limits of how much you could parallelize the build process?
This stuff has to run the gauntlet of companies, regulators, and customers who have NFI about infosec, but do have some idea of the consequences of rushing untested changes into devices which quite literally keep people alive from minute to minute.
To indulge in some gross stereotyping here, they have huge egos that exceed their (very considerable) talents, and little appreciation that anything that doesn't involve medicine, or indeed surgery, is important.
They also tend to end up running hospitals.
If you tell a surgeon running a hospital that you need to inconvenience him (and it's usually a him) and his fellow surgeons to solve a "problem with the computers", they will ignore you. They are also right - anything that interferes with their ability to do surgery is a huge waste of resources.
An infosec person implementing the "principle of least privilege" is almost certainly going to grossly inconvenience surgeons in the process, to ends that are not at all obvious to most of them. Along the way they will, at the very least, inconvenience patients. Therefore, the infosec person will get told precisely where to stick their principle of least privilege.
Longer version: 100 watts for 10 minutes in the context of an hour-long cyclocross race is enough to turn an also-ran into a winner. It would be decisive in most road races other than out-and-out bunch sprints as well.
As far as drag goes, that's negligible by all reports. Avoiding drag when a power source is not providing propulsion is a very well-studied problem.
Often statistics are used as a drunken man uses lampposts -- for support rather than illumination.