Python vs. Lisp -- please explain

[Kay Schluehr]

Re: Python vs. Lisp -- please explain


Roy Smith wrote:[color=blue]
> DH <no@spam.com> wrote:[color=green]
> > -python has true closures (although nothing like ruby's blocks)[/color]
>
> What is a "true closure"? Or, maybe what I'm asking is what kind of
> closure wouldn't be a true closure? Is there some kind of ersatz closure
> other language try to pass off, in violation of truth in closure laws?[/color]

A "true closure" is what Python doesn't have ;)

If you enclose variables in a certain functional context in which they
are not defined they are turned into something immutable in Python.
Assigning a value to the same name creates a new object instead of
rebinding the old name. This "readonly" semantics confuses many
programmers coming from other languages at least all Lispers/Schemers
I've talked to. Python does not provide a rebinding operator for free
variables by BDFL decision.

Kay

[Terry Hancock]

Re: Python vs. Lisp -- please explain

On Sun, 19 Feb 2006 00:54:22 -0500
"Terry Reedy" <tjreedy@udel.e du> wrote:[color=blue]
> In order to be that fast, some of the dynamism of
> intepreted Lisp must be given up. In particular object
> code is not list data. Python with type-dynamism
> eliminated can also be translated to decent C/C++ and then
> compiled. See PyRex and Weave. There is also Psyco,
> which I believe translates directly to machine code.[/color]

I thought it was just "Pyrex" as in "Still as clear as
glass, but can really take the heat.". ;-)

Now it's a small snake / dog chimera. Eeeww. You've ruined
it for me.
[color=blue][color=green]
> > 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?[/color][/color]

Otherwise, I think this has been well-answered -- if you
give up the same features, you can get the same speed. But
who cares?

Those things only matter in a very limited domain, and real
programs can use Python for logic and Python extension
modules for things that truly need optimization. If you use
Pyrex, you can even still pretend you're programming in
Python when you write those extensions. I'm sure that's why
some 3D libraries have opted to write the fast code in Pyrex
instead of C (even though either is possible).

--
Terry Hancock (hancock@Anansi Spaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Bruno Desthuilliers]

Re: Python vs. Lisp -- please explain

DH a écrit :
(snip)[color=blue]
>
> It is by design. Python is dynamically typed. It is essentially an
> interpreted scripting language like javascript or ruby or perl,[/color]

It's not a "scripting" language, and it's not interpreted.
[color=blue]
> although
> python fans will be quick to tell you python is compiled to byte code.[/color]

CQFD.

[Alexander Schmolck]

Re: Python vs. Lisp -- please explain

63q2o4i02@sneak email.com writes:
[color=blue]
> Hi, I've been thinking about Python vs. Lisp. I've been learning
> Python the past few months and like it very much. A few years ago I
> had an AI class where we had to use Lisp, and I absolutely hated it,
> having learned C++ a few years prior. They didn't teach Lisp at all
> and instead expected us to learn on our own. I wasn't aware I had to
> uproot my thought process to "get" it and wound up feeling like a
> moron.
>
> In learning Python I've read more about Lisp than when I was actually
> trying to learn it, and it seems that the two languages have lots of
> similarities:
>
> http://www.norvig.com/python-lisp.html
>
> 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?[/color]

Nothing. Given a sufficiently smart implementation any language can be as fast
as any other -- it might just be a billion times harder to write that
implementation for language A than for language B.
[color=blue]
> 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?[/color]

I think if you're looking for one single reason, it is presumably that (IIRC)
python was designed on the erronous assumption that dynamically typed
languages have to be slow (and are unsuitable for real applications anyway)
wheras common lisp wasn't. Furthermore the people involved in common lisp were
much more knowledgeable and experienced in things like compiler design and had
a long history of similar languages and various implementations to build upon.

As common lisp and scheme demonstrate you can have high level of dynamism (and
in a number of things both are more dynamic than python) and still get very
good performance (in some cases close to or better than C). But both these
languages have been designed with compiler writers and the generation of fast
code in mind, so they made design decisions to ease writing fast lisp
compilers and programs.

For example:

- python classes (and to some extent modules) are essentially dictionaries
that you can modify and customize more or less at will at run-time and that
behave interchangeably in many respects. I'm sure that presents several
optimization headaches.

By contrast if the common lisp compiler sees the symbol CL:LIST (usually
written just LIST, because the CL package is imported by default) it can
safely assume that it refers to the builtin LIST function, because you're
not allowed to rebind the function value of functions in the CL package.
Python can assume no such thing if it comes across ``list`` -- for all it
knows it might as well be the number 42. Also the package and class system
are completely separate and although common lisp's OO system is rather more
powerful than python's it has been designed to be implementable efficiently.

- in python almost everything has to happen at run-time, whereas in common
lisp you can do things at compile time, load time or run-time e.g:

- common lisp has a mechanism for making compiler declarations (so you can
tell the compiler to inline a function, or the type of a variable, or to
optimize something for speed and not for space etc.)

- common lisp has macros (proper ones, not C style) which allow you to build
efficient abstractions

- common lisp has compiler macros. This sort of means that you can write your
own compiler optimizations for your functions (i.e. if you know that your
expensive FOO function is indempotent you could arrange for all calls of the
form (FOO (FOO A)) to be replaced with simply A, in a similar way as an
optimizing compiler might replace (a+b+c+d)*0 with 0).

What's far more interesting to me, however, is that I think there a good
reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code.

If you know the language to be dog slow any way, you're much less likely to
waste your time (and that of future maintainers) on the pointless
microoptimizati ons that geeks so love. Also, since only builtins have
reasonable performance there's added motiviation to become very familiar with
the available builtins (and standard libarary) and far less temptation to roll
one's own version of say dict.setdefault (even if it it sucks). The fact that
non-standard library code is inherently somewhat inferior (because it will
either be written in python and slow or written in C and a pain to install)
adds further incentive to attempt community wide standardization .

I think it's not unreasonable to speculate that all this decreases production,
maintenance and reuse costs of python code considerably, so much in fact that
python's very slowness represents part of its competetive edge over languages
that are in some ways better engineered and more capable.

So ironically, some share of python's success might actually be due to
ignorance on Guido's part (of course python in most respects is a marvellously
well designed language that to my mind places Guido at least on par with the
designers of any contemporary language; I'm just intrigued by the possiblity
that had he known as much about performance issues in very dynamic languages
as say some of the lisp and self people, python might have turned out to be a
faster albeit less popular and productive language).

