Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!amethyst!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: Runtime Polymorphism -- To Have and Have Not (Par
Message-ID: <583@coatimundi.cs.arizona.edu>
Date: 5 Mar 91 20:56:42 GMT
Sender: news@cs.arizona.edu
Lines: 80

In article  <2741@enea.se> Erland Sommarskog writes:
]Also sprach David Gudeman (gudeman@cs.arizona.edu):
]>There are several advantages to this.  First, it makes program
]>prototyping and developement much faster because declarations are
]>minimized.
]
]Hm, I don't have the figures here, but which phases takes
]most time in the life of a software product? Prototyping?
]Development? Testing? Integration? Maintenance?

Depends on what sort of product it is.  And if it isn't a product, but
a utility for personal use, then the figures probably differ even more
dramatically.

] I could
]be wrong, but I don't think it is the prototyping and
]early development stages when you could sneak some typing
]time with shorter declarations.

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.

]... Maintenance and support will
]be more expensive.

And those are the areas where runtime polymorphism gives the biggest
advantages.  It is a lot easier to add features when the language is
more flexible.  Systems written in languages with runtime polymorphism
tend to grow astronomically since they are so easy to modify.  (This
is not an unmixed blessing.)

](Particulary support since you are
]likely to get more crashes due to typing errors and similar.)

There is no reason why a program written in a language with runtime
polymorphism should be less robust.  I do almost all my work in GNU
emacs.  Huge amounts of the system are written in Emacs Lisp (a
language with runtime polymorphism), and I have never encountered a
bug in distributed code.  (There _are_ bugs of course, but they are no
more common than in any other system with comparable functionality.)

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

] And assure at compile time, 
]that I don't pass incomparable or uninsertable types to the generic 
]routine.

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?

]>But in my experience this is a minor
]>problem, and the time spent looking for these errors is quite small
]>compared to the time that would have been spent writing strongly typed
]>declarations.
]
]You've tried this in 500.000 line system? What did the customers
]say?

Not all programs are 500,000 line systems, and not all programs have
customers.  However, there have been plenty of huge programs written
in these languages (most notably lisp) and distributed to others, and
these programs have not shown greater problems with robustness than
programs written in other languages.  I wouldn't be surprised that
feature-for-feature, programs written in these languages are _more_
robust, since feature-for-feature they are much smaller than programs
written in strongly typed languages.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman