Static typing ain't so bad, after all

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

···

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

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.

···

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?

Hi --

   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.

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.

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

David

···

On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote:

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
   ----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.

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.

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-forum.com/.

I must be missing something. i can't see why you didn't just ask the debugger by typing <parametername>.class

···

On Aug 22, 2006, at 5:30 AM, Just Another Victim of the Ambient Morality wrote:

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

--
Egotism is the anesthetic that dulls the pain of stupidity.
-Frank William Leahy, football coach (1908-1973)

I do not agree with all you said, but I think you made a valid point.
I am completely surprised and sad how you get shouted at and insulted, by
some of the most respectable members of the community.
I think it would have been a good approach to give OP a break and take one
before all jumping at him at the same time.
Of course static typing has it's merits, of course we do not want it, of
course dynamic typing has its merits, maybe you do not want it, I do, he
does.

That was a brave thread you have fought OP;) well but you were outnumbered
:slight_smile:

Cheers
Robert

···

On 8/22/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...

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

On 8/22/06, Just Another Victim of the Ambient Morality <
ihatespam@rogers.com> wrote: 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...

Thinking about this thread, I was wondering why I've generally had so little
of this kind of problem. For about a year after I first learned Ruby, I
thought the most irritating thing about the language was that I had to do my
own type checks of all the arguments in every single method I wrote, because
the d**n language wouldn't do it for me. (Can you tell I'm a hard-core
security-oriented C programmer?)

When duck typing finally sunk through my thick skull, it changed everything.
But I notice one thing. It's often said that the intent (including the
desired datatypes) isn't too hard to discern from a quick look at a method's
code or documentation. But this is primarily true if the argument types are
simple or primitive. Strings, IOs, numbers, or collections of same. If
you're passing around objects that are more complex, especially ones that
incorporate domain-specific information, that's when you really get into
trouble.

Because whether you use static or dynamic typing, you are tightly coupling
one set of domain knowledge
(in the argument) with another (that of the method you're writing). This is
where a lot of fragility comes from, to say nothing of difficulty in
understanding the intent. Seeing the argument-type declarations in the text
of a method you are trying to understand
isn't much better than seeing them described in a document, because your
real challenge is still to grasp how the non-primitive design contained in
the argument interacts with that of the method.

This is where one of Ruby's more distinctive features, the yield, can help a
lot. I find that when I'm tempted to pass a big chunky object to a method of
some other big chunky object, I either look for the design commonalities
that I obviously missed in the first place, or else I look for ways for the
method to yield to the argument. Just to avoid coupling them more than is
really necessary.

In the more typical case where you're passing around integers, strings, and
IOs, it just doesn't seem to matter nearly so much. Your first guess on
looking at a method you're trying to understand is probably going to be
right, and spelling out the arg types in the text subtracts readability
without adding comprehensibility.

In short, it's been said here that documentation is the key to the problem,
but I'd like to put in a good word for design as well.

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.

<dblack@wobblini.net> wrote in message
news:Pine.LNX.4.64.0608220913080.27742@rubypal.com...

Hi --

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

···

On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote:

"Farrel Lifson" <farrel.lifson@gmail.com> wrote in message
news:c2c0b660608220540y3cf55b18v18c5879ce4ea55a9@mail.gmail.com...

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

···

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

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

dblack@wobblini.net wrote:

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.

McConnell's Code Complete, too, for basic engineering practices

http://cc2e.com/

"Chris Gehlker" <canyonrat@mac.com> wrote in message
news:C1967BEB-2E20-488B-9977-5EA3B9CB1AC3@mac.com...

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

I must be missing something. i can't see why you didn't just ask the
debugger by typing <parametername>.class

    That's a good question...
    I wasn't looking at the source at runtime... I could have run it and
stuck a breakpoint but that's when the problem occured to me. In a
hypothetical case, the code might be hard to execute. Indeed, if you're
looking at someone else's code then you might have no clue as to how to
execute it. You could write some code to call it directly but that
wouldn't give you insight into how the method is used.
    In my case, the debugger is really slow and it would have taken quite a
while to reach the breakpoint...

···

On Aug 22, 2006, at 5:30 AM, Just Another Victim of the Ambient Morality > wrote:

Word! I still remember the time I found a bug in my code simply by
renaming a poorly-named method. As soon as I saw the result of the
replacement I thought "Hold on, that's wrong!".

Jeremy Henty

···

On 2006-08-22, William Crawford <wccrawford@gmail.com> wrote:

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

You'll come round! I did, and I was a hard-core ML/Haskell lover.
They all crack in the end! :wink:

Jeremy Henty

···

On 2006-08-22, William Crawford <wccrawford@gmail.com> wrote:

As for static typing... I feel your pain. It's heresy, but I
prefer static typing.

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.

Here, take a "PWNT3HN00BS!" T-shirt. Brought to you by the Grumpy Jaded Gits Anonymous.

The best strategy is to take two painkillers, wait for the caffeine to wear off, and then start copy/pasting the explanations. MustExpandYourEmailClientsAdressColumnToThreeTimesItsUsualSize is obviously a tad bit new, so you can either start making scary hand-motions in hopes he runs for the hills, or join the crowd in showing him The Light. I actually find that strangely soothing - gives me that fuzzy feeling all over when someone Gets It.

*wombles back to proselytizing*

David Vallner

William Crawford wrote:

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

Static typing has limitations where dynamic typing doesn't have them, but they're really few and far between. Doing proof-of-concept code, or exploring more exotic design patterns come to mind. Horses for courses, I presume, I'm in the "add optional type / interface / protocol adherence checks" camp myself.

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

Har. So far, only the spam filters in my head go off. Reminds me of my little sister's 12 year old IM friends that whap arbitrary deep-sounding fluff into their screen names.

David Vallner

Hi --

<dblack@wobblini.net> wrote in message
news:Pine.LNX.4.64.0608220913080.27742@rubypal.com...

Hi --

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

ruby-talk is this mailing list. It's mirrored to comp.lang.ruby.
Have a look at
http://blade.nagaokaut.ac.jp/ruby/ruby-talk/index.shtml. You can
start with the 694 messages that come up on a search for "static
typing". Then the 393 on "strong typing". Then see what's left to
say about typing, class vs. type, strong vs. static, duck vs.
whatever....

Also, see http://www.rcrchive.net/rejected.html#rcr120.

Honestly, this is, like, the king of ruby-talk perma-threads. You can
rehash the thread if you end up feeling it's necessary, but do please
look at the six years of discussion and analysis first.

David

···

On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote:

On Tue, 22 Aug 2006, Just Another Victim of the Ambient Morality wrote:

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
   ----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.