iPhone 5 user here with iOS 10.1.1 . I haven't noticed the issue, just the understandable decay of my 4 year-old battery that lasts less than it used to be.
AI is the biggest hype of the moment.
It reminds me the film "Eagle Eye" (2008) where a kind of of Zeroth-law empowered AI wants to assassinate the president of the US. Despite its incredibly intelligence what I found more unrealistic was its control of all internet-connected systems in the US (traffic, remote control drones, phones, different OS, etc) "just because I am an AI and I can do whatever I want"
For god's shake, it is 2016, we are still unable to have a decent dependency system for most programming languages. AI is still decades far to rise up against us.
I sometimes give a talk to startup companies, in which I tell them why their code should be horrible. It's an intentionally provocative thing to say, but there is reasoning behind it, and some of the same reasoning applies to a lot of scientific code. The linked article has a few comments that tangentially touch on my reasoning, but none that really spell it out. So here goes...
Software development is about building software. Software engineering is about building software with respect to cost. Different solutions can be more or less expensive, and it's the engineer's job to figure out which solution is the least expensive for the given situation. The situation includes many things: available materials and tools, available personnel and deadlines, the nature and details of the problem, etc. But the situation also includes the anticipated duration of the solution. In other words, how long will this particular solution be solving this particular problem? This is called the "expected service lifetime".
Generally speaking, with relatively long expected service lifetimes for software, best practices are more important, because the expected number of times a given segment of code will be modified increases. Putting effort into maintainability has a positive ROI. On the other hand, with relatively short expected service lifetimes for software, functionality trumps best practices, because existing code will be revisited less frequently.
Think of the extremes. Consider a program that will be run only once before being discarded. Would we care more that it has no violations, or would we care more that it has no defects? (Hint: defects.) That concern flips at some point for long-lived software projects. Each bug becomes less of a priority; yes, each one has a cost (weighted by frequency and effect), but a code segment with poor maintainability is more costly over the long term, since that code is responsible for the cumulative costs due to all potential bugs (weighted by probability) that will be introduced over the lifetime of the project due to that poor code.
So, short expected service lifetimes for software, prioritize correct behavior over maintainability; long expected service lifetimes for software, prioritize maintainability over correct behavior. The source code written by a brand-new company will be around for six months (maybe) before it gets factored away, or torn out and rewritten. During that time, less-experienced coders will be getting to know new technologies with foreign best practices, and those best practices will be violated frequently but unknowingly. Attempting to learn and retroactively apply best practices for code that will likely last a short period of time is simply more expensive (on average) than just making things work. The same applies to scientific code, which gets run for a graduate degree or two before being discarded. If the code wasn't horrible, I'd think that effort was being expended in the wrong places.
In my experience, most "fights" about best practices (whether a technique should be considered a best practice, or whether a best practice should be applied) usually boil down to people who have different expected service lifetimes in mind. (One of those people is probably considering an expected service lifetime of infinity.)
I sometimes give a talk to startup companies, in which I tell them why their code should be horrible. It's an intentionally provocative thing to say, but there is reasoning behind it, and some of the same reasoning applies to a lot of scientific code. The linked article has a few comments that tangentially touch on my reasoning, but none that really spell it out. So here goes...
Software development is about building software. Software engineering is about building software with respect to cost. Different solutions can be more or less expensive, and it's the engineer's job to figure out which solution is the least expensive for the given situation. The situation includes many things: available materials and tools, available personnel and deadlines, the nature and details of the problem, etc. But the situation also includes the anticipated duration of the solution. In other words, how long will this particular solution be solving this particular problem? This is called the "expected service lifetime".
Generally speaking, with relatively long expected service lifetimes for software, best practices are more important, because the expected number of times a given segment of code will be modified increases. Putting effort into maintainability has a positive ROI. On the other hand, with relatively short expected service lifetimes for software, functionality trumps best practices, because existing code will be revisited less frequently.
Think of the extremes. Consider a program that will be run only once before being discarded. Would we care more that it has no violations, or would we care more that it has no defects? (Hint: defects.) That concern flips at some point for long-lived software projects. Each bug becomes less of a priority; yes, each one has a cost (weighted by frequency and effect), but a code segment with poor maintainability is more costly over the long term, since that code is responsible for the cumulative costs due to all potential bugs (weighted by probability) that will be introduced over the lifetime of the project due to that poor code.
So, short expected service lifetimes for software, prioritize correct behavior over maintainability; long expected service lifetimes for software, prioritize maintainability over correct behavior. The source code written by a brand-new company will be around for six months (maybe) before it gets factored away, or torn out and rewritten. During that time, less-experienced coders will be getting to know new technologies with foreign best practices, and those best practices will be violated frequently but unknowingly. Attempting to learn and retroactively apply best practices for code that will likely last a short period of time is simply more expensive (on average) than just making things work. The same applies to scientific code, which gets run for a graduate degree or two before being discarded. If the code wasn't horrible, I'd think that effort was being expended in the wrong places.
In my experience, most "fights" about best practices (whether a technique should be considered a best practice, or whether a best practice should be applied) usually boil down to people who have different expected service lifetimes in mind. (One of those people is probably considering an expected service lifetime of infinity.)
The story is more complex than the article says. A Spanish forum (one of the top-40 more visited sites in Spain) voted massively the name "Blas de Lezo" https://en.wikipedia.org/wiki/Blas_de_Lezo ) a Spanish admiral who in 1741 defeated a British Army far bigger than his own one.
After gaining the #1 position the organization decided to withdraw the name from the polling, causing more controversy about this digital process.
Excellent article, it explains pretty much the same (but with much more mathematical detail) as the article I wrote some months ago about why parser generator tools are mostly useless [1] .
I find this article really interesting. I am a native speaker of Spanish and the verb 'to be' is usually one of the first lessons we learn when we study English.
Spanish has to different verbs to depict the meaning(s) of 'to be' -> ser (exist) and estar (stay). I always thought merging those meanings into a single verb did not help to express the richness of the English language.
I am saying "Developers do not want :
1 - Pay A LOT of money for advanced solutions that are more than AST checkers (hello SonarQube) or big piles of false positives.
2 - Add overhead to their workflows (more than an IDE plugin is harmful, and what happens with those devs not using an IDE?).
3 - Spend time on figuring out if the static analysis results make sense or not, one by one.
A typical SCA tool can report hundreds or thousands of occurrences for a certain code base. How are developers going to deal with them?
I think the reason is fairly simple: even the most evident-no-doubt clear SQL Injection vulnerability found by a SCA tool may never be exploited at all under production (for instance because of a WAF). Then the obvious benefits of static analysis are not that obvious for your employer.
Sometimes we forget companies do not want a perfect code or the best possible well designed software but a product that make them earn money.
My experience is that developers only use those kind of tools if they are forced to by their QA managers of bounded by contract. Programmers usually don't want to fix or track bugs.
Based on my interest in this field I am willing to pay around $5 for the book. However I agree that it is not a fair price. What should I do? Note that it is not a matter of money. I could afford the suggested price or even more but I am not that interested in the topic.
Downloading for free is not morally acceptable for me, I would like to support this business plan.
It is really interesting. You pointed that the static analysis tools are aimed at developers but even the guys from PVS-Studio admit their main customers are big companies with teams of developers and I agree. From my experience such companies "force" their developers to use these kind of tools. It is somehow paradoxical that such tools are so technical only developers understand their results but only managers want (or think they want) to consume them.