Re: Is strong typing worth the cost?

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

I have absolutely no argument with the notion that different problem domains
are going to have different cost drivers. I believe I said somewhere else
that if you didn't care about bugs and you didn't care about maintenance,
then design work was just an up-front cost with little to no back end
payoff. (With the caveat that if you do *no* design, your project might just
fail entirely.)

One might reasonably ask: "Couldn't the animation software be well built and
still do its job?" Is it of necessity spaghetti code? Is it somehow or other
faster to get the job done to just start plodding along laying down code
until the animation looks right? I suspect that if the hypothetical
animation developers did *some* analysis and design up front and *did* build
solid, reliable code that it would possibly not take any longer to get to
market and might yield larger chunks of things that could be reused & save
time/money on the next animation. (I wouldn't go to the extremes of analysis
& design done for safety critical software, but surely the animator still
needs to do some amount of "debugging" to get the thing to work at all and
surely that means if there were better forthought and stronger checks, lots
of those problems might be minimized.)

I see the point that throw-away code need not be well built. But it is not
demonstrated that this is somehow faster or better or cheaper than
well-built code to do the same thing.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Darren New" <dnew@san.rr.com> wrote in message
news:3CD0A3B8.7B7C8622@san.rr.com...
>
> 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.
>