From: Rik Hemsley <rik@...>
Date: 2001-11-27T09:59:08+09:00
Subject: [ruby-talk:26581] Re: String#== : Why not error with different type?

#if Yukihiro Matsumoto
> Hi,
> 
> In message "[ruby-talk:26498] Re: String#== : Why not error with different type?"
>     on 01/11/26, Ryo Furue <furufuru@ccsr.u-tokyo.ac.jp> writes:
> 
> |I got it!  Thanks for the explanation.  It seems that I've spent too
> |much time with statically-typed languages and I've been "spoiled" by
> |the sense of security that statically-taped-ness brings.  But, I
> |wonder:  Don't you (not only you, Matz, but also you Ruby programmers
> |in general) a little bit fear this flexibility?  I said "sense of
> |security" because type mismatch very often indicates mistakes.
> 
> If you go though the unit test, bugs like that can be found easily.
> I believe static typing does not buy you much.  Just "sense of
> security", excuse, and optimization oppotunity.  They aren't worth the
> price of flexibility for most of the cases.

The thing that shocked me the most was when a String turned into nil,
and 'rescue' didn't work.

a = 4
b = -2 # oops !

begin
  "abcde"[a,b].length
rescue
  print "Phew! - but we don't get here\n"
end

Thankfully this seems to be fixed in 1.7

I don't think static typing /only/ buys you a 'sense of security' an
some optimisation opportunities. It allows the compiler to tell you
'this won't work as you expect' before you run your code. That's
the most important aspect IMO.

This doesn't mean I think static typing is essential. In fact, in some
ways it can be better for my String to turn into nil. This way, I can
see an exception at runtime, and know there is a bug in my code (and
where it is). With C++, I would just get the wrong answer, and I'd have
to go and look for the bug myself.

Rik