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

[JShrager]

Yes, but these are community symbols or tribe marks. They don't have

much meaning per se, just like the language name or a corporate
identity.

Unfortunately, I don't believe that this is entirely correct....I do
lurk c.l.p and see quite often people arguing (if briefly) about what
the one (and preferably only one) obvious way of doing things is. This
is only subtly ridiculous. The other ("It fits your brain") is much
less subtle, and much more problematic:

Now, I'm willing to buy that "it fits your brain" is taken less
seriously, but ...

However they express an attitude ( being easy and free from
language design redundancy ) that can be measured at least subjectively
by the user. If Ruby "fits the brain" better, then people will simply
drop Python in future or right now. There is nothing deep about it.

....if not deep, at least insidious, as demonstrated in part by the
current thread wherein, until forced to give it up, the present
pythonistas spent a significant number of chars trying to arguing, in
effect, that Lisp does NOT fit (one's) brain (e.g, is easier to use,
easier to learn, etc.) IN GENERAL. It seems to me (here and on c.l.p)
that many pythonista have somehow drunk this Koolaide and that as a
result have a sort of smug superiority about it. Of course, Lispers
have a smug superiority as well, but at least we have actual language
features (macros, compositionalit y, compilers) to wave around, not
ridiculous pop psychological noise.

[Kay Schluehr]

Juan R. wrote:

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?

My approach is strongly grammar based. You start with a grammar
description of your language. This is really not much different from
using Lex/Yacc except that it is situated and adapted to a pre-existing
language ecosystem. I do not intend to start from scratch.

Besides the rules that constitute your host language you might add:

repeat_stmt ::= 'repeat' ':' suite 'until' ':' test

The transformation target ( the "template" ) is

while True:
<suite>
if <test>:
break

The structure of the rule is also the structure of its constituents in
the parse tree. Since you match the repeat_stmt rule and its
corresponding node in the parse tree you immediately get the <suite>
node and the <testnode:

class FiberTransforme r(Transformer):
@transform
def repeat_stmt(sel f, node):
_suite = find_node(node, symbol.suite)
_ test = find_node(node, symbol.test, depth = 1)
#
# create the while_stmt here
#
return _while_stmt_nod e

So analysis works just fine. But what about creating the transformation
target? The problem with the template above is that it can't work
precisely this way as a Python statement, because the rule for a while
statement looks like this:

while_stmt: 'while' test ':' suite

That's why the macro expander has to merge the <suitenode, passed
into the template with the if_stmt of the template, into a new suite
node.

Now think about having created a while_stmt from your original
repeat_stmt. You return the while_stmt and it has to be fitted into the
original syntax tree in place of the repeat_stmt. This must be done
carefully. Otherwise structure in the tree is desroyed or the node is
inserted in a place where the compiler does not expect it.

The framework has to do lots of work to ease the pain for the meta
programmer.

a) create the correct transformation target
b) fit the target into the syntax tree

Nothing depends here particularly on Python but is true for any
language with a fixed grammar description. I've worked exclusively with
LL(1) grammars but I see no reason why this general scheme shall not
work with more powefull grammars and more complicated languages - Rubys
for example.

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?

Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are
grammars and T1, T2 transformers that transform source written in L1 or
L2 into some base language
L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3
s.t. the transformers T1 and T2 can be used also to transform L3 = (G3
= G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and
the answer is NO. But it could also be YES in many relevant cases. So
the question is whether it is necessary and sufficient to check whether
the "crossing" between G1 and G2 is feasible i.e. doesn't produce
ambiguities.

[George Sakkis]

Cliff Wells wrote:

On Sat, 2006-12-09 at 00:26 -0800, hankhero wrote:

The Common-Lisp object systems has all and more OO-features, some which
you never probably have thought of before. Here's one:
Inheritance lets you specialise a method so a rectangle and a circle
can have a different Draw method. If you wouldn't have OO you would
need a function with if statements to dispatch on thing, if
thing=rectange then drawRectangle if thing=circle then drawCircle.
What if you want a draw method that takes a thing and a backend, then
you need if statements again, draw(self,backe nd): if backend ==
postscript do one thing else do another.
Maybe you can solve this with multiple inheritance, creating
RectangePostscr ipt and CirclePostscrip t objects. Lisp supports multiple
inheritance too, but also multimethods which allow a looser coupling
between objects and dispatching on all parameters, not only the first
parameter (self in python speak). Just define one method
draw(rectange,p ostscript) and another draw(rectangle, pdf)

This mechanism doesn't make much sense in Python since dispatching based
on type rather than on capability is considered "bad" in the Python
world, and for good reason.
The classic example is file-like objects. What if you have two methods,
one that takes a file object and another that takes a string and you
pass an object that has string as a base class but provides file-like
capabilities? Which method should be called? Better to explicitly call
the desired method. Multimethods may make sense in many languages but
not so much in Python.

Actually they do in Python too, and there's a long active discussion in
the Python 3K list about whether should generic functions (aka
multimethods in Lisp) be added in the language and how they blend with
other concepts that compete in the same arena (interfaces, abstract
base classes, etc.). Generic functions are available even today from
the PEAK framework; see for example
http://www-128.ibm.com/developerwork...ary/l-cppeak2/.

George

[Stephen Eilert]

JS******@gmail. com escreveu:

Yes, but these are community symbols or tribe marks. They don't have
much meaning per se, just like the language name or a corporate
identity.

Unfortunately, I don't believe that this is entirely correct....I do
lurk c.l.p and see quite often people arguing (if briefly) about what
the one (and preferably only one) obvious way of doing things is. This
is only subtly ridiculous. The other ("It fits your brain") is much
less subtle, and much more problematic:

Now, I'm willing to buy that "it fits your brain" is taken less
seriously, but ...

However they express an attitude ( being easy and free from
language design redundancy ) that can be measured at least subjectively
by the user. If Ruby "fits the brain" better, then people will simply
drop Python in future or right now. There is nothing deep about it.

...if not deep, at least insidious, as demonstrated in part by the
current thread wherein, until forced to give it up, the present
pythonistas spent a significant number of chars trying to arguing, in
effect, that Lisp does NOT fit (one's) brain (e.g, is easier to use,
easier to learn, etc.) IN GENERAL. It seems to me (here and on c.l.p)
that many pythonista have somehow drunk this Koolaide and that as a
result have a sort of smug superiority about it. Of course, Lispers
have a smug superiority as well, but at least we have actual language
features (macros, compositionalit y, compilers) to wave around, not
ridiculous pop psychological noise.

Right.

So, let's suppose I now want to learn LISP (I did try, on several
occasions). What I would like to do would be to replace Python and code
GUI applications. Yes, those boring business-like applications that
have to access databases and consume those new-fangled web-services and
whatnot. Heck, maybe even code games using DirectX.

