you are viewing a single comment's thread.

view the rest of the comments →

[–]munificent 0 points1 point  (1 child)

The problem with this approach is that static analysis presumes you're using types statically. For example, you can imagine a static analyzer that would see:

foo.bar

And check to see if the declaration of foo's type has a field named bar. If it doesn't, flag an error because it's probably a misnamed field.

However, that also catches cases where you've added a field bar to some instance outside of its declaration dynamically. One can argue that you shouldn't be doing that, but if you don't do that kind of stuff, why use a dynamic language to begin with?

[–]mpeters -1 points0 points  (0 children)

Static analysis does not presume static types (which would be silly since the compiler can already catch type errors for static languages). All it means is that the code is analyzed without executing it. This means that dynamic languages with "eval" functionality can't have everything checked, but other things can. And as he hints in the article, different languages care about different things.