merits of Lisp vs Python

[Steven D'Aprano]

But as was pointed out earlier in the thread, those keywords can be
overshadowed by custom functions in python as well.
Really?

File "<stdin>", line 1
def import():
^
SyntaxError: invalid syntax


Nope, can't shadow or change keywords. (And yes, the error message could
be better.)

The only reason
that we don't assume those two python lines could mean *anything* is
because those mechanisms are not well advertised, and most people
don't have a need to shadow "import."

Or because they can't mean just anything.

Of course, it is possible to abstract away all of the lisp in such a
way that you have a completely new programming language. But is this
really a problem? Perl5 and bash are abstractions of C. Python has
been implemented on both C and java, and chunks of perl6 have been
implemented on top of Haskell.

That depends. If somebody smart is designing a new programming language,
then no, you get a new programming language.

If somebody not-so-smart is merely hammering the round peg of Lisp into
the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
that will be a problem. But apparently, despite the talk of using macros
to implement anything in Lisp, nobody actually does that.

How do you know that operator has not been shadowed or overloaded in
python?

Because the tokens 1 and 2 cannot be anything but ints, and + with two
int args cannot be anything but addition.

Perhaps it's because I'm a social scientist and not a programmer by
training, but I find many arguments for *technical* solutions to
*human performance* problems to be rather weak as a general
practice. In some cases, using a very restrictive language may be
the best solution for the problem.

I don't know about you, but I'm not talking about VERY restrictive
languages -- I'm using Python, which isn't very restrictive at all. But
even Lisp has some restrictions -- you can't jump to an arbitrary memory
location and treat whatever random bytes are there as executable code, can
you?

 

