11 ms·

I think the point is that programs written in a dynamically typed language aren't that dynamic most of the time. With static analysis, you're able to get at lea

I think the point is that programs written in a dynamically typed language aren't that dynamic most of the time. With static analysis, you're able to get at least some benefit from autocomplete and automatic refactoring. The parts of the code where it doesn't work - well, the developer has made the tradeoff that it's worth it there. Sometimes I wonder why there aren't more 'empirically' typed languages, i.e., you write a function and some unit tests that exercise it and from that the compiler can determine what are the actual types and values the function sees for every variable.

taeric 9y ago
That is mostly the point, yes. And I'll note that autocomplete is already challenged in a functional style, since you aren't always dispatching to methods of an object. As an easy example, if you are looking for functions that can return a Foo, autocomplete does little to help you know that you have to call .convertToFoo() on any of the baz instances in scope. There is already more than just basic type mapping going on. (To that end, a graph traversal assuming shortest path from symbols in scope to the desired shape works. So it is doable, of course.) To your question of "empirically typed", that is close to some of the stuff that more advanced tools can do. I liked showing folks that Coverity wouldn't just tell you that you forgot to check for null, but would show you how the null would get there from the call patterns. Quite impressive.