Python vs. Lisp -- please explain

[Steven D'Aprano]

On Sat, 18 Feb 2006 23:35:27 -0600, DH wrote:

> > I'm wondering if someone can explain to me please what it is about
> > Python that is so different from Lisp that it can't be compiled into
> > something as fast as compiled Lisp?  From this above website and
> > others, I've learned that compiled Lisp can be nearly as fast as
> > C/C++, so I don't understand why Python can't also eventually be as
> > efficient? Is there some *specific* basic reason it's tough?  Or is it
> > that this type of problem in general is tough, and Lisp has 40+ years
> > vs Python's ~15 years?
>
> It is by design. 

You make it sound like Guido sat down to design a language and
deliberately put "Slow" first on his list of desired attributes. Why such
a negative tone to your post?

Python is not slow by design. Python is dynamically typed by design, and
relative slowness is the trade-off that has to be made to give dynamic
types.

The Python developers have also done marvels at speeding up Python since
the early days, with the ultimate aim of the PyPy project to make Python
as fast as C, if not faster. In the meantime, the question people should
be asking isn't "Is Python fast?" but "Is Python fast enough?".

> Python is dynamically typed.  It is essentially an 
> interpreted scripting language like javascript or ruby or perl, although 
> python fans will be quick to tell you python is compiled to byte code. 

You make it sound like Python fans are bending the truth. That Python
compiles to byte-code is an objective fact which can be learnt by anyone,
not just "Python fans". In that regard, Python is closer to Java than Perl
or Javascript. Only without the slow startup time of the JRE.


> They'll also be quick to tell you:
> -python has true closures (although nothing like ruby's blocks)

They're also nothing like Pascal's with statements either. Why make the
comparison with Ruby's blocks when the original poster is comparing Python
to Lisp?


> -is beginner friendly (despite being case sensitive and 3/4==0, for
> example)

Case sensitivity isn't beginner unfriendly. It is sloppy thinker
unfriendly. Whether you have been programming for thirty days or thirty
years, if you don't know the difference between foo and FOO you have a
serious problem. As they say, case is the difference between "I helped my
Uncle Jack off a horse" and "I helped my uncle jack off a horse."

As for the difference between integer division and true division, yes,
that was an unfortunate design decision. Fortunately it is being rectified
in the least painful way possible.


> -is not, in fact, slow at all (despite benchmarks as you noted showing
> otherwise).

I've asked this question before, but obviously there is a particular
mindset that just doesn't get it. Slow compared to what? Slow to do what?

For those who don't understand the difference between "faster" and "fast
enough", perhaps a simple analogy will bring enlightenment. For most
people, under most circumstances, an ordinary car (top speed around 75
mph or so) is fast enough, more convenient, and much better value for
money than the significantly faster F-15 fighter plane (top speed around
1850 mph).

On modern hardware, for the vast majority of applications, the execution
speed of the language is not the limiting factor. I/O or the algorithm is
usually the limiting factor. "Change your algorithm" is often better
advice than "change your language". 

That's not to say that Python isn't objectively SLOWER (note the
relative term, not absolute) than some languages. But execution speed is
rarely the most important factor in choice of a language.

For those tasks that language speed is a limiting factor (say, writing
devise drivers, operating systems, and similar), Python may not be fast
enough. But they are the exception rather than the rule, and there are no
shortage of ways around that: Psycho, C extensions, or even "choose
another language". 



-- 
Steven.