[Steven D'Aprano]

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.

 

[Paul Rubin]

I don't even know what that means. Would you like to translate?

This is something that I've wished Python had. If I try to describe
it I'll probably get it wrong. But basically say Foo is a class with
multiple superclasses. The superclasses each define a "name" method
and Foo itself may also define a "name" method. When you call
Foo.name() you want that to invoke both Foo's name method and the
superclass methods. In Python you have to do grotty things like
super(Bar,self).name() in the Foo.name() to make this happen by hand,
and you have to keep tweaking that as you add and remove superclasses.
In Lisp, you can set it up so that the multiple "name" calls happen
automatically. The :before, :after, and :around keywords let you say
what order you want the calls to happen in. You'd use :before for
setup actions, :after for cleanup actions, and just plain defmethod
for the stuff that is supposed to happen in between.

 

[Steven D'Aprano]

Ohh, can the guy who does discourse analysis for a (meager) living
respond to this?

To start with, English does not restrict the expressiveness and
power of the syntax and grammar.

Really? There are no restrictions whatsoever in English syntax and
grammar? None at all?

So, when I say "sits cat rat" it is not only legal English, but you can
tell which animal is sitting on which?

And if I write "i helped my uncle jack off a horse" with no punctuation or
capitalisation, you can tell which of the two meanings I mean?

Although it isn't strictly syntax or grammar, you also understand
precisely what I mean when I say "the gostak distims the doshes" --
because, as you say, English has no restrictions.

And if I write "You are an idiot", you'll understand that in *my* version
of English "You" means watermelon, "are" means to grow, "an" means best,
and "idiot" means in the summertime, and naturally you won't be offended.

But I'm belaboring the point. Of course English has restrictions in
grammar and syntax -- otherwise one could write something in Latin or
Thai or Mongolian and call it English. There are RULES of grammar and
syntax in English, which means that there are possible expressions which
break those rules -- hence there are expressions which one can't write in
legal English.

That doesn't mean that there are concepts which one can't express in legal
English (although there may be). But we can communicate in English because
when I write "Fred hit Barney with a stick" we both agree that it was Fred
who did the hitting, not Barney or the stick, and Barney was the victim.
If English had no grammatical restrictions, we couldn't agree who hit whom
with what.

 

[Kirk Sluder]

In some cases lisp macros are a way of saying tomato to something
that would be called "tomahto" in python.

One common use of macros is custom iteration constructs. In my
social network analysis I wanted to do something to each and every
sender-recipient pair in the header line of "mail" messages in my
dataset. (And yes, I did have permission to use this data.) Each
message had one sender, but possibly multiple recipients. Since I
would be doing multiple forms of analysis, I might as well create
one iterator to do this.

The DO-MAIL-RELATIONS macro takes the mail message (line), parses
the sender field and assigns it to (sender), splits the recipient
field and assigns it to (recip) and then performs the logic in the
body which often involved looking up values in a database, and
setting values in a matrix.

(kirk.matrix-process:do-mail-relations (message sender recip)
;;about 12 lines of logic snipped
)

To be pedantic about this call. "KIRK.MATRIX-PROCESS" identifies the
package/namespace for the macro call. "DO-MAIL-RELATIONS" names the
macro as part of the DO family of iteration constructs which are
basic to lisp.

Now that I think about this, in python I'd probably do this using
object logic that returned the recipient list as an iteratable
object:

for sender, recipient in message.relationPairs:
#about 12 lines of logic

Would it have been possible to implement DO-MAIL-RELATIONS as a
function? Possibly, but I found trying to compact all of that logic
into a single-use function that could be safely passed to another
function to be more trouble.

Another common macro use is the "WITH-STREAM" family which opens a
stream for IO and closes it at the end.
(with-open-file (file-handle "filename" :direction utput)
(format file-handle "Hello world.~%")
)

The pythonic way to do this would be to create a class that
implements file-like behaviors:

output = fileLike.open()
output.write("Hello world\n")
output.close()

You might want to use a custom "WITH-STREAM" macro or file-like
object if you need to format, filter, or compress the outgoing
stream in any way.

 

[Wolfram Fenske]

Here, you've basically shot yourself in the ass. Appealing to
Turing completeness when talking about programming language
features is about the dumbest thing you can make. In Turing sense,
a program is simply a function that takes an argument and returns a
value. It doesn't say anything about how this function was
implemented. It could be Turing machine, lambda calculus, Markov
chains or whatever else. All these methods produce the same set of
programs, but that doesn't mean you could implement lambda in
Turing machine for example.

[...]

If you're talking about practicality, then of course you're correct,
not all languages are equally expressive. Some languages are not
expressive enough.

I agree.

Some languages are too expressive.

I disagree. "Too expressive"--what a thing to say.

[...]

Look, all snarkiness aside, it just isn't true that "stuff like this
is impossible in other languages". If Wolfram Fenske had said "stuff
like this isn't easy in many other languages" he would have been
right.

I said that it's impossible to write you own object system in other
languages *and* have it behave like it was part of the language. OK,
you could always write your own pre-processor, i. e., your own
Foo+Objects to Foo compiler. But that's almost like saying it's
impossible. Now, object systems aside, how about that one: One of the
new features of Python 2.5 is a syntax for

--8<---------------cut here---------------start------------->8---
if condition:
x = true_value
else:
x = false_value
--8<---------------cut here---------------end--------------->8---

which becomes

--8<---------------cut here---------------start------------->8---
x = true_value if condition else false_value
--8<---------------cut here---------------end--------------->8---

(see [1]). IMO that's a nice addition because this pattern is
something that has bothered me for some time.

Here's another one, the "with" statement [2]:

--8<---------------cut here---------------start------------->8---
Some standard Python objects now support the context management
protocol and can be used with the 'with' statement. File objects are
one example:

with open('/etc/passwd', 'r') as f:
for line in f:
print line
... more processing code ...

After this statement has executed, the file object in f will have been
automatically closed, even if the 'for' loop raised an exception
part-way through the block.
--8<---------------cut here---------------end--------------->8---

My point is that in Python--and AFAIK any other language except maybe
OCaml and maybe maybe Haskell--, you have to wait for these changes
until the language designers decide to make the for you. And if they
don't, you're out of luck. In Lisp, you can just add this yourself.

And if he had said "and stuff like this carries risks as well as
benefits" he would have come across as less of a language fanatic.

Sure, you can shoot yourself in the foot with macros. But you can do
that in any language of any degree of expressiveness [3]. Come to
think of it, the whole reason why we use high level languages is
because of their expressiveness: We get stuff done faster and
introduce less errors. So "the more expressive, the better," right?
But according to you, there's a point when a language gets "too
expressive". I don't see why.

One of the risks with Python is the ease with which you can modify the
built-ins. An expression like list(2, 3, 4) doesn't necessarily create a
list from 2, 3, and 4, because the built-in list could be redefined.
(In practice, that's not often a real problem, because experienced
Python developers simply learn not to needlessly or confusingly shadow
built-ins. It's not the best system, but it works well enough in
practice.)

So you do trust your developers not to do anything stupid.

But at least the basic syntax and keywords of the language are known
to be constant. With Lisp macros, even that isn't guaranteed.

Let me summarize: you're allowed to redefine every built-in function
you want but introducing new syntax is simply too much. See, this is
the kind of thinking I don't understand. I say macros are good
because a), b), and c) and you answer macros are bad because, uhm,
well, it would be pure anarchy.

