merits of Lisp vs Python

[mystilleef]

Well, for example, "Lisp uses a fully-parenthesized notation for
writing programs" and "Python has significant whitespace" are both
objective facts. Agreed? There's nothing subjective about those two
facts. Do any of your points approach that level of objectivity?

I believe so. Even though I wasn't trying to be.

What experience is this?

Experience working with Scheme code in a project a few years back.

Macros are not a substitute for libraries, nor are libraries a
substitute for macros. Having macros lets you build more powerful and
more expressive libraries.

And not having them helps you build less powerful and expressive
libraries?

So it's not just macros but metaprogramming as a whole that bothers
you? You must have an enjoyable time writing programs.

In Python, yes.

Nor do you need it to grok Lisp code. The environment is there to
make your life better. I was merely responding to your original claim
that it's impossible to make sense of code that uses macros.

Not impossible, just painstaking.

Hmm. Anecdotal evidence about Scheme (a vastly and fundamentally
different language from Common Lisp). Again, you've clinched it for
me.

I don't believe my experience would have been marginally different had
I used Common Lisp.

I do believe that the "squealing and whining about macros" was a
response to Pythonistas claiming that macros are not useful. This was
in turn in response to a foolishly (trollishly?) cross-posted
question. It is not as if we have invaded your newsgroup.

Pythonistas are not saying macros are not useful. They are saying their
usefulness in overrated, exaggerated and needless in the context of
Python. They are saying they don't see what they are missing and along
with the rest of the world couldn't give a damn whether or not it is
ever implemented in Python. Okay, I can't speak for all Pythonistas,
but that's what I'm saying.

 

[webraviteja]

The other possibility is that he is just trying to justify not doing it

because it would be so hard without the regular syntax of Lisp,
including parens, and with the JIT module resolution problem discussed
earlier in his remarks. Understandable.

I am surprised that no one brought up Logix yet.
http://livelogix.net/logix/

Macros are perfectly doable in Python while still preserving the white
space syntax. And Python is sufficiently pliable with it's dynamism to
implement this without changing the compiler. And yet, no one cares
about this project and it is effectively dead.

So it is not about technical difficulties. It is not about Python
community not having the opportunity to try out the power of macros.
The Python community on the whole does not think macros as useful.
Personally, I find it strange that we, who argued so many times for
dynamic typing, the need for expressiveness and that it is OK to trust
the programmer with power ("we are all adults here" argument) while
arguing against relatively restrictive languages like Java find macros,
a chaotic and disruptive concept.

 

[Bjoern Schliessmann]

Says a person with a 13-line sig.

Who? Mine was exactly three lines long.

Hint: What's "-- "?

Shrugging Regards,


Björn

Fup2p

 

[Mathias Panzenboeck]

Yes, but Python also supports the functional style to some extent.

I currently visit a course about functional programming at the university of technology vienna:
python implements only a small subset of things needed to be called a functional language (list
comprehension).
but yes, for a imperativ oop language python is very close to functional.

Lisp is only a functional language in that it support both functional
and imperative programming styles. Duck typing is almost identical to
latent typing in Lisp.
And, Common Lisp at least is object orientated.


Their scope is actually very similar. Learn about lisp and you will
soon discover their similarity.

ic

 

[Paul Rubin]

Now, if you want to tell me that, despite all the talk, Lisp coders don't
actually create new syntax or mini-languages all that often, that they
just use macros as functions, then the question becomes: why do you need
macros then if you are just using them as functions? Why not use functions?

Macros let you write what amounts to functions that don't evaluate
their arguments. Think of the endless clpy wars over the ternary
conditional operator. You want to write something like

def ternary(test, iftrue, iffalse):
if test: return iftrue
else iffalse

but because of side effects, you don't want

a = cond(test, f(x), g(x))

to evaluate both f and g. That is trivial to do with a macro but
can't be done with a function. Macros can be used tastefully and
effectively in Lisp programs, though not everyone limits their usage
like that.

