Article of interest: Python pros/cons for the enterprise

[Paul Rubin]

Robert Brown <bbrown at speakeasy.net> writes:
> Unfortunately, performance often comes at the cost of safety and
> correctness.  Optimized C programs can crash when pointers walk off the
> end of arrays or they can yield incorrect results when integers overflow
> the limits of the hardware.

Yes, even unoptimized C programs can do that.  C is just plain dangerous.

> [SBCL Common Lisp]
> Very rarely, say inside a loop, I temporarily change my default compiler
> settings.  Inside the lexical scope of these declarations, the compiled
> code does no run-time type checking and trusts me.  Here, broken Lisp
> code can crash the system (just as broken C code can), but the compiled
> code runs very fast.
> 
> I trade off safety for speed, but only where necessary.

It seems to me that this trade-off results from a problem with the
language's expressivity.  If you have a sound argument that the
subscripts in your loop are actually safe, you ought to be able to
express that argument to the compiler for static checking.  That
should result in safe code with no runtime checks needed.

That said, trying to provide that level of expressivity is at the
cutting edge of programming language research, and in real-world
languages, for now, we have to live with some runtime checks.
But in an example like (pseudocode):

   for i in 1..100:
       hack(x[i])

it should be enough to check outside the loop in constant time that
1..100 are valid subscripts for x, then generate the loop code with
no check on each separate access.  That is maybe not possible in C
because i might be aliased to something, but in a sane language it
should be possible.