Re: Is strong typing worth the cost?

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

In fairness, I think that the problem is a little different than just
finding examples of where strong typing reduces bugs. I think all of us here
have seen numerous examples where strong type checking had caught things
that are potentially really nasty, hard to find bugs. The question seems to
be "...But is there any scientific evidence that strong type checking buys
back more than it costs?"

To a large extent, the question is ill-phrased. Do we mean just the basic
type checking that Ada does free of charge? (Not allowing you to add
Booleans to Integers, for example.) Do we mean the kind of type checking you
get by designing types for specific purposes versus relying only on
intrinsic types? (Your height & weight example, for instance.) Do we mean
designed type checking versus duplicate semantics in another language? (Some
version of implementing range checks in C on all the things you design to
have some constraints.) I'm sure we could come up with other variations on
this theme, but these are the ones I've seen so far in this thread. (Like,
are we only talking about numerical things or does that include the kinds of
type consistency that comes with enumerals, records, arrays, etc.?)

There may not be a lot of science to back it up, but I think its pretty
clear that the first and last types I described above basically cost nothing
compared to the alternative and bring lots of benefit. The one in the middle
is arguable. To do it right, you have to go through analysis and design that
tries to identify all of the necessary types and create the proper
architecture to exploit it. That costs something up front and reduces time
at the back end. The alternative (grabbing the raw data and "Just Do It"
design) costs less up front, but (based on our experience) costs a lot at
the back end. Do you save enough at the back end to justify doing the work
at the front end? We may consider that intuitively obvious to even the most
casual observer, but it is a rather Faith Based Institution. (Other than
relying on a generally accepted principle of manufacturing that the sooner
you catch a problem, the less it costs to fix. Unless, maybe you don't care
if there are problems? :-)

Is there any science to back it up? I don't know of any that addresses that
specific topic, but it would be nice if we had some. In the mean time, I'll
continue to have my faith backed up by reason and what I can see around me.
Maybe one day the science will catch up with me. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnacts3r.2qr.randhol+abuse@kiuk0156.chembio.ntnu.no...
>
> OK this is very trivial, but think about this in a big complex program
> where the variables are not so obvious. Say a Mars probe that crashes
> due to a simple bug or whatever.
>