merits of Lisp vs Python

[Bill Atkins]

Re: merits of Lisp vs Python

greg <greg@cosc.cant erbury.ac.nzwri tes:

>A compiler shifts a lot of decisions that an
>interpreter would have to make at runtime to compile-time. There is
>no reason a dynamic language can't enjoy this efficiency.

>
I'm not saying that it's impossible to compile
Python, only that's there's a lot more to it than
just macro expansion. The OP was saying something
like "If you added macros, you might get a compiler
for free", which is clearly far from true.

Yeah, my mistake - I simply glided right past the "just by macro
expansion." Oops. :)

>Despite its dynamism, Lisp is quite compilable.

>
Please correct me if I'm wrong, but as I understand,
getting efficient code out of a Lisp compiler requires
putting type declarations into the source.
>
If you put the same declarations into a piece of
Python code, then of course it would be fairly
straightforward to compile it efficiently. But it
wouldn't really be dynamic Python any more.

Type declarations can squeeze out extra efficiency, but vanilla Lisp
without type declarations will still beat Python, both because the
language is designed to compile well and because compilers for Lisp
are generally very mature. So it is not the case that type
declarations are the only thing that make Lisp efficient.

[Bill Atkins]

Re: merits of Lisp vs Python

greg <greg@cosc.cant erbury.ac.nzwri tes:

>>>Having edited both Lisp and Python code fairly
>>>extensivel y,

>>
>How extensively?

>
Enough to know what I'm talking about. Tens
of thousands of lines of Lisp and Scheme, and
hundreds of thousands of lines of Python, I
would estimate.
>
Seeing as you asked, how much Python code have
you or Ken edited?

To be honest, very little Python code. But I have manually indented
and rearranged enough code in other line-based languages to appreciate
the convenience of s-expression-based commands.

[Bill Atkins]

Re: merits of Lisp vs Python

Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:

Pascal Costanza <pc@p-cos.netwrites:

>May you have tried the wrong Lisp dialects so far:
>>
>(loop for i from 2 to 10 by 2
> do (print i))

>
The loop language is so complicated and confusing that I never
bothered trying to learn it. I always used simpler primitives to
write loops and it was always enough.

I think you're missing out. If you don't find LOOP appealing, look
for the ITERATE package. ITERATE is a more Lispy, more extensible
replacement for LOOP.

>This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
>you should implement this using recursion, but you really don't have
>to. ;)

>
You can't really use that much recursion in Lisp because of the lack
of guaranteed TCO. I think that makes it reasonable to say that
Scheme is a functional language but Lisp is not. ("Functional " = it's
reasonable to code in a style where the only way to connect variables
to values is lambda binding (maybe through syntax sugar), so all loops
are implemented with recursion).

You should be pragmatic about this - I have never used a CL
implementation that didn't do TCO optimization (indeed, are there
any?). Although the standard doesn't require it, I treat it as a de
facto requirement and don't worry too much about it.

[Bill Atkins]

Re: merits of Lisp vs Python

I V <wrongbad@gmail .comwrites:

On Sun, 10 Dec 2006 03:18:07 -0500, Bill Atkins wrote:

>We're not counting lines here, you goon. We're talking about how
>expressive constructs are and how closely they match your concept of
>what you want to do. The conditional example is lower-level; you're
>talking to the interpreter instead of saying what you want to achieve.
>You're having to repeat things because that's what the language asks
>of you, instead of describing in a higher-level way what you're
>actually doing.

>
To be a little provocative, I wonder if the idea that you're "talking to
the interpreter" doesn't apply more to lisp than to python; you can have
any syntax you like, as long as it looks like an AST.

Uhhh?

One of the things I've always found off-putting about lisp as that all the
syntax looks the same. In Algol-derived languages, each syntactic
construct has a fairly distinctive appearance, so when, for instance, I
encounter a for loop, I can quickly recognize that that's what it is, and
bracket out the "scaffoldin g" and pick out the details that interest me.
With lisp, I can't do that, I have to read through the sexp, decide on
what syntax it is, and then remind myself where to look for the relevant
specific details.