Haskell uses a different approach: 1) all arguments are unevaluated
unless the program tries to actually use the values. 2) there are no
side effects anyway. This may be why Haskell's current lack of macros
apparently isn't a big problem.

 

[Kaz Kylheku]

unnecessary abstraction. The question I have is why do critics
single out macros and not other forms of abstraction such as
objects, packages, libraries, and functions?

The answer is: because they are pitiful morons.

But you knew that already.

 

[Ken Tilton]

Uh. Clearly no one would be dumb enough to admit it in front of the
entire usenet world, right?

The good news is that I was just trying to flush out a live specimen.
The bad news is that after some tests we want to dissect you.

- Mr. NoOne


P.S. I am still going to get back to it when I get some time, really.
LISP seems intriguing and superior, almost a magical Rubik's cube
waiting for me. I just stumbled across Python in the meantime and code
started flowing - I got distracted.

Oh, shucks, that is not "gave up because they could not handle the syntax".

You have me wondering if I would have switched from C to Lisp had Python
been what itis now back in '95. Obviously the simple transition would
have been attractive. OTOH I had done extensive LOGO (and loved it) and
experimented heavily with Prolog, so syntax would not scare me. The
immaturity of Python would have been an issue because I had just gotten
sliced up pretty badly with bleeding edge stuff I tried at the same time
(trying desperately to avoid C++). I beat on the C preprocessor like I
was its daddy, so macros might have made sense to me even without having
played with them. Giving up cycles I would not like all other things
being equal. And to tell you the truth, novelty tends to make me more
productive, not less, because fresh brain cells perforce get pulled into
play. Sounds like I would have dabbled in both, and then Lisp would have
won because I recall the first two weeks being pretty much astonished
whooping and hollering over how great Lisp was. But Python has a lot of
that, too.

I have CL (& Scheme) on all my
machines awaiting my focus.... I'll join the flock any day now.
I've just been busy. There is a cost to learning and I've not had the
spare change to date.

But New Years resolutions need to be made: I could get up a couple
hours early and spend some quality time with CL, do a daily hour jog,
and eat a really heathly breakfast. Writing myself a note on this.


P.P.S. Undoubtedly not learning a syntax either means not enough time
was put in or the student lacked proper intelligence.

Intelligence to understand syntax? Isn't it memory (and not so much that
the correlation with intelligence would matter)? This punctuation means
this, that punctuation means that, and the precedence is this. One of
the big wins of Lisp is that it is just (verb object*) 95% of the time.

Maybe you mean functional vs imperative requires intelligence? That I
might buy. A little. But then Lisp handles imperative, too. You just get
laughed at it if you post it to c.l.l.

This will always
bias the significance of learning syntax as a factor in choice of
language to be under reported.

That's OK, I am looking for the person so bright they have the
self-confidence to expose their failure. Then we do not have to dissect
them, we can ask them to introspect and get useable data. But you did
not say anythng about having a problem with Lisp at all let alone the
syntax and indeed offer some quotes that could go in the RtL Highlight
Film, so you are useless. No fee for you.



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

 

[Paul Rubin]

yeah, I think it is. Folks don't vary that much. If every Lisp
programmer also reports parens disappearing at about thirty days, any
given non-Lispnik can pretty much bet on the same experience.

I think an editing program that balances parens automatically is near
indispensible for writing Lisp code. I can't stand writing Lisp
without Emacs.

My suspicion goes the other way, and is based not on punctuation,
rather on imperative vs functional. In Lisp every form returns a
value, so I do not have all these local variables around that, in the
strecth of an interesting function, take on a stream of values and
transformations to finally come up with some result, meaning to
understand code I have to jump back and forth thru the code to see the
lineage of a value and figure out its net semantics. Too much like work.

Python has been steadily getting better in this regard.

 

[Bill Atkins]

And not having them helps you build less powerful and expressive
libraries?

If you told me a turbocharger makes a car accelerate faster, and I
said, "So not having a turbochanger helps your car accelerate slower?"
what would be your reaction?

