Python syntax in Lisp and Scheme

[Alex Martelli]

Jon S. Anthony wrote:
   ...
>> > Can someone write a nifty Python hack to figure out how many times
>> > Lispniks have tried to get Alex to explain how macros are any different
>> > than high-order functions or new classes when it comes to The
>> > Divergence Problem? I love that we have given it a name, by the way.
>> 
>> The very 'feature' that was touted by Erann Gat as macros' killer
>> advantage in the WITH-CONDITION-MAINTAINED example he posted is the
>> crucial difference: functions (HO or not) and classes only group some
>> existing code and data; macros can generate new code based on examining,
>> and presumably to some level *understanding*, a LOT of very deep things
>> about the code arguments they're given.
> 
> Are you really this dense?  For crying out loud - functions can
> generate code as well and just as easily as macros.  In fact macros
> are just functions anyway so it really should go without saying.

These assertions may hold in your favourite corner of the world, but
they surely don't in mine.  So, cry out just as loud as you want, and
keep insulting me at will, but you will hardly change my opinion: functions
_compute and return a result_ (which may be another function, but that's a 
detail) -- they cannot in any way break nor bend the syntax of the language 
[in non-pure-FP languages, including Python and lisp, functions can also 
have side effects, but that's another debate -- since c.f.programming is 
not in the list of groups targeted by this sub-sub-thread we probably don't 
need to pursue it].  Macros can.  Even Gat asserts that "in MOST cases" the
divergent language one builds with macros is a superset of lisp -- which
means it needs not be.  Without macros, you cannot alter the syntax and
make the language in which you embed your functions a different one,
perhaps not even a superset of the one you started with.  You can of
course implement a _separate_ language (hey, most language implementations
around today are probably coded in C, even for languages that have nothing 
at all to do with C), but that's quite different from mixing language and 
meta-language freely.


>>  If all you do with your macros is what you could do with HOF's,
>> it's silly to have macros in addition to HOF's -- just
> 
> No it isn't, because they the mode of _expression_ may be better with
> on in context A and better with the other in context B.

I care about "mode of expression" when I write poetry.  When I write
programs, I care about simplicity, clarity, directness.


>> MTOWTDItis encouraging multiple different approaches to solve any given
>> problem -- this, of course, in turn breeds divergence when compared to a
> 
> Actually it breeds better solutions to problems.  If you don't
> understand this, you will never understand much of anything about good
> problem solving.

Right: that's why I'm a decently-paid consultant and in my spare time write 
best-selling-in-niche books -- because I don't understand much of anything 
about good problem solving.  Flailing around between a zillion divergent
approaches is clearly the One True Way of problem-solving: that's why
perl, which glorifies that multiplicity, r00lez, right?

Meanwhile, while the perl-using team is halfway through the heated debate 
among the bazillion oh-so-EVER-clever and dazzling ways, the plodding, 
pragmatical, simplicity-oriented python-using team has delivered a clear, 
simple, maintainable solution and is well on its way towards the next one.

Easy pop quiz: of the designers of the languages Perl and Python, which
one was born in South California, which one in the Netherlands...;-?  [more
later about such geography-based stereotypes...]

Downside: nobody really gets entitled to feel smarter-than-thou for having
unearthed a solution so obscure it had escaped all the others; if you're in
the programming game for ego-boosting, a cleverness-requiring language
with a built-in competition for "stardom" may suit you better.  If you're 
into it to actually solve problems, egoless programming may be ok, though.

[[ back to stereotypes: now, lisp is clearly in-between, its designer being 
from Massachussets.  And just for a little self-satire -- if a language had
an _Italian_ designer, it probably would be little use for _programming_,
though it would likely be good for cuisine, fashion, major-scale graft, and  
seducing beautiful women [though come to think of it, I didn't do all that 
badly with Python on the latter -- Hi Anna!-)]  ]]


>> Oh, and if you're one of those who disapprove of Gat's example feel free
>> to say so, but until I hear a substantial majority denouncing it as
>> idiotic
> 
> At the moment the only thing I am willing to denounce as idiotic are
> your clueless rants.

Excellent!  I interpret the old saying "you can judge a man by the quality 
of his enemies" differently than most do: I'm _overjoyed_ that my enemies 
are the scum of the earth, and you, sir [to use the word loosely], look as 
if you're fully qualified to join that self-selected company.


Alex