"Farrel Lifson" <farrel.lifson / gmail.com> wrote in message 
news:c2c0b660608220540y3cf55b18v18c5879ce4ea55a9 / mail.gmail.com...
> On 22/08/06, Just Another Victim of the Ambient Morality
> <ihatespam / rogers.com> wrote:
>>     I was debugging someone else's code the other day (it was htmltools,
>> actually) and I was in the middle of some function trying to figure out
>> what it does.  That's when I noticed that I had no clue what the passed 
>> in
>> parameter was.  I mean, I can see how it was used but it really didn't
>> reveal what it was.  In fact, it could have been anything.  I could have
>> tried to do a search to see when this method was called and try to
>> investigate what was passed in at each instance but that would not
>> necessarily be revealing since the object may not have been created in
>> those methods and, instead, passed into them.
>>     The problem is that dynamic typing, while very powerful, also hid 
>> the
>> intent of the method.  Obviously, any object that satisfied whatever the
>> method was trying to do will suffice as a parameter, and that would be 
>> the
>> point of duck typing, there was obviously some concrete example of some
>> type the method was expecting.  It would really have helped to let me 
>> know
>> what that was...
>>     Now, the answer to this is simply better documentation.  Write a 
>> damn
>> comment that says what the method is expecting and, hell, while you're 
>> at
>> it, you could mention what the method does, too.  However and
>> unfortunately, I've been a professional programmer way too long to 
>> expect
>> code to come with good documentation.  Out here, in the real world, 
>> you're
>> lucky if the code works...
>>     Has anyone noticed this?  How do you deal with this issue?
>>     Thank you...
>
> In my experience the way to handle this is to have parameters and
> variables with logical, consistent names. If I'm debugging a function
> 'foo(i)' it's almost impossible to know what  is. If the function
> instead was defined as 'foo(categoryName)' it's a lot easier to deduct
> that it's a (string or an object that should be able to ducktyped to a
> string).

    ...but this is often not enough.  What if the parameter is called 
"node."  In context, how can this be better?  "parse_node?" 
"html_parse_node?"  What's in this "html_parse_node?"  Is it lazy parsing 
or did it do the processing as it parsed and the node contains the parsed, 
processed data?  How would I know this?  I can't look up any of the objects 
that will be passed in because any object can be passed in; this language 
is dynamically typed!  I could look for a "class Node" in the hopes that 
that is the name of one of the object classes passed in but who knows?  It 
could be called anything and there's no way for me to know what that 
anything is!
    If the language were statically typed, I would know straight away what 
type the parameter was and can look up, exactly, what it does and can 
probably easily discern what it's role is.

    Now, don't misunderstand me, I'm not advocating turning Ruby into a 
statically typed language.  I enjoy that Ruby has no "templates" (in the 
C++ sense) because every method is "templatized!"  The mere fact that C++ 
has templates is testimony to the power of dynamic typing.  I'm just saying 
that static typing "ain't so bad," in that this is one problem I would not 
have had were I working with a statically typed language.  I'm also looking 
for how people deal with this issue, since it surely must come up from time 
to time...