Stagefrightening

Posted Jul 30, 2015 18:34 UTC (Thu) by ms (subscriber, #41272)
In reply to: Stagefrightening by jhoblitt
Parent article: Stagefrightening

Why is that a poor story? Tools are awkward and tricky to use until they get regular use and get polished by that. Remember how awful the first editors were?
The tools will get better once they are mandated for any code that is ever fed untrusted inputs. I'd rather have fewer features and slower code but code that is flawless than a billion insecure and badly implemented features. Slowly, more people may come to agree with this.

Stagefrightening

Posted Jul 31, 2015 7:56 UTC (Fri) by NAR (subscriber, #1313) [Link] (1 responses)

The problem is that static analyzers don't make the code flawless. I remember a "sales pitch" for an Erlang product, they said that practically all of the reported bugs were the kind of "software did what the developer wanted to do, not what the user wanted to do". Static analyzers may decrease the number of some kind of bugs, but definitely not eliminate all bugs. So the choice is between "slower development, less features, (hopefully) less bugs" and "faster development, more features, (probably) more bugs".

Stagefrightening

Posted Aug 3, 2015 7:51 UTC (Mon) by jezuch (subscriber, #52988) [Link]

My experience with static analyzers is that they protect you from silly mistakes. Like using instanceof on a variable that can never refer to an object of this type. Or that this field is accessed from these methods but is inconsistently synchronized. Which is great but kind of underwhelming. I don't think I've seen anything that would detect serious architectural problems.