Re: Is strong typing worth the cost?

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

Marin David Condic wrote:
> I'm pretty well convinced that you can't really conduct an experiment to
> demonstrate the superiority/inferiority of strong typing by using two
> different languages.

I don't think you can have a single language that has both strong typing
and not strong typing. Getting rid of the strong typing in a language
allows you to replace that part of the design and coding with other
techniques.

> In general, we convince ourselves that for larger systems, failure to do any
> up front design costs a lot at the back end in terms of missed requirements,
> debugging, rework, total failure, etc.

Except there's also a lot of empirical evidence that suggests this is
not so, in some fields of software development. 

Certainly, if you're building software to run the space station, doing a
lot of up-front development is important and cost-effective.

On the other hand, if you're writing run-once software, it's pretty easy
to see that the cleanliness of the design is virtually irrelevant.
Consider software to animate a crowd of CGI characters in a movie. As
long as the end result looks good, it doesn't matter what the code looks
like. It could be the most god-awful mess of spaghetti code and misnamed
uncommented variables you can imagine, and it just doesn't matter. As
soon as the film is out, you're never going to run the program again.
Certainly if the requirement is "make the fur on the monster look
realistic", the first place to start is not the type system.

> I'm not sure that there is any
> "scientific" evidence we can point to, but certainly a lot of experience
> that tells us this ought to be "Conventional Wisdom". 

Yes. Which is why it surprised the people who abandoned such wisdom when
they were far more successful than those that came before them using
that wisdom.

> Most of us with experience doing this will contend
> that, yes, it costs something up front but it saves a lot at the back end.

I think in some environments, like where the requirements are changing
faster than you can code and test, that saving costs on code that you no
longer need by the time you've finished implementing it is not a
worthwhile expenditure, regardless of how much you save. In that
situation, the trick would be to save 100% of the costs.

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