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

Okay, first of all, please note that when I started this off
by saying "static typing is for people with weak minds" I
put a SMILEY at the end of it :-)  That means it's a joke, folks.

Static typing has its place, but that place is not Ruby.  It may
be a perfectly fine concept, and useful in some, perhaps even many 
circumstances, but not in Ruby.  You want static types, the
SmallEiffel folks would love to have your help.

There are no types in Ruby in the way you think.  A class is 
a collection of methods and variables, both of which may be altered 
from time to time and at anytime.  Individual objects may be
extended with different methods from other objects of that class.
So what is a type in this environment?

    >>"Thaddeus L. Olczyk" wrote:
    >>> Considering the heaps of praise Eiffel has recieved
    >>> from the OO community I would suspect that most feel it has benefit.

I personally like Eiffel.  I think it has great benefits.  But
while everyone praises it, no one uses it.  Why is that?  Is
it more academically correct and not as convenient as it could be?

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

    >And if you were to ask an Eiffel adherent, most would reply that
    >" programming by contract" includes static typing. Indeed what is
    >meant by contract? According to OOSE the contract is the interface
    >and the constrictions on the interface ( pre and postconditions,
    >invariants ). This definition implies that a contract requires static
    >typing.

I disagree strongly.  While Meyer is an advocate of static typing, I
see no reason that DBC cannot be effective in a dynamically typed
environment -- in fact, it seems to me that DBC could be even *more*
useful in a dynamic environment than in a static one.

A precondition asserts a routine's expectations of the state of the
world.  A poscondition verifies the results of the operation.  
Why do you feel that static typing has *anything* to do with expressing
the semantics of an operation in this manner?  I would argue that
DBC in a dynamic language gives you the best of both worlds -- some
guarantee that you're doing the right thing (the objects you are
dealing with honor the semantics you expect, regardless of type), 
along with the flexibility of dynamic types.

    >Frankly, I don't buy what a lot of the studies say ( hey. Microsoft
    >has thousands of studies ).
    >The point is that studies are unreliable in SE. In fact they are a 
    >poor imitation of studies done in other areas with a more rigourous
    >foundation. 

It is easy to be mislead by statistics, and since virtually every
major software is unique in its own way, conclusions drawn from
a relatively small sample set may in fact be suspect.

A recent issue of IEEE's Computer magazine focused on the issue
of the lack of science in computer science.  Virtually every book
you read on OO theory, project managment, or methodology has little,
if any, evidence to back it up.  In other disciplines these works
would be laughed out the door, but in Computer Science they are
hailed and studiously followed by many.

    >As for dynamic typing, I know of several programmers who have worked
    >on Smalltalk projects. In each case the story is the same: we spent
    >two weeks writing the code and five and a half months getting it to
    >work write ( due to dynamic typing ).

That speaks more of the programmers than the language, I think.
The contrasting story goes like this: it took five months to
write the code in C++, get it to compile without warnings, not
core dump, link in under a day, etc., and then only five months 
to get it to work right.

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

An interesting thought, but one for another language.  Fatal 
flaws of most languages seem to get introduced by committees :-)

Languages should be as small as possible, but no smaller,
and never, ever, larger.

/\ndy