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

On Thu, 15 Jun 2000 13:58:56 -0500, Conrad Schneiker
<[e-mail]> wrote:

>Hi,
Hi
>
>"Thaddeus L. Olczyk" wrote:
>
>> 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.
>
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.

>> 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).
>
Frankly, I don't buy what a lot of the studies say ( hey. Microsoft
has thousands of studies ). The last one I saw was by Laurie Williams.
I saw several flaws in it. (It was on pairs programming). The
primary was that she was making claims about the whole programming 
community based on studies done on college sophmores. It was not done
in circumstances of great time pressure etc. Did she go out and do
more studies trying to fix the holes? No. Instead she's going around
lecturing the industry on the benifits of pair programming ( and
probably making a ton of money ). Me, I ask a simple question.
What would happen if I pair off with my twin? Either a kickass
programming team, or two dead programmers. Bye bye pair programming.

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. 

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

My only serious experience with dynamic typing is a small project I am
working on right now. There are several special cases which popup late
in the data I am working on ( something has to come last, it takes ten
minutes to process the data  ). For this set of data they are special
for others they may not be. When I make a change I have to spend a
long time correcting the code because I can't trust the compiler to
tell me that I am not catching the code for one of the special cases.
I still miss a few here or there.

>
>> 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.
>
I don't think so. You need a casting mechanism ( and a null object
for when you can't cast ) between the two. You have method parameters
which are either typed or untyped. If you call a method with a an
untyped object and that method  requires a type, you do a typecast
before you pass it. If you call a method requiring an untyped object
with a typed object, the compiler simply ignores the type information.

The hard part is deciding what classes can and coannot be used by
static types. Even that is not hard.