From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d89b08801f2aacae X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-30 23:20:09 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsxfer.visi.net!154.32.99.10.MISMATCH!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Is strong typing worth the cost? Date: Tue, 30 Apr 2002 16:20:15 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <4519e058.0204290722.2189008@posting.google.com> <3CCE8523.6F2E721C@earthlink.net> <3CCEB246.9090009@worldnet.att.net> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1020198016 18157 136.170.200.133 (30 Apr 2002 20:20:16 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 30 Apr 2002 20:20:16 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:23317 Date: 2002-04-30T20:20:16+00:00 List-Id: 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" 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. >