merits of Lisp vs Python

[Ken Tilton]

What do you mean with "encapsulation" in this context?

Mr. mystilleef's remarks struck me as needlessly contentious and perhaps
unavoidably ignorant, hence unworthy of response. YMMV.

ken

--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm

"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd

"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon

 

[Neil Cerutti]

I'm afraid you're on the wrong track. Any programmer can pick
up Lisp and be productive in it these days. Please don't try
to make Lisp seem more mysterious or elitist than it really is.
It's just a programming language, and anyone can learn it:

http://www.gigamonkeys.com/book

I got stuck (last year) in that book:

http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html

The author didn't do Common Lisp (or me) any favors by drawing my
attention to the pathname library. I suppose I missed whatever
the point was supposed to be in the midst of the mind-boggling. I
meant to get back to it but haven't yet.

 

[jayessay]

Maybe not bleeding edge, but more modern than CL in my opinion.

Odd, caml is even older than CL.


/Jon

 

[HowiPepper]

I'll vouch for what Harry said. I'm definitely not a "newbie", I've
been programming since around 1982, and I am fluent in a plethora of
programming languages, not including Lisp. I have checked out Lisp
several times in the past, but I always get turned off completely by
the parenthesis you have to use for everything. What's up with that
anyway?

I had been a big C/Java/Perl developer for many years, but due to a job
change in May of 2005, I had to add Python into the mix. I had never
even given Python a second thought, but after playing around with it
for one afternoon, I had learned enough to enable me to write programs
that did what I needed them to do. I now use Python on a professional
basis almost every single day, and I can tell you with certainty that I
am far more productive with Python, then with any other language in my
arsenal.

As an aside, I recently introduced a young acquaintance to Python, as a
way to learn programming. Since he had absolutely no background in
programming, it took a little to get him going, but thanks to the ease
of use and readability of Python, he is now very confident in his work,
and asks me questions only rarely.

With Python's ease of learning and use, availability of a large number
of libraries, extremely active development community and large
user-base, I'd say the question to ask is what specific advantages over
Python does Lisp offer, to make people switch to it?

Cheers,
Howard

 

[Kay Schluehr]

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.

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. 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.

I'm not precisely sure when programming languages have turned into pop
culture and language designers stopped to name them "Algol", "Scheme"
or "A Programming Language" but "Joy", "Perl" or "Java". Even the small
lambda symbol is a pop fetish nowadays that is printed on the T-shirts
of Haskellians. Obviously language communities need some emotional glue
to grow even when they are constituted mainly by CS PhDs. I don't find
this necessarily a bad thing. In case of Lisp I don't think Paul Graham
made a bad job in constructing the imagery of a libertarian macho
hacker with a high end tool. Meanwhile all the flies are sitting on
Blubb that means on a heap of shit. A bit archaic and more cowboy than
Michelangelo but even Hegel is more famous for ending history, over 150
years before F. Fukuyama repeated this act, then for his intricate
systems theory created by idealist speculation. Some things end as pop
cult while others fill the archives of university libraries.

 

[Cliff Wells]

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,backend): if backend ==
postscript do one thing else do another.
Maybe you can solve this with multiple inheritance, creating
RectangePostscript and CirclePostscript 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,postscript) 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.

Regards,
Cliff

 

[Espen Vestre]

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.

Just as I said: Less managable, but not more dynamic.

 

[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, compositionality, compilers) to wave around, not
ridiculous pop psychological noise.

 

[Kay Schluehr]

Kay Schluehr ha escrito:

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 <test> node:

class FiberTransformer(Transformer):
@transform
def repeat_stmt(self, node):
_suite = find_node(node, symbol.suite)
_ test = find_node(node, symbol.test, depth = 1)
#
# create the while_stmt here
#
return _while_stmt_node

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 <suite> node, 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.

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

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]

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/developerworks/library/l-cppeak2/.

George

 

[Stephen Eilert]

(e-mail address removed) escreveu:

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 ...


...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, compositionality, 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]

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 .

 

[jayessay]

Such a pity that answer is, apparently, wrong.

Thank you to those who wrote back with the more accurate answer, which
apparently is "yes, it is easy and there are no error messages".

Actually, that's not correct either. The correct answer is that the
consequences of redefining (or altering in any way) cl:+ are
undefined. Generally, in this context, that means the same as
"implementation defined". So, while it would be possible in some
conforming implementation to "just sit back and let all hell break
loose" in this situation, in practice, they issue a "barrel" of error
messages.

The message from Frank Buss (and possibly others) that it is actually
easy and results in no errors in any implementation is in error (i.e.,
its just plain wrong). What he is showing is that it is possible to
_shadow_ cl:+ - this in no way shape or form _alters_ (including
redefinition) cl:+.

So, while both comments you mention here are strictly speaking wrong,
Kirk Sluder is quite close to being correct, since, while a conforming
implementation could do nothing, all extent ones that I know of do
issue errors.


/Jon

 

[Paul Rubin]

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 = b[n]

with

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

and the attractions of Python may make more sense.

 

[Paul Rubin]

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]

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]

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?

 

[Paul Rubin]

Unless I'm missing something this looks absolutely dead easy to
implement in Lisp and with a very little macrology you would have the
syntax as well. I'm not sure how this makes one or the other "more
dynamic".

I'm talking about the way Lisp is actually used, not what contortions
one can do with macros. The way one does OOP in Lisp is with CLOS.

 

[Paul Rubin]

In Python it can't happen because + is not a function.
And what do you do if you want to pass + as a HOF?

Use a lambda. There's a library module (use "import operator") that
exports functions for most of these operators. It's used sometimes
but not all that often. You could think of Python as sort of a
Huffman code. It tries to make the most common operations very
convenient, sometimes at the expense of the less common ones.