Not impossible, just painstaking.

No more so than seeing a function you don't understand. Please be
realistic here. Read through the other posts in this thread, where
this same issue is refuted ad nauseam.

I don't believe my experience would have been marginally different had
I used Common Lisp.

Well, believe it. The languages are very different, although they
appear superficially similar to anyone who isn't familiar with both.
The similarity is much like that between Python and Ruby. The two
appear to have very similar syntax, but anyone who knows both knows
that they're quite different underneath.

Pythonistas are not saying macros are not useful. They are saying their
usefulness in overrated, exaggerated and needless in the context of
Python. They are saying they don't see what they are missing and along
with the rest of the world couldn't give a damn whether or not it is
ever implemented in Python. Okay, I can't speak for all Pythonistas,
but that's what I'm saying.

Of course they're overrated - *because you don't have them*. It would
be amusing to see how Python's collective tune would change if Guido
issued a royal edict that "Python 3000" (hehehehe) will support
syntactic extensions. If Python had macros, would you really
complain, or would you appreciate the extra expressive power?

On the other hand, I am willing to agree with all of you Pythoners
that Python is winning in the library department. So are Perl and
Ruby. It would be silly for me to claim that libraries are
"overrated," just because other languages have more of them. The
truth is that I would like to have macros, libraries, and Lisp's
interactive development model, all at once.

But your claim upthread that Lisp doesn't have libraries because it's
not "worthwhile" is unfounded. When all of the AI companies collapsed
in the late 80's and early 90's, Lisp went comatose by association.
The revival of Lisp as a tool for doing modern programming dates back
only to about 2000 or so. So six years along, we are behind other
languages that have had active communities for ten years (Ruby),
fifteen years (Python), and nearly twenty years (Perl). I am not
worried about the future of Lisp libraries. We already have some:

- CL-PPCRE, a pure-Lisp regular expression package that is faster than Perl's
- Hunchentoot, a complete web server and web development framework
- CAPI, a proprietary but excellent GUI library
- CommonSQL (and CLSQL, its open-source offspring)
- parenscript, an embeddable Lisp that compiles to Javascript, letting
you use macros in your Javascript code
- assorted useful libraries, like MD5, base64, SDL, XML parsers, web
page fetchers, testing frameworks
- bindings to the common C libraries, like GD, Tk, Gtk+

We will get there, in time. Lisp is still the only language in
history to linger in "mostly dead" status for a decade and then be
resurrected; it is capable of more surprises yet.

 

[=?ISO-8859-15?Q?Andr=E9_Thieme?=]

Speaking as someone who had been programming for more than twenty years
before learning Python (including a brief gander at Lisp), and also
referring to many years of observations of newcomers to Python: Python's
syntax also appeals to experienced programmers.

I would say that your statement about Lisp syntax is wrong. Not that it
is technically inaccurate, but that it completely misses the point, so
much so that it is wrong to say it. One of the key goals of Python is
readability, and while it is indeed easy to learn the rules for Lisp
syntax, observational experience indicates that many people (perhaps even
the vast majority of people) find it difficult to learn to read Lisp
programs.

If you ask a non-programmer to read programs he/she will have difficulties.
But I guess this person would not have more problems learning than any
other programming language. They are not biased because they don't know
how programs look like. If you show Lisp code to people who know C or
Java, Python or PHP they will not find as easily the structure.
They are already used to something, and we all are creatures of habit.

As for your claims about speed, they are also nonsense; I doubt one
would find an order of magnitude increase of speed for production
programs created by a competent Lisp programmer compared to programs
created by a competent Python programmer.

The Python language interpreter itself is programmed in C (biggest parts).
Lisp compilers are programmed in Lisp.
Both are mature production programs. Why do you think isn't the Python
interpreter programmed in pure Python?

Consider this: Lisp has had years of development, it has had millions of
dollars thrown at it by VC firms -- and yet Python is winning over Lisp
programmers. Think about it.

