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. -- http://mail.python.org/mailman/listinfo/python-list