So, how would I do that? For Python, that was simple. I learned the
basics, then moved to the libraries, learning as I went. Python has
some excelent online resources.

No, I don't want to see yet another Fibonacci example. No, console
output is not fun. And yes, I know about this list processing stuff.
All I can find are introductions to LISP written for computer science
courses. I can't seem to put together all those mnemonics into a
working program. LISP is full of primitives with 3-4 characters, chosen
for historical reasons.

The bottom line is that I didn't have a pleasant learning experience.
Perhaps the lispers here could offer some insights?
Stephen

[JShrager]

So, how would I do that? For Python, that was simple. I learned the

basics, then moved to the libraries, learning as I went.

We've already all agreed that Python has a much larger set of standard
libraries than Lisp. You're right; This is an advantage that we all
recognize, and would love to have. We've also all agreed (I think) that
there's nothing in principle stopping Lisp from having these except
popularity, and that there is no good reason for this...except not
already having lots of libraries. Unfortunately, this is a bad bug, and
we (the lisp community) is hung on it. So if you guys would just fix
your language by adding homogeneous syntax and all that it brings with
it (macros, compilers, etc) we'd be happy to use your version of Lisp,
and all its great libraries, instead of ours! :-)

[Ravi Teja]

Mark Tarver wrote:

Paul Rubin wrote:

"Mark Tarver" <dr********@uko nline.co.ukwrit es:

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

<http://google.com/search?q=python +lisp&btnI=I'm+ feeling+lucky>

Thanks; a quick read of your reference to Norvig's analysis

http://norvig.com/python-lisp.html

seems to show that Python is a cut down (no macros) version of Lisp
with a worse performance.

By that standard, every other mainstream dynamically typed language for
you is a cut-down version of Lisp with worse performance.

The only substantial advantage I can see is
that GUI, and Web libraries are standard.

Somehow you conveniently miss the fact that he stated that it is ...
1. An excellent language for his intended use.
2. Easy to use and learn.
3. Easier to read than Lisp.
4. Looks more like pseudo code than does Lisp.

Here is a quote from the same Peter Norvig

"Python has been an important part of Google since the beginning, and
remains so as the system grows and evolves. Today dozens of Google
engineers use Python, and we're looking for more people with skills in
this language."

http://www.python.org/Quotes.html

This confirms my suspicion
that Lisp is losing out to newbies because of its
lack of standard support for the things many people want to do.

You confirm things too easily :-).

[Paul Rubin]

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

import module
module.function = memoize(module. function)

Yes, I mentioned that a bit earlier in this thread (not about the
"during runtime" thing).
I also said that many macros only save some small bits of code.
Your python example contains 4 tokens / brain units.
The Lisp version only has 2.

You shouldn't count the import statement, since you'd need the
equivalent in Lisp as well.

Contrast the much more common

a[i] = b[n]

with

(setf (aref a i) (aref b n))

and the attractions of Python may make more sense.

[Paul Rubin]

Michael Livshin <us****@cmm.kak pryg.netwrites:

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,

It's a reasonable answer. Does SML have a macro system?

[Paul Rubin]

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

We are following them in the direction of much more powerful, and at the
same time more secure (type-safe) solutions like Haskell Template
Meta-programming.

So there seems to be something macro-like for Haskell.

I think that's some kind of proposed or experimental Haskell feature,
not in the current standard, but I'm not sure. I'm barely even a
newbie with Haskell.

[Paul Rubin]

jayessay <no****@foo.com writes:

Also, there is the issue of whether there even is a "continual
progression", as in "moving up some ladder" towards something
"better", in the context of programming languages. All of that is
pretty fuzzy stuff, and plenty of CogSci work has shown these value
judgements in this context to be less than obvious in any meaning.

It's simply that newer language designs by definition have more of an
experience base to build on than older ones, if the designers care to
make use of it. ML's designers were quite aware of what it was like
to write Lisp code. Lisp (like anything else) has good and bad
points, and ML's designers were able to examine these in retrospect
and try to improve on them.

Are there any Lisp devotees who have done serious development in ML?