[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Static typing ain't so bad, after all...

Just Another Victim of the Ambient Morality

8/22/2006 12:29:00 PM

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...
44 Answers

Farrel Lifson

8/22/2006 12:41:00 PM

0

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).

Farrel

Lyle Johnson

8/22/2006 12:51:00 PM

0

On 8/22/06, Just Another Victim of the Ambient Morality
<ihatespam@rogers.com> wrote:

> Has anyone noticed this? How do you deal with this issue?

Most of the time I'm able to deduce what kind of object the method is
expecting, but I agree that sometimes I have to do a lot of detective
work to find out how to use the code.

If an object is passed in to a method, and is *only* used within that
method, it's usually straightforward to just use the duck typing
assumption: I just need to pass in some object that's capable of
responding to the messages that will be sent to it in this context.

But what if the object is passed down into some other method as an
argument? Or stored in an instance variable for later use? In those
situations, I have to chase that rabbit all around the code, seeing
how it's used elsewhere, before I can know for sure what kind of
object I need to provide.

It's definitely a documentation issue, in my book. But I'm looking
forward to other responses.

dblack

8/22/2006 1:17:00 PM

0

Francis Cianfrocca

8/22/2006 1:18:00 PM

0

At the risk of sounding flip, I would give two answers. First, don't
name your methods "foo." There was a criticism upthread of
parameter-names that are nonindicative of their purpose, and that
certainly matters if your methods take more than one parameter. But
even more important (in addition to proper documentation) is to name
your methods well. Method names (ideally) should be verbs, long enough
to indicate what they do as precisely as possible, but short enough
not to offend the eye. Another problem is adding side-effects to
methods after they've been defined and named, when you're modifying
your code later on. When you do this, your method is now misnamed and
will give you less help as you (or someone else) tries to read your
code. In addition, well-named methods generally tend to be smaller,
which is a plus in the Ruby stylebook.

The second (flip) answer to your question is: "it doesn't matter."
Most of the time when duck-typing is working well, there is little
question about the right kind of argument for a method. Especially
since you're writing your documentation as you write your methods.
When there is a mismatch, your unit tests will generally emit an error
that's not hard to diagnose. There are cases when you'll tear your
hair out over a hard-to-find type error, and these cases are the heart
of the argument against dynamic typing, but in practice they are very
few indeed.

Another point of style is to write methods in anticipation that they
will be called with several different types (like Arrays or Strings,
or any of a raft of IO types) and just do the right thing in your
method.


On 8/22/06, Lyle Johnson <lyle.johnson@gmail.com> wrote:
> On 8/22/06, Just Another Victim of the Ambient Morality
> <ihatespam@rogers.com> wrote:
>
> > Has anyone noticed this? How do you deal with this issue?
>
> Most of the time I'm able to deduce what kind of object the method is
> expecting, but I agree that sometimes I have to do a lot of detective
> work to find out how to use the code.
>
> If an object is passed in to a method, and is *only* used within that
> method, it's usually straightforward to just use the duck typing
> assumption: I just need to pass in some object that's capable of
> responding to the messages that will be sent to it in this context.
>
> But what if the object is passed down into some other method as an
> argument? Or stored in an instance variable for later use? In those
> situations, I have to chase that rabbit all around the code, seeing
> how it's used elsewhere, before I can know for sure what kind of
> object I need to provide.
>
> It's definitely a documentation issue, in my book. But I'm looking
> forward to other responses.
>
>

Trans

8/22/2006 1:47:00 PM

0


Just Another Victim of the Ambient Morality 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...

Zen.

T.

William Crawford

8/22/2006 1:51:00 PM

0

Just Another Victim of the -spam trigger removed-t Morality wrote:
> The problem is that dynamic typing, while very powerful, also hid
> the
> intent of the method.

For preventing the problem, my answer is the same as everyone else's...
Good naming techniques.

For figuring them out... Unit Testing! If it doesn't already have some
tests, write some. As Francis said, you'll get some informative
messages back. It's kind of a perversion of unit testing, but I often
use it to quickly experiment with classes I don't completely understand.
Once I can make working tests for something, I usually understand it
pretty well. And I've always got them to look back at in case I forget
how I managed to make it work. (Without hunting through tons of code.)

As for static typing... I feel your pain. It's heresy, but I prefer
static typing. Inheritance provides everything I need that Duck Typing
does for me. (At least, so far. I'm really new to Ruby.)

-sigh- Victim, your name triggers the spam filter here. Am I the only
one annoyed by this?

--
Posted via http://www.ruby-....

Just Another Victim of the Ambient Morality

8/22/2006 2:20:00 PM

0


<dblack@wobblini.net> wrote in message
news:Pine.LNX.4.64.0608220913080.27742@rubypal.com...
> Hi --
>
> On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality 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?
>
> I think a good first step is to read "Programming Ruby" by Dave Thomas
> et al., especially the part where he explains in detail that type and
> class are not the same thing in Ruby.

I don't think this semantic argument has much to do with my problem...


> Also, please -- PLEASE -- read the hundreds, or perhaps thousands, of
> posts about this in the ruby-talk archives. I'm not optimistic about
> breaking the cycle; it seems we're doomed to have this thread repeated
> three or four times a year. But, I don't know, maybe one of these
> years we can stop.

I don't know what you're talking about. What is this "ruby-talk" of
which you speak? I assume that, whatever it is, it has archives...
I've been on this newsgroup for some time now and I haven't heard
anyone complain about this so either you're exaggerating the frequency of
this question or you're very impatient...


> Don't take my curmudgeonliness personally. It's just that there's
> really not much else left to say on the topic.

I don't take your "curmudgeonliness" personally, although I suspect
that there's plenty to say about this topic...

dblack

8/22/2006 2:29:00 PM

0

Just Another Victim of the Ambient Morality

8/22/2006 2:48:00 PM

0


"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...

Just Another Victim of the Ambient Morality

8/22/2006 2:57:00 PM

0


"William Crawford" <wccrawford@gmail.com> wrote in message
news:57036c1aad7647e52b065dfd52ead3aa@ruby-forum.com...
> Just Another Victim of the -spam trigger removed-t Morality wrote:
>> The problem is that dynamic typing, while very powerful, also hid
>> the
>> intent of the method.
>
> For preventing the problem, my answer is the same as everyone else's...
> Good naming techniques.
>
> For figuring them out... Unit Testing! If it doesn't already have some
> tests, write some. As Francis said, you'll get some informative
> messages back. It's kind of a perversion of unit testing, but I often
> use it to quickly experiment with classes I don't completely understand.
> Once I can make working tests for something, I usually understand it
> pretty well. And I've always got them to look back at in case I forget
> how I managed to make it work. (Without hunting through tons of code.)
>
> As for static typing... I feel your pain. It's heresy, but I prefer
> static typing. Inheritance provides everything I need that Duck Typing
> does for me. (At least, so far. I'm really new to Ruby.)
>
> -sigh- Victim, your name triggers the spam filter here. Am I the only
> one annoyed by this?

Yeah, I'm sorry about the spam filter. I've been using this name for
about a decade now and I'm a little reticent about giving up my anonymity
(although, really, now anonymous can I be after using the same name for so
long?). At least it's a fairly unique name to search for in google news.
You can see how helpful (or not) I've been during my entire usenet career!
If your spam filter was triggered, how did you come to read my post?
I'm also interested to hear if anyone else is annoyed by my name...