"Decide on what syntax it is"? Examples?

Now, this might well be just due to my comparative lack of familiarity
with lisp; I'd be interested to hear if you lisp people find different
lisp constructs as visually distinctive as constructs in python (or other
similar languages). But I think what people are getting at when they
complain about "all the brackets" in lisp may actually be this issue of
a visual distinction between different constructs (this is also a reason
why having a limited number of syntactic constructs can be helpful - there
are a probably a limited number of stereotypical layouts a programmer can
keep in their mind at once).

We rely on indentation for readability just as you guys do. Lisp
programs are not chaotic arrangements of parentheses and symbols; code
structure is made apparent through indentation.

(Why are people from c.l.p calling parentheses "brackets"? )

[Robert Brown]

Re: merits of Lisp vs Python

Paul Rubin <http://phr.cx@NOSPAM.i nvalidwrites:

Robert Brown <bbrown@speakea sy.netwrites:

>Luckily, Willem Broekema has written a Python to Lisp compiler called
>clpython that can be consulted to answer questions like these.
>>
> http://trac.common-lisp.net/clpython/

>
Does this count as a "children of a lesser Python"? How does clpython
implement Python's immutable strings, for example?
>
http://dirtsimple.org/2005/10/childr...er-python.html

I think CLPython is in the "children of a lesser Python" category, on the
grounds that it doesn't implement the complete language and there's no
obvious way to reuse the C packages that make CPython so useful. However,
the other distinguishing feature of the "children" category is bending
semantics to gain speed. CLPython doesn't appear to be doing much of this.
The author says it runs at about the same speed as CPython.

Python strings are implemented in CLPython as instances of a CLOS class, not
as raw Common Lisp strings, so they appear to be immutable.

[JShrager@gmail.com]

Re: merits of Lisp vs Python

greg <greg@cosc.cant erbury.ac.nzwri tes:

>

A compiler shifts a lot of decisions that an
interpreter would have to make at runtime to compile-time. There is
no reason a dynamic language can't enjoy this efficiency.

I'm not saying that it's impossible to compile
Python, only that's there's a lot more to it than
just macro expansion. The OP was saying something
like "If you added macros, you might get a compiler
for free", which is clearly far from true.

Speaking as the OP, let's see what the OP really said:

>... compilers are GREATLY facilitated by having a
macro facility because (at first blush) all you need to do is to
macro-expand down to something you know how to turn into code.
This isn't the only, nor perhaps the best way to get a compiler, but it's
a step in that direction. Later on you can learn the other great
features offered by homogeneous syntax, like being able to write code
walkers, which help improve over the "first blush" compiler....

So, "If you added macros, you might get a compiler for free" is not a
fair paraphrase of this.

(Another way, BTW, that macros improve efficiency is by replacing
function calls with in-line code. Another cheap improvement facilitated
by macros.)

[mystilleef@gmail.com]

Re: merits of Lisp vs Python


Paddy wrote:

Robert Uhl wrote:
>

Steven D'Aprano <steve@REMOVE.T HIS.cybersource .com.auwrites:

>
Speaking as somebody who programmed in FORTH for a while, that doesn't
impress me much. Prefix/postfix notation is, generally speaking, more
of a pain in the rear end than it is worth, even if it saves you a
tiny bit of thought when pasting code.

Of course, you use prefix notation all the time in Python:

for x in range(0,len(y)) :
dosomething(x)

>
In Python, most containers are directly iterable so we are much more
likely to arrange our program to use:
for a in y:
dosomethingwith (a)
>
-Paddy.

Or the more succinct Python (FP) construct:

map(dosomething , y)

[Kaz Kylheku]

Re: merits of Lisp vs Python

Bill Atkins wrote:

(Why are people from c.l.p calling parentheses "brackets"? )

Because that's what they are often called outside of the various
literate fields.

[Raffael Cavallaro]

Re: merits of Lisp vs Python

On 2006-12-12 19:18:10 -0500, "George Sakkis" <george.sakkis@ gmail.comsaid:

If you mistakenly select an extra parenthesis or omit one, it's
the same thing.

