merits of Lisp vs Python

[Mark Tarver]

How do you compare Python to Lisp? What specific advantages do you
think that one has over the other?

Note I'm not a Python person and I have no axes to grind here. This is
just a question for my general education.

Mark

[Kay Schluehr]

Marc 'BlackJack' Rintsch schrieb:

In <11************ **********@n67g 2000cwd.googleg roups.com>, Kay Schluehr
wrote:

Once an easy to use metaprogramming system could be done for Python it
could be ported with some adaptions to other languages with more
"complicate d syntax" ( non LL(1) parsable ).

FYI: Here's how Nemerle does macros: http://nemerle.org/Macros

I guess you can't really transform Nemerle into a completely different
language, but it is at least interesting to see such a feature in language
with a more complex syntax than Lisp.

Ciao,
Marc 'BlackJack' Rintsch

Hi Mark, there are quite a lot of meta programming systems ( MPS ) for
non Lispy languages ( O'Caml, Haskell, Java of course and also Dylan
as a member of the "Lisp family" with non homogenous syntax ). I hope I
will find time in the new year to review and compare them to the
grammar based approach I described in the grandparent post and follow
myself with "EasyExtend " for Python - which is *radical* and somewhat
in between a language specific MPS and Lex/Yacc. The idea to separate
the MPS from the host language but providing a multi-language framework
is somewhat complementary to that of PyPy that is a framework that
supports several backends for one language.

[Paul Rubin]

Espen Vestre <es***@vestre.n etwrites:

If you say foo.frob() in Python, that's supposed to look up 'frob' in
a dictionary hanging off of foo. You can modify the contents of this
dictionary any time you want.

You can redefine CLOS methods at run time any time you like, so this
doesn't make Python more /dynamic/ than CLOS. Maybe you should replace
"more dynamic" with "less managable", if that's what you mean?

Can you redefine CLOS methods without calling CLOS functions that tell
the object system what to expect (so it can do things like update the
MRO cache)? I.e. can you redefine them by poking some random
dictionary? You can in Python. I don't claim that's a good thing.

[Paul Rubin]

Marc 'BlackJack' Rintsch <bj****@gmx.net writes:

FYI: Here's how Nemerle does macros: http://nemerle.org/Macros

I guess you can't really transform Nemerle into a completely different
language, but it is at least interesting to see such a feature in language
with a more complex syntax than Lisp.

Nobody seems to concerned that Haskell lacks macros. What's up with that?

[sjdevnull]

Bill Atkins wrote:

On the plus side, Python makes less demands on the
capabilities of the editor. All you really need
is block-shifting commands. Bracket matching is
handy for expressions but not vital, and you
certainly don't need bracket-based auto-indenting.

Oh, please. So we should restrict the power of the languages we
choose just to make sure that our code can be edited in Notepad?

