merits of Lisp vs Python

[JShrager@gmail.com]

Re: merits of Lisp vs Python

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]

Re: merits of Lisp vs Python

Paul Rubin <http://phr.cx@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]

Re: merits of Lisp vs Python

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

Re: merits of Lisp vs Python


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@gmail.com]

Re: merits of Lisp vs Python

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.

[Marc 'BlackJack' Rintsch]

Re: merits of Lisp vs Python

In <7xslfmju4g.fsf @ruckus.brouhah a.com>, Paul Rubin wrote:

Marc 'BlackJack' Rintsch <bj_666@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?

Hm, right from the Nemerle macro page linked above:

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.

Ciao,
Marc 'BlackJack' Rintsch

[André Thieme]

Re: merits of Lisp vs Python

Fred Gilham schrieb:

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

>André Thieme <address.good.u ntil.2006.dec.2 2@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.
>

You don't even need to say 'function
(memoize function) would be enough.
And yes, you can memoize functions while the program is running.
And you don't need a tool like slime for it. Lisp already offers ways
for doing that.


André
--

[Christophe]

Re: merits of Lisp vs Python

André Thieme a écrit :

You don't even need to say 'function
(memoize function) would be enough.
And yes, you can memoize functions while the program is running.
And you don't need a tool like slime for it. Lisp already offers ways
for doing that.

In Python while the program is running :

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

[jayessay]

Re: merits of Lisp vs Python

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

jayessay <nospam@foo.com writes:

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

Odd, caml is even older than CL.

>
You'd have to compare (say) OCaml to CL if it's dialect against
dialect. If you're going to bring in the earlier ML family you also
have to bring in Lisp 1.5, which goes much further back than CL.

Fair enough. But really, I don't see any of these things as
particularly "modern" (whatever that means) or groundbreaking.
Certainly not at this point.

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.

There is also a question about "old/new" wrt these value judgements.
Since Lisp is (admittedly some hand waving here) more or less lambda
calculus embodied, is it closer to say The Calculus or Group Theory
than to some random piece of technology?[1] If Lisp is "old
fashioned", then The Calculus and Group Theory are like _really_ old
fashioned. But does that lessen them in some way? What would that
be? Is some random "new" technique (say brute force iterative
techniques for calculus problems with computers) somehow "better"?


/Jon

1. Of course, the _implementation s_ are random pieces of technology.

--
'j' - a n t h o n y at romeo/charley/november com

[Harry George]

Re: merits of Lisp vs Python

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

Kay Schluehr wrote:
>

is rapidly replacing Perl, and Ruby is simultaneously and even more
rapidly replacing Python.

Really? Given its small base, the percentage increases in Ruby use
(for any reason) can look quite impressive. I've see data suggesting
Ruby is replacing Perl and maybe Java. But I've yet to see data which
shows people dropping Python and moving to Ruby. Where do I find that
data?


--
Harry George
PLM Engineering Architecture

[jayessay]

Re: merits of Lisp vs Python

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

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.

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

The Lisp equivalent would be some generic function (frob foo)...

I would say the Lisp equivalent would be to literally do exactly the
same thing. Of course, as you say, maybe doing this doesn't actually
make any sense and so it wouldn't get done...


/Jon

--
'j' - a n t h o n y at romeo/charley/november com

[André Thieme]

Re: merits of Lisp vs Python

Steven D'Aprano schrieb:

Yes. But you can't redefine 1+2 in Python, at least not without hacking
the interpreter. Can you redefine (+ 1 2) in Lisp?

It is possible as was pointed out.
If anyone would do it, he/she would do it inside a package.
Then you would write:
(package:+ 1 2)

So in real world programs there is no danger.
In Python I could just say
def list():
return 30

and won't get a warning. In Lisp I would at least have to shadow +
explicitely.


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


André
--

[André Thieme]

Re: merits of Lisp vs Python

mystilleef schrieb:

Ken Tilton wrote:

>Lisp has all the cool qualities you like in your pets, plus native
>compilation in most implementations , plus maturity and a standard, plus
>a better OO, plus macros, plus a dozen more small wins. Including
>automatic indentation. :)
>>

>
Better OO? You mean the one that doesn't support basic encapsulation
and is retardedly cumbersome to use? There's a reason I said, I'd never
use Lisp for OO not even when I'm high. Gimme Python, Eiffel or
Smalltalk anyday, not the retarded add-on package bolted on CL.

What do you mean with "encapsulat ion" in this context?
I am looking for something that Pythons or Smalltalks OO system have
which isn't in Lisps...


André
--

[Juan R.]

Re: merits of Lisp vs Python

Harry George ha escrito:

Really? Given its small base, the percentage increases in Ruby use
(for any reason) can look quite impressive. I've see data suggesting
Ruby is replacing Perl and maybe Java. But I've yet to see data which
shows people dropping Python and moving to Ruby. Where do I find that
data?

No _scientific_ data but TIOBE Dec index shows an increase of 9x on
Ruby, 1x for Python and -4x for LISP [1]. More:

"There is only 1 month to go before TIOBE announces its 'programming
language of the year 2006'... Ruby remains to be top favorite for the
title."

Look also to Google Trends [2, 3]. One can notice further increase for
Ruby and slight decreasing for Python.

[1] http://www.tiobe.com/tpci.htm

[2]

http://www.google.com/trends?q=ruby+programming%2C+python+programming&ctab=0&geo=all&date=all

http://www.google.com/trends?q=ruby+language%2C+python+language&ctab=0&geo=all&date=all

[Ken Tilton]

Re: merits of Lisp vs Python



Harry George wrote:

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

>>Kay Schluehr wrote:
>>
>>

>>>is rapidly replacing Perl, and Ruby is simultaneously and even more
>>>rapidly replacing Python.

>
>
Really? Given its small base, the percentage increases in Ruby use
(for any reason) can look quite impressive. I've see data suggesting
Ruby is replacing Perl and maybe Java. But I've yet to see data which
shows people dropping Python and moving to Ruby. Where do I find that
data?

You missed it? Google fight:

http://www.googlefight.com/index.php?lang=en_GB&word1=Python&word2=Ruby

Python wins, 74 to 69.3. And there is no Monty Ruby to help.

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