merits of Lisp vs Python

[Paul Rubin]

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]

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.

 

[Michael Livshin]

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

 

[Fred Gilham]

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 (e-mail address removed)
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.]

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

 

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

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(loggedInUser) ?>.<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 compositionality 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
compositionality?

 

[JShrager]

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

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

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]

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

 

[Harry George]

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?

 

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

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]

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)

 

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

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

 

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

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 "encapsulation" in this context?
I am looking for something that Pythons or Smalltalks OO system have
which isn't in Lisps...


André
--

 

[Juan R.]

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,+python+programming&ctab=0&geo=all&date=all

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

 

[Ken Tilton]

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

 

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

André Thieme a écrit :

In Python while the program is running :

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.

In the first moment one might want to say:
"Hey, just 10-15 more characters to type in Python". But this sums
up. If someone *really* thinks this extra typing is not bad, why doesn't
this person add some functions like:
def foobar():
pass

and call them from time to time? If a bit of extra typing is not bad one
could call this function each time before one uses the built in * operator.
Why not?


André
--

 

[Juan R.]

Ken Tilton ha escrito:

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

Nice animation!

http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Monty+Ruby

 

[Pillsy]

André Thieme wrote:
[...]

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

Presumably that CLOS makes no attempt to enforce the distinction
between "private" and "public" methods or class slots. I suppose you
can indicate that certain classes, generic functions et c. are
"private" by not exporting the symbols associated with them from the
relevant package, but even then you merely have a way to communicate
your intent to the user, not a way to force them to keep their hands
off.

ISTR that it's easy to get at "private" things in Python, too, so I'd
be surprised if this were a make-or-break issue for Pythonistas.

Cheers,
Pillsy

 

[Rob Thorpe]

Ken Tilton ha escrito:

Nice animation!

http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Monty+Ruby

It's not fair to pick on him just because you're better at
Googlefighting...
http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Juan+Gonz%E1lez

This thing is strange, I don't understand it at all...
http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Robert+Thorpe
I find the results dubious. A conspiracy masterminded by Monty Ruby no
doubt.