Because you can't mistakenly select an extra paren or omit one in a
lisp-aware editor. Whether its a commercial lisp IDE or emacs, you
don't manually select s-expressions. You put your cursor/point at one
paren and you tell the editor - with a keystroke or a mouse click - to
find the matching paren and select everything contained between the two.

[Lars Brinkhoff]

Re: merits of Lisp vs Python

Bill Atkins <atkinw@rpi.edu writes:

the macro is just a friendlier syntax for expressing an idea.

I like that phrase!

[Paul Rubin]

Re: merits of Lisp vs Python

Neil Cerutti <horpner@yahoo. comwrites:

Is the above 'duck-typing' idiom considered very useful to a
Lisper? It seems logical to me that duck-typing works best in an
environment where it is ubiquitous. If users have to implement
accessors specifically to use your library, it is not as good as
if they had already implemented one as a matter of routine.

It's a little more complicated than that, the classes involved have to
have special interfaces to tell setf/getf what to do, sort of a
compile time equivalent of __setattr__/__getattr__ if I remember right.

[Paul Rubin]

Re: merits of Lisp vs Python

"JShrager@gmail .com" <JShrager@gmail .comwrites:

Let us note that it's not FSF that gives this stuff away for free -- or
if it is them proximally, it is not them ultimately -- ultimately it's
the engineers who did all that work that gave it away for free.

When I worked there, they paid me ;-)

[Paul Rubin]

Re: merits of Lisp vs Python

Bill Atkins <atkinw@rpi.edu writes:

You should be pragmatic about this - I have never used a CL
implementation that didn't do TCO optimization (indeed, are there
any?). Although the standard doesn't require it, I treat it as a de
facto requirement and don't worry too much about it.

I have to confess that most of the Lisp code I've written were on
simpler dialects that didn't have TCO. But I'm not sure if the CL
implementations I've used (KCL back in the day, and CLISP a little
bit) had it either.

[Juan R.]

Re: merits of Lisp vs Python

Kay Schluehr wrote:

>
You mean a universal language adapter? I guess this is always possible
using alpha conversion but I don't believe this leads to theoretical or
practical interesting solutions but is just a limit concept.

Not familiarized with you terminology. I think that i would call that a
universal language composer.

I mean if there exists some theoretical limitation to composionality of
two directly collapsing languages (G1, T1) and (G2, T2) via a
unambiguous modification (e.g. 'renaming') to a third one (G2', T2'),
unknown to me. I mean some theoretical limitation in the sense of known
theoretical limitations to proving theorems in closed formal systems.
After all proving a formal theorem is not very different from
enhacement of a language.

The practical problem with composing enhancements is that any two
extensions L1, L2 share a lot of rules and rely on their structure.
What if they don't just extend their host language L0 conservatively
but also redefine rules of L0? This is not just a theoretical problem
but it happens quite naturally if you want to adapt an extension
developed for Python 2.4 for working with Python 2.5. Here Python 2.5
is considered as just another particular extension. Obviously Py3K will
become an interesting testcase for all kinds of syntactical and
semantical transformations .

I would consider redefined-L0 to be L0'. I think that a concept of
namespaces could be also used for versioning-like conflicts:
L0v24:foo(), L0v25:foo(). The problem is that both versions may be
stored and managed during initial period of time. But in the long run
old libraries, extensions... would be updated to the new version.

[Timofei Shatrov]

Re: merits of Lisp vs Python

On Wed, 13 Dec 2006 16:07:01 +1300, greg <greg@cosc.cant erbury.ac.nztri ed to
confuse everyone with this message:

>Robert Uhl wrote:
>

>o Symbols
>>
>In Lisp, a symbol is essentially a hashed string;

>
>Are you aware that strings can be interned in Python?
>Furthermore, any string literal in the source that
>is a syntactically valid identifier is automatically
>interned, and you can intern any string explicitly
>if you need. This gives you exactly the same
>capabilities as symbols in Lisp.

Are you aware that you hardly know any Lisp yet make such bold and unfounded
claims? Unless interning a string somehow gives it a property list, slot value
and function value it doesn't give you the same capabilities.

--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________ |