I just got done reading Steve Yegge’s “Dyanmic Languages Strike Back”. He notes that one of the perceived problems with dynamic languages is the lack of tools, (he notes specifically the autocomplete feature).
While the thought of type declarations or any sort of annotations makes me cringe, is there any useful type data that could be recorded while running the unit tests that could later be used for the autocompletion of methods from within your Favorite Editor (I
While this may be cheating by deriving types at runtime, it certainly seems simpler than the probabilistic methods Steve outlines for determing types in dynamic languages. And it would certainly encourage the act of writing tests if you could get the added productivity boost of autocomplete.
May 13th, 2008 at 7:26 am
Yeah I’ve thought about this approach before - I wrote some code to instrument execution of unit tests before to record method argument type information.
The point in my case was to augment a simplistic ruby type inferencer, in order to have a pretty good idea AOT, what the argument types are likely to be for a function, to compile type-specialized alternatives. This means you can still generic algos, but if you call it predominantly with plain ints, it will take a fast path as if it were written in C…
May 30th, 2010 at 6:47 pm
This means you can still generic algos, but if you call it predominantly with plain ints, it will take a fast path as if it were written in C…