2 ms·
To me it seems the only way to smarter tools is static analysis, but there's only so much one can do in a dynamic language. There seems to be this dissonance b
by platz 12y ago
To me it seems the only way to smarter tools is static analysis, but there's only so much one can do in a dynamic language.
There seems to be this dissonance between dynamic languages, which tend to be popular with new programmers for a variety of reasons, and better tools enabled by static analysis of (usually) static langues.
The static languages seem to present this "hump" that a lot of people are averse to, and if we really want these smarter tools, we're going to have to find a way to get programmers to use more static techniques; we need to get them over that "hump", possibly then these smarter tools would ease things in the long run, but doesn't have quite the same immediate-gratification aspect of dynamic languages due to the up-front effort.
- raverbashing 12y agoYou can do a lot of static analysis of dynamic languages. Check what PyLint/PyFlakes does for example It's probably not the dynamic language that is the problem, but its constructs.
- seanmcdirmid 12y agoThere is also so much one can do with a static language. Dynamic languages are preferred by those who don't want the conservative verbose static type system to get in the way of writing code. You can design a static type system that is less verbose (e.g. via more inference), but then it can become more conservative (H&M's inability to deal very well with semi-unification in the form of subtyping and assignment). That is the "hump." Smarter "more magical" compilers are a nice idea in theory, but hard to realize in practice. There are even limits to the kind of analysis we can do dynamically, but they are a bit less constrained then what we can do statically.