Now, if Lispers would say "Oh yes, macros give you great power, and
with great power comes great responsibility. Be careful." then, no
doubt, we'd take you guys more seriously.

Sure, it's a powerful tool but it's not *that* hard to use. Maybe
you're afraid of it because that it's something that's unique to Lisp?
But IMO the reason for that is not that they're too powerful. IMO it
has mostly to do with the fact that other languages' syntaxes make it
too difficult to implement Lisp-style macros.

But we don't hear that -- we hear Lispers going on and on about how
great it is that they can easily redefine every corner of the
language. Do you blame people for *believing them* and imagining
that reading Lisp code is like following some ghostly
will-o-the-wisp across a swamp, where nothing is what it seems and
the landscape is forever shifting?

Come on! You're telling me people don't learn Lisp because they are
afraid of it? Python allows you to redefine built-in functions, as
you said, Ruby allows you to attach new methods to live objects, but
Lisp is simply going too far?

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?

Easy because macros are not functions. Functions allow you abstract
functionality, macros allow you abstract syntax. Look at the examples
above. How would you implement conditional expressions as a function?
Answer: You can't, it's syntax.


Footnotes:
[1] <http://docs.python.org/whatsnew/pep-308.html>

[2] <http://docs.python.org/whatsnew/pep-343.html>

[3] And here's the proof
<http://www.reed.edu/~tuckers/jokes/foot.html>

 

[Paul Rubin]

Another common macro use is the "WITH-STREAM" family which opens a
stream for IO and closes it at the end.
(with-open-file (file-handle "filename" :direction utput)
(format file-handle "Hello world.~%")
)

The pythonic way to do this would be to create a class that
implements file-like behaviors:

output = fileLike.open()
output.write("Hello world\n")
output.close()

Actually the Python example can lose (e.g. leak a file descriptor
temporarily) if output.write raises an exception (prevents
output.close from running). For this reason Python recently
introduced the "with" statement:

with output as fileLike.open():
output.write("Hello world\n")

Here the file gets closed automatically (by running an exit method in
the fileLike class) when the "with" block exits, whether normally or
through an exception.

 

[George Sakkis]

1. Lisp is the only industrial strength language

^^^^^^^^^^^^^^^^^^^
You keep using that phrase. I don't think it means what you think it
means.

with pure compositionality, and that this makes it suprior to Python.

Perhaps it does in some programming language theory research groups. In
the real world, superiority has to do with far more than technical
merits alone, let alone obscure metaprogramming features which are
irrelevant to the vast majority of programmers.

2. Ruby, which is closer to Lisp than Python, is beginning to eat
Python's lunch. We don't have to debate this either because George has
kindly gave support to it through posting a survey that made this point
quite nicely; Thanks, George!

AKA "if you can't beat them, join them". I don't know if other lispers
would join you in your feeble attempt to steal a bite from Ruby's
current glory (mostly thanks to the admirable marketing around the
overhyped Rails framework), but Ruby is much closer to Python than
either of them is to lisp. In fact, if Python suddenly disappeared,
Ruby would probably be my next stop. Both Ruby and Python are high
level dynamic languages with an emphasis on pragmatic needs, not being
the language of the God(s) (see, I can bring up stupid slogans of
languages too). The similarities between Python and Ruby outweigh their
differences, resulting in very few defections from one to the other, so
nobody's eating the other's lunch. They are both appealing alternatives
to different (overlapping) subsets of the Java/C++/Perl/PHP crowd, and
the choice between the two usually comes down to a subjective
preference about the syntax, the availability of libraries or other
non-technical reasons.

