On Wed, 14 Jun 2000 14:20:13 -0400, Andrew Hunt <andy / Toolshed.Com>
wrote:

>	>Static typing..., hmm,...
>	>
>	>							matz.
>
>Argh!  Don't do it!
>
>"Static typing is for people with weak minds"  :-)
>
>/\ndy
First in defense of static typing.
It's strange that you pick on static typing given that Ruby boasts of
strong Eiffel roots and tha Eifel itself is statically typed ( if I
remeber correctly BMeyer insists static typing is critical to a good
OO language ). Considering the heaps of praise Eiffel has recieved 
from the OO community I would suspect that most feel it has benefit.
Aside from that   ( sorry not to go into details, but it's late I want
to get to bed )  static typing helps to prevent many errors,
especially ones that happen at crunch time. To avoid these errors
in a dynamically typed language, you would need to have many many more
tests, and be sure to have 100% coverage. However for this type
safety, you give up many of the benifits of dynamic typing, in
particular, full scale reflection/introspection and heterogenous
collections.

It seems a shame that that you throw out the safety of a statically
typed language, when you don't use what a dynamically typed
object brings you most of the time ( I figure you really take
advantage 1%-10% of the time ). So why not do this? Make Ruby a
language with both static and dynamic type. You can declare an object
to be of a type (eg MyClass MyObj ) in which case it is statically
typed or you can declare an object untyped (eg untyped myObj or
dynamic myObj ). You would need the standard typing rules for the
static variables ( casting rules, type heirarchies etc. ). You also
would be able to cast from dynamic to a particular type and
vica-versa. Function calls could be either typed or untyped
( foo( MyClass MyObj) or foo(MyObj) ). You probably would want
a static keyword to denote a class as being statically type.

It would be interesting to see where people used static variables, and
where they used dynamic variables.