Re: Is strong typing worth the cost?

[Darren New <dnew@san.rr.com>]

Following up on several posts at once...

> There is no scientific
> evidence I am aware of that somehow weak typing, lack of runtime checks,
> "concise" syntax or other features that are contrary to the Ada philosophy
> (The AntiAda Way?) improve productivity or reduce defects over development
> in Ada or other more rigorous languages.

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.

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.

If you're trying to convince C programmers to move to Ada, focussing on
only the strong typing is probably a bad idea, given there's good
"scientific" evidence that Ada outperforms C. If you're trying to
convince people that Ada is best, it's less obvious.

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

> This discussion is occurring in an Ada news group because Ada
> is essentially the only game in town, with regard to a) strong
> typing, and b) a reasonable sized commercial usage base.

Errr, COBOL? Smalltalk? Java? You seem to have a very odd definition for
"strong typing". 

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

> How about doing what I did: keep track of each bug found in their
> currently-developing code, and then determine whether strong typing
> would have either prevented it or turned a multi-day debug into a
> multi-minute debug.

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. 

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   The 90/10 rule of toothpaste: the last 10% of 
         the tube lasts as long as the first 90%.