'as

[Alexander Schmolck]

Re: Python vs. Lisp -- please explain

Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:
[color=blue]
> DH a écrit :
> (snip)[color=green]
> > It is by design. Python is dynamically typed. It is essentially an
> > interpreted scripting language like javascript or ruby or perl,[/color]
>
>
> It's not a "scripting" language, and it's not interpreted.[/color]

Of course it is. What do you think happens to the bytecode? And if python
isn't a scripting language, then what on earth is?

You might want to argue about whether scriping language is a meaningful and
useful concept, but it's really hard to see how you could talk about "scripting
languages" without including python.

'as

[63q2o4i02@sneakemail.com]

Re: Python vs. Lisp -- please explain

Cool, thank you. That's the answer I was looking for :)

[Fredrik Lundh]

Re: Python vs. Lisp -- please explain

Alexander Schmolck wrote:
[color=blue]
> What's far more interesting to me, however, is that I think there a good
> reasons to suspect python's slowness is more of a feature than a flaw: I'd not
> be suprised if on the whole it greatly increases programmer productivity and
> results in clearer and more uniform code.[/color]
[color=blue]
> So ironically, some share of python's success might actually be due to
> ignorance on Guido's part[/color]

it didn't, for even a millisecond, strike you that maybe, just maybe, the
"make it as dynamic as we possibly can" choice was made on purpose ?

</F>

[63q2o4i02@sneakemail.com]

Re: Python vs. Lisp -- please explain

Great, thanks for a very complete answer.
michael

[Fredrik Lundh]

Re: Python vs. Lisp -- please explain

Alexander Schmolck wrote:
[color=blue]
> You might want to argue about whether scriping language is a meaningful and
> useful concept, but it's really hard to see how you could talk about "scripting
> languages" without including python.[/color]

define "scripting language".

the only even remotely formal definition I've ever seen is "language with
designed to script an existing application, with limited support for handling
its own state". Early Tcl and JavaScript are scripting languages, Python
is not.

</F>

[Bruno Desthuilliers]

Re: Python vs. Lisp -- please explain

Alexander Schmolck a écrit :[color=blue]
> Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:
>
>[color=green]
>>DH a écrit :
>>(snip)
>>[color=darkred]
>>>It is by design. Python is dynamically typed. It is essentially an
>>>interprete d scripting language like javascript or ruby or perl,[/color]
>>
>>
>>It's not a "scripting" language, and it's not interpreted.[/color]
>
>
> Of course it is. What do you think happens to the bytecode?[/color]

Ok, then what do you think happens to 'machine' code ?

"interprete d" usually means "no compilation, all parsing etc redone at
each execution", which is not the case with a bytecode/vm based
implementation.
[color=blue]
> And if python
> isn't a scripting language, then what on earth is?[/color]

bash is a scripting language for *n*x systems. javascript is a scripting
language for web browsers. VBScript is a scripting language for MS
applications.
[color=blue]
> You might want to argue about whether scriping language is a meaningful and
> useful concept,[/color]

A scripting languagee is a language whose main purpose is to be embbeded
in an application to provide the user a way of programmaticaly automate
some tedious tasks.

