Article of interest: Python pros/cons for the enterprise

[Robert Brown]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> Robert Brown <bbrown at speakeasy.net> writes:
>> This is the approach taken by Common Lisp.  Often just a few type
>> declarations, added to code in inner loops, results in vastly faster code.

> That is just a dangerous hack of improving performance by turning off
> some safety checks, I'd say.  Static typing in the usual sense of the
> phrase means that the compiler can guarantee at compile time that a
> given term will have a certain type.  That can be done by automatic
> inference or by checking user annotations, but either way, it should
> be impossible to compile code that computes improperly typed values.

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.

Common Lisp compilers are allowed to completely ignore type
declarations, but the compiler I use, SBCL, uses a combination of
compile-time type inference and run-time checking to ensure that my
variables have the types I've declared them to have.  Sometimes I see an
error message at compile time but otherwise I get an exception at run
time.  It works this way because my code contains

    (declaim (optimize (debug 3) (safety 3) (speed 0)))

which indicates I prefer correctness and ease of debugging to run-time
speed.

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.

bob