[ruby-talk:03441] Re: Static Typing( Was: Waffling between Python and Ruby)

Hi,

"Thaddeus L. Olczyk" wrote:

> On Wed, 14 Jun 2000 14:20:13 -0400, Andrew Hunt <[e-mail]>
> wrote:
>
> >       >Static typing..., hmm,...
> >       >
> >       >                                                       matz.
> >
> >Argh!  Don't do it!
> >
> >"Static typing is for people with weak minds"  :-)

Well, that sounds like some pretty strong stereoTYPING of the people that
gave us Unix and Linux. :-)


> >/\ndy
> First in defense of static typing.

I think what is missing here is _optional_, and maybe consideration of
whether there are other means to what is indisputably _sometimes_ a very
desirable end.


> It's strange that you pick on static typing given that Ruby boasts of
> strong Eiffel roots

Well, I think this is more a matter of giving credit where credit is due,
not boasting as such, and a matter of taking what features seemed most
useful for Ruby, versus the core language (granted there is overlap
involved).


> Considering the heaps of praise Eiffel has recieved
> from the OO community I would suspect that most feel it has benefit.

I think a major benefit was support for "programming by contract". There
has previously been a little discussion of how to do this in Ruby.

> 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 ).

While static typing is  _somewhat_ more safe in _some_ ways, but with
respect to frequency of bugs (which tend to increase with length of code
and time to implement), most studies I have seen references to (sorry,
don't have any handy) don't show clear-cut advantages except for special
cases (which granted may be important for some types of critical
applications).


> So why not do this? Make Ruby a
> language with both static and dynamic type.

I think this might be possible, but I think there would be all sorts of
complex issues concerning the often subtle and indirect interactions of
these 2 very different styles of doing stuff.

Maybe a better way of thinking about this in the Ruby context is to think
in terms of how to support "constant types". When Ruby's CRAN library
becomes as large as Perl's CPAN library, it seems obviously desirable that
there be some sort of reasonable constraint on dynamic changes that can
unexpectedly break things (the recent discussions on $-variables are an
example of this concern), or perhaps some improved way of expressing its
existent capabilities.

--
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)