< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous (in thread)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
On Tue, 18 May 2004 21:56:52 +0900, Dave Thomas wrote:
>> One (possible, and not mine) argument against duck typing is that you
>> are essentially required to write assorted unit tests beyond checking
>> for operationally correct behavior; the compilation step for a
>> staticly typed language offers these (albeit compulsory) "unit tests"
>> for free.
>
> No one requires you to do this. Instead, you do this if you feel
> uncomfortable with your code. After a while, you stop feeling
> uncomfortable, and realize that all this type discussion is simply a
> red herring, and get back to writing proper code and the tests to test
> it. A few months after that, you're surprised when you realize that you
> haven't had a single type-related error.
>
> This is simple a question of experience. When you first start out, you
> feel exposed because Ruby doesn't let you add type annotations to
> variables (I know I did). Knowing that it worked OK in Smalltalk, I
> made the conscious decision not to fight this, but instead to see how
> it worked just doing it the Ruby way. It was hard at first, and I kept
> fighting some inner demon who wanted me to add "kind_of?" calls
> everywhere. But after a while, I realized that my code was no less
> accurate than it was in Java, and that I didn't really need the type
> information. Once I overcame that fear, I suddenly realized that I
> could also get a lot of benefit from the flexibility: the realization
> that type != class, but rather that type equals capabilities was a
> revelation, and it has fundamentally changed the way I code.
>
> However, I honestly believe that there is no short cut on this path:
> the only way to come to understand the true nature of typing in Ruby is
> to write a bunch of code the Ruby way, and to gain your own experience
> (and form your own opinions). Unit tests are a safety net that can be
> used while crossing that wire. Once across, you'll be able to form your
> own opinions about the effectiveness of unit tests for type-related
> checking.
OK, but I personally find it difficult to write unit tests for some kind
of programs (especially web and GUI applications). I don't see any
testing frameworks for such programs laying around. I really would like
to follow the path you presented above, but how can I do this without
being able to write tests? You said before you mostly write web
applications - could you share your experience regarding testing them
with us?
--
Marek Janukowicz