In the real world, it's a non-negligible consideration, IMO. I find
myself needing to write code on machines that aren't my usual dev
machine at least a couple of times a year, and not having to install a
particular editor is nice (especially in terms of keeping the
modifications to someone else's machine down to a minimum).

It's hardly a dealbreaker for a particular language, but it's far from
worthless.

[Fred Gilham]

Paul Rubin <http://ph****@NOSPAM.i nvalidwrites:

André Thieme <ad************ *************** *@justmail.dewr ites:

>Instead of function = memoize(functio n)
one could just say: memoize(functio n).

In Python you'd say

@memoize
def function(): ...

But in Lisp you'd write the function, say, "Damn, I need to memoize
this sucker," and evaluate

(memoize 'function)

and the function would be memoized.

I suspect you could even do this "while the program was running" from
something like SLIME. Basically the memoize macro changes the
function cell of the symbol, so from that point all the calls to the
function would be to the memoized version.

--
Fred Gilham gi****@csl.sri. com
One of the authors of the Daniel Bell volume says, in horror and
astonishment, that the radical right intends to repeal the twentieth
century. Heaven forfend! Who would want to repeal the twentieth
century, the century of horror, the century of collectivism, the
century of mass destruction and genocide, who would want to repeal
that! -- Murray Rothbard

[JShrager]

Kay Schluehr wrote:

[Interesting and useful analysis of issues in language homogenization
snipped.]

You might even get a compiler out of the deal, at
a pretty low cost, too! If you get macros, and get a compiler, I'm
pretty sure that you will have no problem winning over the Lisp
community, who would LOVE to have your extensive libraries, and that
you will probably be able to maintain and improve your flagging
position wrt Ruby (which, according to Matz, is more-or-less just Lisp
w/o macros.)

Just a moment ago you called programmers of other languages "flies"
which I found annoying and now you offer LOVE in big letters?

Since everyone seems to have taken offence and this remark, let me
hereby apologize for the unintended implication. For the record, I
quote myself in full:

Common) Lisp is the only industrial strength language with both pure
compositionalit y and a real compiler. What Python has is stupid slogans
("It fits your brain." "Only one way to do things.") and an infinite
community of flies that, for some inexplicable reason, believe these
stupid slogns. These flies are, however, quite useful because they
produce infinite numbers of random libraries, some of which end up
being useful. But consider: Tcl replaced Csh, Perl replaced Tcl, Python
is rapidly replacing Perl, and Ruby is simultaneously and even more
rapidly replacing Python. Each is closer to Lisp than the last; the
world is returning to Lisp and is dragging the flies with it.
Eventually the flies will descend upon Lisp itself and will bring with
them their infinite number of random libraries, and then things will be
where they should have been 20 years ago, but got sidetracked by Tcl
and other line noise.

I've already admitted that this was both a poor choice of words and, as
pointed out by Carl, an ad hominem argument. However, if you read the
whole thing you'll see that I'm really railing against the silly "It
fits your brain" and "Only one way to do things" marketing hype, and
programmers who seem to swallow and repeat it, not programmers in
general, nor even python programmers in general. In the last part it
say: "Eventually the flies will descend upon Lisp itself and will bring
with them their infinite number of random libraries, ..." Note that I'm
looking forward to this! So, although "flies" was a poor choice of
words, for which I whole heartedly apologize to those who might have
taken offence (and I do understand the reading and why you might take
offense at this given the context!), what I meant to say was: "Hey, all
you busy little pythonistas creating a million interesting libraries
(and some not, but that's fine) come over here and help do that for our
language too!"

Maybe "beavers" would have been a better animal. Mea Culpa!

Regardless, the topic of the rest our conversation -- how to put macros
and a compiler into Python -- stands as an interesting possibility
because it would enable us to come to you rather than the other way
around -- I'd be happy either way.

[Michael Livshin]

Paul Rubin <http://ph****@NOSPAM.i nvalidwrites:

Nobody seems to concerned that Haskell lacks macros. What's up with
that?

Haskell is lazy, so it doesn't need macros (well, it would be more
accurate to say that by not evaluating function arguments until they
are needed it makes many of the usual macro usecases moot).

lazyness has a nontrivial cost, however, both runtime and cognitive.

hoping he's not answering a rhetorical question,
--m

--
I'm on a seafood diet -- I see food and I eat it. -- anonymous

[André Thieme]

Steven D'Aprano schrieb:

On Sat, 09 Dec 2006 22:41:12 -0500, Ken Tilton wrote:

>>I know that. It was more of a rhetorical question -- Lispers are either
trying to emphasis the radical nature of what you can do with macros, or
understate it and make them seem just like functions.

Yep, both. The first is rare. CLOS is one, my Cells (ported this summer
to PyCells as part of SoC 2006) is another. The latter is the norm.

If macros' advanced usage is rare, and most usage of macros could be done
by functions, then maybe that explains why so many coders don't miss them.

You can't do with functions what you can do with macros.
Macros are just parameterized code. A template. Compare it with HTML
templates

<html>
<body>
Your name is <?py print name.getUser(lo ggedInUser) ?>.<br>
Welcome!
</body>
</html>

The page that arrives the user does not include any template code anymore.
Just plain html.
Same happens with Lisp macros. After compilation (preprocessing the
html template by Zope) there are no macros left.
So in the end you have just some Lisp functions. So one does not *need*
macros, in the sense of turing completeness. But at the same time one
can meet lots of places where templates can make sense and where they
are used. Even the programmers of Zope thought of them as a plus for
productivity.
In Lisp you don't always design one huge macro after the other, which
really saves a lot of code. Many macros save one or two short lines of
code. This might sound not important. But it sums up.
Somewhere else I asked you to imagine how you would like it if you had
to call doodleBoodle() before each if-statement to make it work. That
would be plain stupid if you had to. So if you meet something in code
that you use several times, then you factor that repeating block of
code out into a function that takes another function which will get
called in the right environment.
And macros help here "only" to save one or two loc. But as I said, it
sums up.
André
--

[Juan R.]

Kay Schluehr ha escrito:

Note also that a homogenous syntax is not that important when
analyzing parse trees ( on the contrary, the more different structures
the better ) but when synthesizing new ones by fitting different
fragments of them together.

Interesting, could you provide some illustration for this?

The next question concerns compositionalit y of language
enhancements or composition of even completely independent language
definitions and transformers both on source and on binary level. While
this is not feasible in general without creating ambiguities, I believe
this problem can be reduced to ambiguity detection in the underlying
grammars.

A bit ambiguous my reading. What is not feasible in general? Achieving
compositionalit y?

[JShrager]

Python has this unsung module called doctest that neatly shows some of

the strengths of python: http://en.wikipedia.org/wiki/Doctest

Now I'm *certain* that you're just pulling my leg: You guys document
all your random ten-line hacks in Wikipedia?!?! What a brilliant idea!

Python is newbie-friendly. Part of that is being accessible.
Doctest is about a novel way of using a feature shared by Lisp, that is
docstrings. Testing is important, usually not done enough, and doctests
are a way to get people to write more tests by making it easier. Does
Lisp have similar?

Seems like a trivial commonality between the languages, and a trivial
library, but that's not at all what I was laughing at...

Hey, you even have dead vaporware projects like uuu documented in
Wikipedia! Cool! (Actually, I don't know that doctest is ten lines in
Python, but it'd be about ten lines of Lisp, if that, so I'm just
guessing here.)

Does Lisp have a doctest-like module as part of its standard
distribution? Or are you saying that If you ever needed it, then it would be
trivial to implement in Lisp, and you would 'roll your own'? There are
advantages to doctest being one of Pythons standard modules.

Actually, I don't care what you put into your library -- to some exent,
the more the merrier (as I've said elsewhere, I wish we had your
community of busy ... um ... beavers :-) to create libraries full of
stuff, trivial or not!) The wheat will rise from the chaff. (Some
Lispers might disagree with me here.)

But anyway, what I was laughing at had nothing to do with doctest --
but that you use wikipedia to document your libraries. Elsewhere I have
aregued that Wikipedia is a stupid marketing document -- *many* Lispers
disagree with me here, so let's no go down this road, please as it's
soooooooo OT! So, I'm mostly laughing at the laughability of the
concept of the Wikipedia as somehow a source of all wisdom, not doctest
per se. Random ten-line Python libraries (as well as dead vaporware
python projects, as well as a whole bunch of other useless crap, and
the very occassionally useful crap) being in Wikiperdia just makes me
smile, that's all.