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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no 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-05-01 20:55:13 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!supernews.com!skynet.be!skynet.be!feed1.news.be.easynet.net!easynet-monga!easynet-melon!easynet.net!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: Wed, 1 May 2002 13:25:35 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <9gBz8.4054$%r1.2380315867@newssvr21.news.prodigy.com> <3CD01D32.19D997B0@san.rr.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1020273936 17317 136.170.200.133 (1 May 2002 17:25:36 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 1 May 2002 17:25:36 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:23390 Date: 2002-05-01T17:25:36+00:00 List-Id: "Darren New" wrote in message news:3CD01D32.19D997B0@san.rr.com... > Following up on several posts at once... > Makes it kind of hard to respond... > > Well, depending on the project, you might consider things like XP to be > evidence that such a system can be made more productive than a strict > top-down design blah blah. > I wasn't thinking of XP or any other development methodologies, etc. I was talking about language philosophies - Ada has a distinct philosophy that distinguishes it from other languages like C. (Programs should be more readable than writable. Programs should have checks done by the language rather than the programmer... etc...) If what you want to test is the relative efficiency of this philosophy as compared to the C philosophy, then you'd have to introduce them both to the same development process. Anything else and you've got a worthless experiment. > However, I think the benefit of something like Ada over something like C > is pretty clear. It's just not clear to me that the benefit of something > like Ada over something like Smalltalk or Common Lisp or FORTH or > something else with an entirely different philosophy of programming is > as obvious. > I don't know of any studies that introduced Ada into a process that used to use Smalltalk, etc. (or the other way around) and demonstrated any change in productivity or quality. It would be interesting to find out, but given the more niche-market characteristics of the above languages, its harder to find case studies - real or potential. > > > standard disclaimer: "All Other Things Being Equal" :-) > > And the problem is that in reality, all other things aren't equal. A > language specifically designed to be weakly typed, or dynamically typed, > or something like that isn't going to be equal to Ada in most other > ways. If all you know are the "romance languages" of programming > (procedural imperative statically-typed languages), this may not be as > obvious. > That's one big reason that it is hard to study the impact of language, or some specific language characteristic, on productivity and quality. It is unbelievably hard to make all other things equal. This would be true even within the "romance languages" so its just plain hard to do anything that doesn't immediately come under fire as not being scientific or at least seriously flawed. > > > Things like that *can* become functional requirements as in "The system > > shall detect all input that is out of range..." or "The system shall never > > generate an output for this device that exceeds its safe operating > > range...." All that requires some kind of constraint checks at points > > throughout the code where a weak typed language is going to be at a > > disadvantage because you'll have to manufacture your own checks. > > It's not clear a weakly-typed language is going to be at a disadvantage > from this. Consider a compiler that has a requirement to give a syntax > error for any malformed input. Something like Ada could declare types > representing valid syntax trees and build the syntax trees during > parsing. But the Ada code is still going to have to check the input as > it reads it in order to give an error message rather than throwing an > uncaught exception. Something like an SQL RDBMS written in Ada is going > to have to do pretty much all the same checks in Ada as it would in C. > So once you get to a high enough level of input checking and error > reporting, you can't rely on the constraint checks to tell you what's > wrong with your input. You really don't want a stack traceback printed > out on your payroll checks. > I think this is a separate issue. Think in terms of two levels of checks. The first safeguard (which may be a requirement) you might call "Sanity Checks". If you know your inputs are supposed to be in some range or that they must be valid ASCII characters or that arrays have to be of some specific size or you have to insure you can't walk off the end of a buffer or whatever, and all those things are considered to be system requirements, then any weak typed language is going to be at a disadvantage because you'll have to code all those checks yourself. The next level of checks for validity - the kinds of things you bring up such as a compiler looking for valid syntax - those are going to be very application specific and you'll have to manually code those checks no matter what language you use. So is the requirement to do both validity checks and sanity checks? If so, weak typing loses. > > And XP addresses this by making every debug session a multi-minute debug > session. For some types of developments, it really does work, even > without the strong typing. (Well, it's strongly typed, but dynamically > typed, so I don't think the OP would consider it strongly typed.) And > indeed the keeping track of bugs found and fixed is one of the central > mantras of XP. The way you program is you first insert a bug ("The code > doesn't yet implement this new requirement, so the test that it works > fails, so that's considered a bug") then you fix that bug. > You're bringing up process - not language. Process may be interesting, but I don't think it has much to do with the original question. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com