Re: Article of interest: Python pros/cons for the enterprise
- From: Paul Rubin <http://phr.cx@xxxxxxxxxxxxxx>
- Date: 02 Mar 2008 09:02:38 -0800
Robert Brown <bbrown@xxxxxxxxxxxxx> 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.
.
- Prev by Date: SV: Keeping the console window
- Next by Date: Re: Can one get "for x in y" to work for non builtin classes?
- Previous by thread: Problem with the strip string method
- Next by thread: Re: tuples, index method, Python's design
- Index(es):
Relevant Pages
|