Now you could of course argue about what is an application...
[color=blue]
> but it's really hard to see how you could talk about "scripting
> languages" without including python.[/color]

Ho, really ? How many applications using Python as scripting language ?
And how many applications written in Python ?

Python *can* be used as a scripting language (and is not too bad at it),
but it *is* not a scripting language.

[Ed Jensen]

Re: Python vs. Lisp -- please explain

Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> wrote:[color=blue]
> It's not a "scripting" language, and it's not interpreted.[/color]

http://www.python.org/doc/faq/general.html#what-is-python

"Python is an interpreted, interactive, object-oriented programming
language."

[63q2o4i02@sneakemail.com]

Re: Python vs. Lisp -- please explain

Great, thank you and everyone for this nice discussion.

Michael

[Torsten Bronger]

Re: Python vs. Lisp -- please explain

Hallöchen!

Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:
[color=blue]
> Alexander Schmolck a écrit :
>[color=green]
>> Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:
>>[color=darkred]
>>> [...]
>>>
>>> It's not a "scripting" language, and it's not interpreted.[/color]
>>
>> Of course it is. What do you think happens to the bytecode?[/color]
>
> Ok, then what do you think happens to 'machine' code ?
>
> "interprete d" usually means "no compilation, all parsing etc
> redone at each execution", which is not the case with a
> bytecode/vm based implementation.[/color]

That sounds like an implementation feature rather than a language
feature. Besides, it's not a very sensible distinction in my
opinion. Much better is to think about the structure of the
interpreting machine. I'm not a CS person (only a physicist) but if
you *need* a bytecode interpreter on top of the CPU interpretation,
it's an interpreted language to me.

I've had such a discussion about TeX already, and my personal
conclusion was that you can defend almost any opinion in that area.
However, one should ensure that the definitions make a pragmatic and
useful distinction.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Paul Boddie]

Re: Python vs. Lisp -- please explain

Torsten Bronger wrote:[color=blue]
> Hallöchen!
>
> Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:[color=green]
> >
> > Ok, then what do you think happens to 'machine' code ?
> >
> > "interprete d" usually means "no compilation, all parsing etc
> > redone at each execution", which is not the case with a
> > bytecode/vm based implementation.[/color][/color]

Such criteria sound more like those which would distinguish interactive
languages from others.
[color=blue]
> That sounds like an implementation feature rather than a language
> feature. Besides, it's not a very sensible distinction in my
> opinion. Much better is to think about the structure of the
> interpreting machine.[/color]

And it's even better to think about the nature of the machine...
[color=blue]
> I'm not a CS person (only a physicist) but if
> you *need* a bytecode interpreter on top of the CPU interpretation,
> it's an interpreted language to me.[/color]

Yet one could potentially have that bytecode interpreter in hardware.
What typically prevents this is the potential difficulty of realising
complicated software designs in reasonably priced hardware, thus
introducing the nature of the machine: how complicated the instructions
are, what additional support would be required for implementing those
instructions, and so on. Low-level or systems programming languages are
compilable to instructions which are convenient to implement in
hardware and require little additional support: concepts such as stacks
(for various purposes) are supported by machine instructions and
registers, for example, whereas more advanced memory management is left
to software running on top of the virtual machine (although I imagine
that various Lisp machines did some interesting things in this domain).
[color=blue]
> I've had such a discussion about TeX already, and my personal
> conclusion was that you can defend almost any opinion in that area.
> However, one should ensure that the definitions make a pragmatic and
> useful distinction.[/color]

Agreed. The CPython virtual machine consists of "complicate d"
instructions: that is, some of those instructions may involve
non-trivial amounts of work and may be integrated with other subsystems
that can realistically only be implemented in software. Even virtual
machines like that of the Java platform have moderately high-level
instructions, resulting in various "Java optimised" hardware
implementations not attempting to provide a complete coverage of all
the available instructions (as far as I am aware).

I'm not sure why people get all defensive about Python's
interpreted/scripting designation or about the details of the CPython
implementation, especially considering that the virtual machine
technology in use has been around for a decade and a half, and that
various projects have been experimenting with alternatives.

Paul

[Steven D'Aprano]

Re: Python vs. Lisp -- please explain

On Sun, 19 Feb 2006 19:26:20 +0000, Alexander Schmolck wrote:
[color=blue]
> Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:
>[color=green]
>> DH a écrit :
>> (snip)[color=darkred]
>> > It is by design. Python is dynamically typed. It is essentially an
>> > interpreted scripting language like javascript or ruby or perl,[/color]
>>
>>
>> It's not a "scripting" language, and it's not interpreted.[/color]
>
> Of course it is. What do you think happens to the bytecode?[/color]

By that logic, all languages are interpreted. What do you think happens to
the machinecode?


--
Steven.