From: Rick DeNatale Date: 2008-02-22T21:26:35+09:00 Subject: Re: Ruby type-safe? Ruby strongly/weakly typed? Ruby pitfalls? On 2/22/08, Yukihiro Matsumoto wrote: > At least, the Wikipedia entry for Ruby is not the right place to > describe the definition of type-safety and strong typing, since same > thing happens on language with similar type concept, like Python, > Lisp, or Smalltalk. They should have their own entries if they didn't > have yet. At the very least that section should be moved from the main article to the discussion page, it strikes me as violating wikipedias NPOV policy. I'd also argue that this whole issue of "type safety" should be abstracted a bit to talk about safety in general. My experience is that those who demand "type safety" are concerned about the type of bugs which happen when executable code which depends on assumptions about the format of the date it operates on which is bound at compile time encounters data which violates those assumptions. highly "type safe" languages like C++ bind a lot of such assumptions into the executable code, Java less so, Smalltalk less than that, and Ruby the least of the four. http://talklikeaduck.denhaven2.com/articles/2008/02/08/whose-variable-is-it-anyway The difference it seems to me is that at one end the philosophy is "check the credentials at the door, and if they pass, let whatever happens happen", and at the other end, it's "trust but verify." Trust but verify is actually safer in the end because it tends to keep really bad things from happening when the credentials are confused or forged, albeit at some cost of overhead. It also provides more flexibility and does away with the programmer overhead of "high ceremony" languages like C++ and Java. And years of development of dynamic languages like Lisp, Smalltalk, and Self have shown how to minimize, or even eliminate in some cases, the overhead of late binding. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/