Comments on: Pipe Dream: Static Analysis for Ruby

By: anonymous

anonymous — Fri, 10 Sep 2010 00:50:25 +0000

That’s called Soft Typing (Static typing + Type inference + allowing indeterminable types to be checked at runtime).

By: Matisse Enzer

Matisse Enzer — Sun, 11 Jul 2010 04:18:01 +0000

You probably already know this but the Perl community scoffed at the idea of a static code analyzer for Perl, that is, until Adam Kennedy produced PPI (http://search.cpan.org/dist/PPI/) which led to the creation of Perl::Critic (http://search.cpan.org/dist/Perl-Critic/ or http://perlcritic.com/)

So, there is hope for doing something like this in Ruby.

By: Ned Konz

Ned Konz — Thu, 02 Jul 2009 14:35:52 +0000

Actually, this kind of type inference can be taken pretty far. Look at Traits (for Squeak), (http://doi.acm.org/10.1145/1119479.1119483) which is a simple system that does just the kind of analysis you’re talking about (and allows automatic refactoring based on this analysis, or Moose http://moose.unibe.ch/ which is an ambitious system that does many kinds of analysis on software.

By: Daniel Spiewak

Daniel Spiewak — Mon, 30 Jun 2008 19:56:18 +0000

coderrr is right, there’s a fairly hard limit on what is possible with pure runtime analysis. Ruby’s highly dynamic nature actually makes this easier than it would otherwise be (subbing in a new implementation of Object.new, for example), but there’s really no way around the issue of side-effects. It is for this reason that I think that some sort of static analysis is really the only way to improve on the situation, due to the fact that static analysis doesn’t have the concern associated with external side-effects. The obvious problem being that you can’t really guarantee much about the code. ActiveRecord is a good example of a library which relies upon external conditions (a database) to define what object structure is going to look like. Clever, but very frustrating from the perspective of stability assurance.

By: coderrr

coderrr — Mon, 30 Jun 2008 17:07:34 +0000

@matthew: I’ve thought about runtime analysis before a little, by no means thoroughly. But the problem is that you have no idea what code is safe to run. The analysis may exercise some code which deletes a whole directory of files. For example you may think you’re just resolving a class and enumerating its methods. But when that class is resolved maybe it makes a connection to a database and resets some state somewhere. Seems like dangerous and unpredictable stuff to do especially when you’re dealing with 3rd party libs.

Maybe some sort of guided analyzer would work where you show it safe paths or maybe just dangerous paths to exclude from the analysis. This would still be work for the developer but could be easier than writing tests.

It would be nice to see more attempts in this area forsure.

By: matthew

matthew — Mon, 30 Jun 2008 16:21:42 +0000

Even in the case of Eclipse’s Java support, there are certain situations that only indicate you might be making a mistake, like when you use an enum in a switch block but don’t use all values, or a missing serialVersionUID. A method call that falls down into method_missing is maybe a similar situation.

I’m thinking that runtime analysis might be the way to go though, especially in Ruby where you can attach methods to instances and classes at will. Resolving the ordering of these things seems too tough at a purely source code level, but at runtime you can verify which methods are available on an instance. Then maybe you could use the data from that analysis and insert it back into the source code viewer, kind of like some code coverage tools do.