Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!uupsi!sunic!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.misc
Subject: Re: Runtime Polymorphism -- To Have and Have Not
Message-ID: <2773@enea.se>
Date: 9 Mar 91 17:30:33 GMT
References: <583@coatimundi.cs.arizona.edu>
Organization: Enea Data AB, Sweden
Lines: 57

David Gudeman (gudeman@cs.arizona.edu) replies to my article:
>Typing time isn't the main issue.  It's having to make too many
>decisions up front, and setting them in stone early in the
>development.  (Data abstraction helps solve this problem, but runtime
>polymorphism is more flexible.)  Another problem is that when you
>write more code you make more mistakes.  In Icon or Lisp, you _never_
>make mistakes in the declarations because there are (almost) no
>declarations.

But do you make less type errors? And when do you find them?

I spend quite some time of declaring stuff and setting up
the types. And when I have done this I also know a lot more
what I am about to do.

>]>Another advantage of runtime polymorphism is code generality...
>]]Fine. I can do this in Ada and Eiffel.
>
>You have to write seperate code for each type that might be used.  The
>amount of code you have to write increases linearly with the number of
>types used in the program.  And increased code means increased bugs.

What do you mean? OK, in Ada you have to write

    PACKAGE Integer_list IS NEW Linked_list(integer);
    PACKAGE Array_list IS NEW Linked_list(Array_type);
    -- etc.

and then declare each list you need. But you don't have to rewrite
the list package for any type that you might think of. In Eiffel
you only declare them:

    Int_list   : Linked_list[integer];
    Array_list : Linked_list[Array[T]];

Is this so frustrating? Or do you simply not know what you are 
talking about?

>Why is that such a big deal?  What's the big difference whether you
>find a bug during compilation or during the first couple of test runs?

1) People pay me to program. The earlier I find my errors, the
   less it costs my contractor.

2) You find a type error in the first couple of test run, if it
   is a common case. An uncommon case, e.g. an error handler,
   might not wind up until you integrate, or horror after shipping.

>Not all programs are 500,000 line systems, and not all programs have
>customers.

True, but I have to admit that programs that have customers
are much more interesting to me. And 500.000 or 5.000 lines
it's not so much difference. The more errors the compiler
can find for me at an early stage, the happier I am.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se