BTW, for the record, I don't have anything particularly against Python
aside from its stupid marketing hype and a bit of jealousy over those

Talk about a well-founded reason to diss a language.

George

 

[Kirk Sluder]

Really? There are no restrictions whatsoever in English syntax and
grammar? None at all?

Of course I didn't say that: What I said was, "To start with,
English does not restrict the expressiveness and
power of the syntax and grammar. People who use the English language
in specific communities and in specific forms of discourse do. The
key to how this happens occurs on another layer of how language
works which is almost always left out of internet discussions of
language: pragmatics."

As an example of the context-specific nature of pragmatics at work,
if I was your reviewer or editor, I'd reject this manuscript. As a
participant on usenet, I'll just point out that you selectively
quoted the antithesis, and deleted my thesis to argue a straw-man.

Of course there are restrictions, *enforced by users of language in
specific communities.* But the English language is quite malleable,
and includes not only the discourse we are currently engaged in, but
the clipped jargon of internet chat and amateur radio, the
chronically passive discourse of academia, the passionate chants of
protesters, and a wide variety of poetic expression.

This is where wannabe critics of "English grammar" fail to
understand the language they claim to defend, much to the amusement
of those of us who actually do study language as it is, rather than
the mythical eternal logos we want it to be.

Languages are (with some trivial exceptions) human creations. The
laws, rules and restrictions of languages are dynamic and dependent
on community, mode, medium and context. Of course, wannabe
grammarians frequently rise up at this point and say that if such is
the case, then there is nothing to prevent <language of choice> from
devolving into a babble of incomprehensible dialects. To which the
easy response is that the benefits of conformity to linguistic
communities almost always outweigh the costs of nonconformist
expression.

And if you want to bring this back around to computer languages, the
benefits of conformity to said linguistic communities tends to
outweigh the costs of doing your own thing. (Unless you can make a
convincing argument that "doing your own thing" is superior.)

So, when I say "sits cat rat" it is not only legal English, but you can
tell which animal is sitting on which?

What is "legal" in English depends on the communities in which you
are currently participating. Likely there is some community in which
such clipped discourse is understood and therefore legal. If you are
talking to me, I'd express my lack of comprehension by saying
"Pardon?" and ask you to rephrase.

But I'm belaboring the point. Of course English has restrictions in
grammar and syntax -- otherwise one could write something in Latin or
Thai or Mongolian and call it English. There are RULES of grammar and
syntax in English, which means that there are possible expressions which
break those rules -- hence there are expressions which one can't write in
legal English.

When you make an "illegal" statement in English, exactly who or what
corrects you?

Is it Zeus, the divine Logos, the flying spaghetti monster, some
platonic ideal?

As you can probably tell, this kind of silliness is a bit of a sore
spot for me. So please by all means, do some basic reading of
linguistics before you continue to engage in such silliness. Or at
least learn to properly quote an argument.

 

[Wolfram Fenske]

If Common Lisp didn't have lexically scoped variables (most Lisp
dialects before Scheme didn't have them) then it would be very
difficult to add that with macros.

Alex Mizrahi already took care of that one.

Do you seriously think lexical scoping is the last word in language
features and that there's now nothing left in other languages that
can't straightforwardly be done in CL?

No. My point was more that Lisp is so flexible that it even allows
you to add something as huge as object orientation without requiring a
change to the compiler. What about Aspect-Oriented Programming, for
example? For Java, you need a new compiler/preprocessor, for Lisp, it
can be implemented as a library [1].

Hint: call-with-current-continuation (also known as call/cc).

You're right call/cc is a problem because you basically can't
implement call/cc without having call/cc. I. e. it requires pervasive
changes to the compiler/interpreter if something like it is not
already in there. Still, Scheme--also a Lisp--has call/cc and was
probably the first language to implement it.

I just don't see a non-messy way to simulate Python generators in CL.
They can be done in Scheme using call/cc though.

Scheme is also a Lisp. So?

Take a look sometime at Hughes' paper on "Why Functional Programming
Matters":

http://www.math.chalmers.se/~rjmh/Papers/whyfp.html

The examples in it are pretty easy to do in Python or Scheme, but I
think not so easy in CL.

