From: maniattb@cs.rpi.edu (Bill Maniatty)
Subject: Re: comparing object-oriented platforms
Date: Fri, 2 Oct 1992 19:13:07 GMT

In article <ken8Xe_00awRQ5OHYd@andrew.cmu.edu>, Stefan Monnier <osoelgaultier+@CMU.EDU> writes:
|> Excerpts from netnews.comp.lang.eiffel: 2-Oct-92 Re: comparing
|> object-orient.. Des.Kenny@bbs.actrix.gen (2292)
|> >   I guess we are talking about specific implementations of a language
|> >   in this context.
|> 
|> >   In addition to the time it takes to edit a module of an application
|> >   and test the result. There are also other important software engineering
|> >   issues for large systems in industry to consider.
|> 
|> >   In ISE Eiffel 3 we still have static type checking even with an 
|> >   interpreter/compiler mix. This may be more important for the quality
|> >   of a system in the longer term. Rapid development of modules with
|> >   no static type checking may risk type failure in production. So what
|> >   is really rapid about having to fix type errors at the production stage?
|> >   I am sure there are some Smalltalk developers who rarely allow type
|> >   errors into production. But is it not better to let these errors be
|> >   eliminated by the development tool before production? I prefer the
|> >   environment to help me as much as possible with quality assurance
|> >   as early as possible in the lifecycle.
|> 
|> 
|> Getting a working application in a limited time is not just 
|> done for pleasure: customer generally wants to see a working 
|> prototype of the application to be sure it can be done, to see how
|> it's gonna work and so on.
|> Static type checking makes it harder to develop code in limited
|> time (prototype doesn't have to be bug free, nor fast, nor complete)

We have a trade off between quick turnaround and correct implementation.
I suspect correct implementation is much more important, as most
software costs are fixing design and implementation errors.

Do you realize how disasterous it is to have a prototype crash in front
of the customer?  A prototype must be sufficiently robust to gain the
customer's confidence in the developer.  (Of course demo for insiders is
much more relaxed, but it is still quite embarassing).

|> 
|> What is needed is a language that permits you to write 'free code'
|> (without too much verification done by the language) to start 
|> fast and get a working prototype in very short time. And then
|> add type constraints (etc...) to get to a 'bug-free' (grin) stable
|> application.

When the programmer makes type errors, there is a serious semantic error
in the source code.  The whole point behind a rigorous type checking system
is that the programmer is notified immediately about the semantic errors, and
can fix them on the spot, rather than at some convenient time like, ... never.

Please consider the rate of turnover of programmers, and that even if the
programmer that originally wrote the code is the one to fix it, that most people
cannot remember details for any length of time.  It is much more costly to
fix things later in the development cycle.  Also remember that while the error
is waiting to be fixed, other code has been built which might integrate
with the damaged software.

|> 
|> Sure debugging is easier with static type checking, but this help
|> sometimes turns out to be a hassle: it should be possible to turn
|> it off (completely or partly)

Early detection of errors in the development cycle reduces the number of reworks,
and the cost of reworks.

|> 
|> I'm sure this kind of Smallfel (or is it Eifftalk ?) is coming
|> and will be very nice (I like to dream, you know)

I strongly suspect that rigorous type checking at compile time is the way
to go.  Of course, life is full of exceptions, so there should be a way
to explicitly disable the type checker for small regions of code.

|> 
|> 	Stefan

Bill

-- 
|
|	maniattb@cs.rpi.edu - in real life Bill Maniatty
|
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object