"Strong typing vs. strong testing"

[John Nagle]

On 10/1/2010 7:17 AM, Rui Maciel wrote:
> Pascal J. Bourguignon wrote:
>
>> Nothing extraordinary here.  Common Lisp is more efficient than C.
>> http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf
>> http://portal.acm.org/citation.cfm?id=1144168
>
> I don't know if you are intentionally trying to be deceitful or if you honestly didn't spent much
> time thinking about this issue.  To be brief I will only point out the following topics:
>
>
> a) no language is inherently more or less efficient than any other language.  The efficiency
> aspect is only related to how those languages are implemented (i.e., the investments made in
> optimizing the compilers/interpreters)
> b) Just because someone invested enough effort to optimize a specific implementation of language X
> to run, under a specific scenario, a benchmark faster than some other implementation of language Y
> it doesn't mean that language X's implementation outperforms or even matches every implementation
> of language Y under every conceivable scenario.

     If the implementation has an omniscient compiler, yes.  If not,
some languages have serious speed penalties.

     Python has some inherent performance problems stemming from
its "gratuitous hidden dynamism".  That is, there are
bits of dynamism which are very unlikely, but not visible at
compile time, and thus very difficult to optimize out.
For example, it's possible to add an attribute to an object
from outside the object's class.  It's thus very difficult to
detect at compile time which classes could use static "slots",
and which could not.  Python allows replacing a function at
run time, even while another thread is executing in it.
(Even PHP disallows that.)  This breaks a wide range of
optimizations.  And then, of course, there's the "global
interpreter lock" problem.

     Dynamism is not the problem.  It's hidden dynamism, which
forces compiling for the worst case all the time, that's
the problem.

     Most of these problems come from CPython,
which is a naive interpreter.  The feature set of Python
is well matched to a naive interpreter.

     The organizational situation is a lot like the one with
Pascal and Wirth. There'a a very straightforward way to write
a recursive-descent Pascal compiler that compiles to a stack
notation.  Wirth wrote one of those, and insisted that the
language should be very close to what a compiler of that form
can do.  This eventually killed Pascal.

				John Nagle