From: Rick DeNatale Date: 2008-02-02T09:32:53+09:00 Subject: Re: Gedankenexperiment on method duck type safety On Feb 1, 2008 3:55 PM, Tim Connor wrote: > I mean, really who hasn't been > bitten by a bug that took some digging that had to do with a parameter > not meeting some of their assumptions? Yes, and that happens with statically typed languages, actually those bugs tend to be harder to diagnose with static languages. Most of the really awful things which can happen in statically typed languages which can be caught by static type checking are caused by the fact that the compiled code relies on static types. For example in C++, it would be really bad if a member of an object was 'accessed' when the object was of the wrong type, since accessing is done by early (compile-time) bound offsets. Dynamically typed languages trade off a little bit of run-time performance for safety or at least serviceability by deferring such bindings to run-time and checking them. Other very common 'type' mistakes such as array bounds errors aren't caught by most statically typed language compilers, yes some advanced type systems attack this problem but it's still considered an advanced type-theory issue in practice. So most statically typed languages defer bounds checking to run-time if they do it at all. Back in the days when the arguments raged about C+ vs. Smalltalk, Bjarne Stroustrup was wont to say that he didn't want to fly in a plane where the autopilot could throw a does_not_understand exception, my feeling that that would be better than the autopilot branching to a virtual function through a corrupted or type-punned pointer. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/