I wonder why you lost or never had any faith in static analysis. On Apple's platforms it's becoming a really big "thing". Also John Carmack talked about the benefits of static code analysis at QuakeCon 2012.

Also a good read: http://www.altdevblogaday.com/2011/12/24/static-code-analysi...

It's a huge big deal in enterprise software security; lots of Fortune 500 firms deploy it (most of them use Fortify, not Coverity).

I'm not a fan either.

I'm a big +1 for static code analysis as a "silent observer" of code practices. We have various static checks run on each build and if a certain threshold is crossed, the build will kick out an error (we've decided not to have it fail entirely, although some could argue that's a reasonable thing to do).

Although we're a Ruby and JS shop, we take advantage of different services and libraries that perform different checks. In dynamic-language land it's a lot harder to do some of the things that static complication provides, but it's a heck of a lot better than nothing!

I hated every attempt at static analysis until I started programming with Xcode. In my usage, Build and Analyze is always right -- that's the difference. Other tools (lint, FXCop) are too noisy. Even warnings in some compilers are an annoyance that you have to code around to eliminate.

Fxcop is massively overused. The rules are designed for teams who are building libraries and frameworks (thus the name, Fx is short for framework). For ordinary app development many of the rules are inappropriate, which can lead to an impedance mismatch and frustration.

Yeah, I read that Objective-C got it's ARC feature after static analyzer was integrated to Xcode. No more manual reference counting is definitely a plus.

Why would you not have much faith in static analysis? Have you changed your mind on this?

I am a firm believer that the best way to fix programming is through better programming languages, which I learned about myself while working at Coverity. Otherwise I think it was a great place to work: lots of very smart people, a very good business plan, great startup stock (back then), but I'm too idealistic!

Static analysis tools are very pragmatic in a world where better languages aren't adopted very often.

Do you think better languages will make static analysis useless? I would think the combination to be better than better languages alone. Or are you arguing that static analysis by compilers should be improved (1) so far that separate tools for static analysis aren't useful anymore?

(1) almost all compiled language systems do _some_ static analysis. For example, many compilers and linkers do dead code elimination, and Java and C# must, by spec, do static analyisis to prove that variables won't be used before set.

Static analysis is about performing heuristical non-local analysis on a code base to find bugs. We aren't talking about modular type checking that is performed by the compiler and explicitly enabled by the programming language design.

If you eliminate potential bugs to be found, static analysis is devalued significantly. So while static analysis may seem necessary for C++ code (very buggy, not much safety), it has less value for Java or C# code, where the easy-to-detect bugs and the remaining bugs are much more difficult to find.

Really depends on the type of code you are writing. If you're writing a Mars Rover, you're probably not using a single dynamic feature and static analysis works quite well in this case. So long as you're writing 'dead' software, you're better off with static analysis.

As soon as you try to write living software, that is, software able to evolve over time without restarting, static analysis goes out the window. Design by contract and test suites are your friends in this case.

Ok, that explains your position in a way that makes good sense to me. I agree that better programming languages would be good (and in fact, we do have them) but I'm a pretty pragmatic person and any tool that helps me to do the job that I need to do better is welcome.

Until better languages are much more common static analysis can save you a lot of time tracking down obscure issues and for that alone it gets my vote. I'll be more than happy to ditch all that for a better way to develop software (not necessarily just better languages) it feels as if we're doing something terribly wrong but I can't quite put my finger on what it is.

It feels as if we're building fragility right into the process from the ground up when in fact we should be doing the opposite.

Right. I should have replaced "faith" with "excitement."

If you program in C++, you need static analysis. I'm not so sold on it for Java or C#, their is a lot less low hanging fruit in a moderately modern statically typed language.

java and C# still allow casting, so I think there you will still want static analysis outside of existing language features.

Yes, and they have null pointers also, but such bugs aren't as horrible as they are in c++, they show up more quickly during tests and are easier to debug.

C++ remains the market maker for the static analysis industry.

I've been 'around' static analysis a decent amount in the past 10 months or so, and my conclusion is that the deep solution is ML/Haskell/etc, not static analysis.

Writing in C/C++ is like asking to be shot in your foot. So you get static analysis, which gives you a modicum of help.

static analysis is always going to result in a deluge of false positives

i think the future is symbolic execution, which due to a lot of factors is becoming practical

symbolic execution is very similar to static analysis in purpose, if not name (closer to verification). You are right about the false positive rate, but I don't see why you think its becoming more practical?

what do you think about klee.llvm.org?

Looks like your career is a string of bad bets..

(joking)

Quite true. I'm sure it would have worked out well financially if I hanged around in San Francisco (probably working for Coverity) rather than go to Lausanne to do a postdoc.

But then I wouldn't have had a job. :) Good to see your name again Sean.