Is python not good enough?

[John Nagle]

Nobody wrote:
> On Fri, 15 Jan 2010 12:34:17 -0800, John Nagle wrote:
> 
>>     Actually, no.  It's quite possible to make a Python implementation that
>> runs fast.  It's just that CPython, a naive interpreter, is too primitive
>> to do it.  I was really hoping that Google would put somebody good at
>> compilers in charge of Python and bring it up to production speed.
>>
>>     Look at Shed Skin, a hard-code compiler for Python
> 
> A hard-code compiler for the subset of Python which can easily be compiled.
> 
> Shed Skin has so many restrictions that it isn't really accurate to
> describe the language which it supports as "Python".
> 
> Hardly any real-world Python code can be compiled with Shed Skin. Some of
> it could be changed without too much effort, although most of that is the
> kind of code which wouldn't look any different if it was implemented in
> C++ or Java.
> 
> The monomorphism restriction is likely to be particularly onerous: the
> type of a variable must be known at compile time; instances of subclasses
> are allowed, but you can only call methods which are defined in the
> compile-time class.
> 
> If you're writing code which makes extensive use of Python's dynamicity,
> making it work with Shed Skin would require as much effort as re-writing
> it in e.g. Java, and would largely defeat the point of using Python in the
> first place.
> 
> http://shedskin.googlecode.com/files/shedskin-tutorial-0.3.html
> 
> If you want a language to have comparable performance to C++ or Java, you
> have to allow some things to be fixed at compile-time. There's a reason
> why C++ and Java support both virtual and non-virtual ("final") methods.

     My point is that Python is a good language held back by a bad
implementation.  Python has gotten further with a declaration-free syntax
than any other language.  BASIC and JavaScript started out declaration-free,
and declarations had to be retrofitted.  Python has survived without them.
(Yes, there are hokey extensions like Psyco declarations and "decorators",
but both are marginal concepts.)

     The key to hard-compiling Python is that you have to compile the
whole program, not individual modules.  You can't tell how an individual
module will be used until you've seen its callers.  If the compiler
looks at the whole program at once, type inference has a good chance of
disambiguating most type issues.

     If you can see the whole program at once, most dynamism can be detected.
What's really needed is to detect the most common case, where objects don't
have unexpected dynamism and can be implemented as hard structures.

					John Nagle