Anything in particular? I'd be surprised if the solutions in Scheme
and CL would differ very much because apart from the Lisp-1/Lisp-2
issue and call/cc, Scheme and CL are not that different.


Footnotes:
[1] <http://common-lisp.net/project/closer/aspectl.html>

 

[Kirk Sluder]

That depends. If somebody smart is designing a new programming language,
then no, you get a new programming language.

If somebody not-so-smart is merely hammering the round peg of Lisp into
the square hole of not-quite-Lisp-and-not-quite-anything-else, then yes,
that will be a problem. But apparently, despite the talk of using macros
to implement anything in Lisp, nobody actually does that.

Then what exactly is your argument here?

And BTW:
CL-USER> (defun + (a b))
Lock on package COMMON-LISP violated when setting fdefinition of +.
[Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]

While lisp doesn't prohibit such name conflicts, it does mean that
anyone trying it will generate a fair number of errors each time the
definition is compiled.

I don't know about you, but I'm not talking about VERY restrictive
languages -- I'm using Python, which isn't very restrictive at all. But
even Lisp has some restrictions -- you can't jump to an arbitrary memory
location and treat whatever random bytes are there as executable code, can
you?

Certainly, and I've even pointed out a few that would mediate
against your claim of incompetent programmers being able to
arbitrarily shadow core functions in a way that is invisible to
anyone else.

 

[Kirk Sluder]

.....

Actually the Python example can lose (e.g. leak a file descriptor
temporarily) if output.write raises an exception (prevents
output.close from running). For this reason Python recently
introduced the "with" statement:

with output as fileLike.open():
output.write("Hello world\n")

Here the file gets closed automatically (by running an exit method in
the fileLike class) when the "with" block exits, whether normally or
through an exception.

Ohhh, shiny!

 

[Bill Atkins]

We're shocked.

We are.

(Counting lines? Come on.)

 

[Ken Tilton]

If macros' advanced usage is rare,

Hunh? I have tons of them. Of coure at your level of discourse you will
want to know if those are metric tons or...

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

 

[Ken Tilton]

Steven D'Aprano <[email protected]> schreibt: ....


I disagree. "Too expressive"--what a thing to say.

A sad moment in Usenet discourse... a moment of silence, please.

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

 

[Bill Atkins]

Rightly or wrongly, people fear that Lisp's macros push Lisp closer to
that hypothetical anything-goes language than is healthy. Maybe that's a

Wrongly. And do they? To paraphrase Brian Griffin: "Are you sure it
was people? Are you sure it wasn't...nothing?"

My point isn't whether or not their claims are correct (a "couple" of
macros? really?) but that things like this feed the perception that Lisp
is close to that hypothetical language where anything could be anything.
If anything could be anything, do you really know what (+ 1 2) means
without reading every line of code?

Jesus H Christ. Didn't you just get through talking about how easily
someone can redefine built-ins in Python?

Even something simple like file I/O can be abused. Example: I've seen

Agreed. This is why I've always argued that I/O should never have
been included in programming languages. Too dangerous. And, let's
face it, pretty old-fashioned these days.

(This is an interesting demonstration that any language that allows file
I/O and importing of external program files can always treat functions
as data, even if the language doesn't directly support it. An alternative
would be to keep the strings in memory instead of writing to a module,
then use exec on them instead of importing the module.)

No, it treats code as text. See the difference?

Honest to god, the code really was like that!

Holy cow! How incredible!