When Lisp got so many millions it was not known how to create very good
compilers. Mankind had to learn it, so these investments were needed.
Today there are open source Lisps. And while they don't get millions
of Dollars for development they can produce mature production code.


André
--

 

[Bill Atkins]

worried about the future of Lisp libraries. We already have some:

- CL-PPCRE, a pure-Lisp regular expression package that is faster than Perl's
- Hunchentoot, a complete web server and web development framework
- CAPI, a proprietary but excellent GUI library
- CommonSQL (and CLSQL, its open-source offspring)
- parenscript, an embeddable Lisp that compiles to Javascript, letting
you use macros in your Javascript code
- assorted useful libraries, like MD5, base64, SDL, XML parsers, web
page fetchers, testing frameworks
- bindings to the common C libraries, like GD, Tk, Gtk+

Lest anyone interpret that list as exhaustive: http://www.cl-user.net/

 

[Bill Atkins]

Ahem. Calling Python programmers "flies".

For what it's worth, I don't think this was called for, either.

Whatever, fanboy.

Weak.

 

[Paul Rubin]

Advantages of Python:

1). More and better mature standard libraries (Languages don't matter,
libraries do).

Erm, somewhat true, but Python's library is overrated. Lisp's on the
other hand is out of date.

2). Multiple programming paradigms (including functional style
programming see itertools, functools, operator modules (lambda, map,
filter, reduce, sum etc builtins), higher order functions, list
comprehension, blah, blah)

Getting there but still full of warts.

3). Better OO implementation. (I used to hate OO until I started using
Python)

Have you used CLOS? Flavors?

4). Ultimate glue language (Plays well with C, C++, Java, .NET. nuff
said. Bindings for almost any lib worth using, at least on *nix)

Hmm, Python's C API is awful compared with the FFI's in reasonable
Lisp implementations or to Java's JNI.

5). Clearer syntax.
OK.

6). Better namespace management. (nobody ever talks about this, but
Python seems to be one of the few languages that gets symbol management
right from a users perspective)

I dunno, Python gets some things completely wrong in this regard.

7). Easier packaging and distribution system.

Because there's basically just one Python implementation (CPython).

8). Ubiquity! Python is everywhere. Lisp, bleh.

Not so sure of this, unless you're limiting to Common Lisp. There are
Lisp systems out there that use as little as 20k of memory, running
inside cellular phones etc. By comparison an attempt to shoehorn
Python into the 1 megabyte Palm handheld computer was abandoned.

9). Relatively good docs (PHP has better).

Lisp's docs are far superior to Python's. This is one of the areas
where I bag on Python all the time.

10). Fewer perceived community assholes. Large community.
11). Less fragmentation.

True and true.

Advantages of Lisp:

Learning a functional language can improve your programming range and
depth. And today, I wouldn't even recommend Lisp (it's rather archaic),
when there's mind bending Haskell. I'd go as far as saying I believe
Haskell has a better fate than Lisp.

I don't really of think Lisp as a functional language; its data
representation is what makes it worth knowing. Despite years of
experience with Lisp and Python I'm still having trouble wrapping my
head around Haskell, and that tells me Haskell is really doing stuff
that Lisp does not.

On Lisp Macros:

I think they are overrated, and in general cause more harm than good.
It's the reason I find Lisp-like programs difficult to grok, maintain
and extend. Cos every smart ass wants to needlessly write his own mini
language to the point of absolute obfuscation. Naturally, I'm supposed
to be awed by his mischievous cleverness.

There is certainly the possibility of writing Lisp code that way, but
it's not all that big a problem when the code is written tastefully.

Conclusion:

The semantics or features of a language is almost irrelevant today.
Developers want to put the lego pieces together, they don't want to
make lego. Rewriting the sun and moon, or needlessly reinvent the wheel
was popular in the 70s, but it's boring and expensive today. Today,
when a developer needs to solve a problem, the question they ask is,
"Is there a library for that?".

