Re: Is strong typing worth the cost?

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

Marin David Condic wrote:
> 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.

Sure. Here's my problem with the whole "scientific experiment" bit.

It's obvious that a trivial way to do the experiment would be to use two
versions of Ada, one where you get to use the whole language, the other
where you get to only use the base types and all the run-time checking
is turned off at compile-time. That would seem to be about as close as
you can come to having the same language both strongly and weakly typed.
Maybe C vs C+Lint would be the other way to go.

But obviously, the second version of Ada is a subset of the first
version of Ada. Running off the end of an array or overflowing a
variable or whatever is going to be an error. It won't be caught without
the run-time checking, but it's still an error. So the run-time checking
doesn't really give you any benefit when the program is correct
(assuming you don't intentionally throw and later catch constraint
errors or something rather than returning inside an "if", say). 

So clearly the first group *could* be just as productive as the second
group by simply ignoring the range checks in Ada, and *will* be more
productive because the errors are caught earlier.

My point being that it sounds like a pretty worthless experiment,
because it's so constrained that the outcome is obvious. The interesting
part is to ask what using a language with weak typing buys you. If the
language with weak typing is Ada, it doesn't buy you anything. If the
language with weak typing is C, it buys you programmer experience, more
populous newgroups, a plethora of syntax-directed editors, code
generators for GUIs, zero-effort interfaces to third-party libraries,
etc etc etc.
 
> 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.

Errr, this is odd. What do you think the "niche market" is for Smalltalk
or Forth? Do you really think Smalltalk's market is more of a "niche"
than Ada's?

Now, if you'd said that Atlas is a niche language, or Postscript is a
niche language, or YACC is a niche language, I'd agree with you. But by
what criterion is Smalltalk or Forth a niche language?

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

I'd say it's easy to determine the impact of language choice on
productivity and quality. However, I'd say that things tangential to the
language may have a serious effect. For example, it's possible that
Smalltalk's model of the environment (in terms of debugging, code
editting, "workspace"-style program management, etc) make it far more
productive in some situations than Ada is. However, it's not independent
of the language, because Ada can't do the kinds of things that Smalltalk
does in that regard.

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

Again, I'd say it's easy to evaluate the choice of language+environment
on programming productivity, and trying to evaluate a question of
language and discarding all the environmental differences *caused* by
the difference in the language is just silly.
 
> 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.

No, I'd think that putting in a requirement to do sanity checks would be
silly. The requirements on a program ought to be based on the input and
output. Otherwise, why not just write in a requirement that you have to
use a language where all sanity checks are done by the compiler?
 
> 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.

Except that I can't imagine the XP process working with Ada, for
example, so it is relevant. Asking about the typing independent of the
process is like asking whether it's better to travel by car or airplane
without asking how far you're going.

Take as an extreme example, if your goal is to save programming dollars
... is it better to spend money on Ada training, or is it better to
spend money to put programmers in offices with doors they can close
instead of cubicles? If your bottom line is dollars, it's not obvious
that checking strong against weak typing is going to tell you anything.
If you're just interested in strong vs weak typing, well, anything you
can do with weak typing you can also do with strong typing, so limiting
yourself to a language that only supports one is going to be at best no
better than one that supports both.

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