Re: Is strong typing worth the cost?

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

"Darren New" <dnew@san.rr.com> 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