[Shootout-list] Safety vs. speed

[Brandon J. Van Every]

Peter Hinely wrote:
>
> > Define "safe".
>
> Okay, I'll take a stab at a simple, useable definition.  For bounds
> checking and type safety:  Basically, whether the memory of
> the runtime
> itself can be corrupted by a programmer's programming mistake in the
> language.  In other words, a corruption so severe is possible that the
> exception handling mechanism of the language is not capable of
> detecting/handling whatever has happened.

Any language with a C FFI is unsafe.

> For integers:  Whether integers silently overflow or not.

This is orthogonal to what you said above.  Overflow affects the
accuracy of the computational result.  The computational result is not
necessarily used to access memory.  It might, for instance, represent a
pixel brightness.  It is hardly 'unsafe' to clamp pixels at white.  It
is less accurate, but that's always the tradeoff.  "Good, Fast, Cheap -
pick any two."

> > Personally, I think it's beyond Shootout's mandate.  We're
> > not measuring a language's "goodness", just it's "performance".
>
> If that is the case, then perhaps the name of the pages
> should be changed
> from "The Great Computer Language Shootout" to "The Great Computer
> Language Performance Shootout" to more accurately reflect that.

Sounds good to me!  Anyone else like it?


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.