But it seems to me that Java crushes Python in this regard.

 

[Paul Rubin]

People only contribute to things they understand and appreciate. More
people would be writing Lisp libraries if it was worthwhile.
Apparently, it doesn't seem to be. A few years ago, I tried to write an
editor is Scheme. The experience was appalling. I was able to write a
fully functional prototype editor in less than a week in Python.

I remember thinking about writing an editor in Python. One of the
editor functions I couldn't figure out how to implement was
search-backward-regexp. Although the underlying regexp package in
Python's standard library is capable of searching backwards, the
Python lib does not export that feature to where Python code can use
it. RFE #516762 about this has been open for almost 5 years.

 

[Paul Rubin]

Slow for users who aren't familiar with Psyco, Pyrex and C extensions,
sure.

Psyco is not included in the Python distro. Pyrex and C extensions
depend on having C compilers available for every target platform. As
a Linux user, if I want to release Python programs that Windows users
will run, I cannot use C extensions because I have no way to compile
them for Windows, and most Windows users don't have C compilers
either.

Anyway it's pretty lousy advocacy for a language to say "well if the
language is too slow, don't use it, use another langauge like C instead".

I think PyPy will make a big difference when it becomes part of
regular Python but for now it's vaporware.

 

[tayssir.john]

Donkeys have wings.

Please stop misinforming your fellow Python users. Feel free to look up
"CLOS" and the "metaobject protocol." Further, Lisp is not a functional
language like Scheme; it has unusually powerful iteration and array
facilities.

Common Lisp's OOP has multiple inheritance, a metaobject protocol,
method combinations, generic functions. I realize these sound like
buzzwords to you; I vaguely recall this being a nice video intro:
<http://www.archive.org/details/DanielGB1987>


Alan Kay coined the term object oriented programming, and I think
you'll enjoy his keynote "The computer revolution hasn't happened yet."
At 54:30, he praised the book explaining Common Lisp's metobject
protocol as being the "best book anybody's written in ten years", for
containing "some of the most profound insights, and the most practical
insights about OOP, that anybody has done about OOP in the last many
years."
<http://video.google.com/videoplay?docid=-2950949730059754521>

And he offered a Limoge Balloon award to anyone who'd simply rewrite
the book so that the general OOP community could understand it, for
being "a great service to mankind."

The concepts in that book underlie Lisp's modern OOP system.


Further, you portray Lisp as a "functional" language. But it is a
powerful iterative language. Check out LOOP, a powerful iteration
facility. Check out its powerful multidimensional arrays, which are
adjustable and have fill-pointers.


There exist legitimate criticisms of Common Lisp, and I've even written
a page with "gotchas." One should remain appropriately skeptical of
Lisp users' claims, because they too can mislead. I wish we could
critique thoughtfully. On the basis of facts, not invented claims.


Tayssir

 

[tayssir.john]

(e-mail address removed) wrote

Further, Lisp is not a functional
language like Scheme; it has unusually powerful iteration and array
facilities.

Excuse me, I mean to say it is not a pure functional language.

Tayssir

 

[Ken Tilton]

I think an editing program that balances parens automatically is near
indispensible for writing Lisp code.

I would say indispensible full stop.

I can't stand writing Lisp
without Emacs.

Emacs or an Emacs-like editor (or at least Lisp-ware editor) provided by
the Lisp environment.

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

 

[Paul Rubin]

I currently visit a course about functional programming at the
university of technology vienna: python implements only a small
subset of things needed to be called a functional language (list
comprehension). but yes, for a imperativ oop language python is
very close to functional.

List comprehensions are just fairly trivial syntax sugar. The essence
of functional programming is being able to construct new functions on
the fly, and Python does that. See Hughes' paper "Why functional
programming matters" and imagine doing the examples in Python vs. doing
them in Java.

 

[Paul Rubin]

Lest anyone interpret that list as exhaustive: http://www.cl-user.net/

What have you got for concurrency? How would you write a
multi-threaded web server in Lisp?