Is that an argument against factory functions? Damn straight it is:
they are a powerful tool, and in the hands of morons, they can be
dangerous. Does that mean that languages shouldn't permit higher-order
functions? Not necessarily: all programming tools can be misused, but some
can be misused more easily than others. Power and risk is often a
trade-off, and language designers can't eliminate all risk of stupid
behaviour, but they can design the language to allow whatever level of
risk they believe is acceptable. (E.g. there is no doubt that C's raw
pointers are powerful, but many languages deliberately don't use them.)

Could you please calm down?

The risk of stupid factory functions is small compared to the benefit, but
maybe there is some domain somewhere where the ideal solution is a
language that DOESN'T treat functions as first class objects, deliberately
weakening the language so that a particular class of errors (or stupid
behaviour) just cannot happen. But that language isn't Python.

Could you calm down?

When it comes to Lisp's macros, the perception is that the power is

NB: here, "the" means "Steven D'Aprano's" (the number of meanings
"the" can assume in different contexts is quite surprising).

correspondingly greater, and the risk of abuse even more so. The safe

Don't you get tired of making the same arguments? Because I'm getting
tired of making the same counterpoints.

 

[Kaz Kylheku]

Oh my god! Lisp can echo STRINGS to the interpreter?

Indeed yes, but that's not exactly what's happening here. (And it's not
necessarily an interpreter, by the way. Some Lisp implementations
compile every expression to machine code and branch to it. Corman Lisp,
for instance, doesn't even contain an interpreter).

My point is not to showcase anything about Lisp, but simply to point
out the irony that in the same paragraph in which you are going on
about Lisp being unreadable compared to human written languages, there
appear pieces of parseable Lisp syntax.

Why didn't somebody somebody tell me that!

The answer to that would be: because your being properly informed for
these kinds of debates is your responsibility, and it is assumed.

!!! That *completely* changes my mind about the language!

If you keep up the mind changing, you can maybe trade up to one that
works in perhaps fewer than twenty transactions. (Think: Kyle
MacDonald).

 

[Jon Harrop]

That is a deficiency of Python that doesn't exist in modern FPLs like OCaml,
SML, Haskell, F#...

Omigod. Is that what you meant? You think macros are unnecessary because
one could hard-code their expansions as separate functions? And that
would constitute hiding the boilerplate? What happens when the
boilerplate changes? <game over>

He is correct. When the boilerplate changes, you change your HOF.

 

[Ken Tilton]

^^^^^^^^^^^^^^^^^^^
You keep using that phrase. I don't think it means what you think it
means.

To me in part it means "no one can decide to take away lambda because
they decided they should not have put it in in the first place and then
change their mind and leave it in after I already put a few people on
de-lambdifying our 100kloc system because...", and in part it means
compilation. And it /has/ to have macros.

Perhaps it does in some programming language theory research groups.

haha, the same old straw man, Is it not embarrassing to have to resort
to the same defeated argument again and again?

In
the real world, superiority has to do with far more than technical
merits alone, let alone obscure metaprogramming features ...

Metaprogramming by definition cannot be obscure. Metaprogramming means
programming at a higher level. A higher level means "more productive".
More productive is the essence of pragmatism. QED.

...which are
irrelevant to the vast majority of programmers.

You insult them by suggesting they cannot concieve at a higher level.
Mebbe they could if their language aupported it. Yours does not.

I don't know if other lispers
would join you in your feeble attempt to steal a bite from Ruby's
current glory...

Of course we would. You do not get it. The only thing you guys are
bleating about is greater popularity. Now someone is about to eat your
lunch popularity-wise. Live by the poll, die by the poll. And you held
first place for like a week in language geologic time, taken down merely
because...

(mostly thanks to the admirable marketing around the
overhyped Rails framework)

.... a little hype came along? Wow, your fundamental advantage must have
been about zip, and all derived from things unrelated to syntax. <gasp>

, but Ruby is much closer to Python than

either of them is to lisp. In fact, if Python suddenly disappeared,
Ruby would probably be my next stop. Both Ruby and Python are high
level dynamic languages with an emphasis on pragmatic needs, not being
the language of the God(s) (see, I can bring up stupid slogans of
languages too).

As Graham said, if some pretty good programmers are jumping up and down
about X, mebbe you should take a look at X. Even if assholes like me
piss you off.

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

 

[Jon Harrop]

If that's the best example of what macros can be used for, frankly I'm
unimpressed. Yes, I can see some benefit. But I don't see that the benefit
is worth the added complexity. Maybe there are more complex tasks that
macros are better suited for.

You both seem to be trying to implement a pattern match. It would probably
be productive for you to compare Python and Lisp to languages that have
pattern matching.

For example, look at the symbolic simplifier here:

http://www.ffconsultancy.com/free/ocaml/symbolic.html

or the interpreter here:

http://www.ffconsultancy.com/free/ocaml/interpreter.html

Implementing this kind of stuff in Python is probably a nightmare. At least
you can address Lisp's deficiencies with macros...