Isaac Gouy wrote:
> Another mechanism - IDE support.
> 
> The most basic Smalltalk code exploration builds on tools for browsing
> implementors/senders of methods. We'd browse all implementors of "parse
> data, machine" to see if we were dealing with a massively polymorphic
> method, and then we'd browse all senders of "parse data, machine" and
> keep tracing back to see what sort of things "data.index 0" was being
> initialized with.
> 

Type information being part of the method signatures usually helps 
narrow this down. I sort of get where HorkingLongAndObnoxiousName is 
coming from - "parse" is a very generic method name and might be found 
around the system with even the same arity for wildly varying purposes. 
Without as much as receiver type information, the code search could show 
a lot of unrelated results.

Hopefully, you could further narrow them down by making assumptions 
based on identifier names, but that's a) error-prone, and b) better not 
to have to do by hand.

Making sophisticated tool support is much easier if the tools have much 
more information at their disposal, and statically typed code does 
provide more / easier machine-analysable information.

Dynamic typing is inherently more prone to being hard to maintain. The 
problems can be very well mitigated using proper conventions, and common 
sense.

But that's not always the case, and when you get thrown on a project as 
a maintainer or to contribute feature XY into revision Z of a codebase 
that had random people without a code style guide leading them working 
on it for two years, you get very, very happy that you have Ctrl-Shift-G 
in Eclipse on your side. In a rainy day scenario, the systems aren't 
quite equivalent.

David Vallner