Python syntax in Lisp and Scheme

[Alex Martelli]

Kenny Tilton wrote:
   ...
>> Doug Tolton <doug at nospam.com> wrote previously:
>> |Yes, this discussion is frustrating.  It's deeply frustrating to hear
>> |someone without extensive experience with Macros arguing why they are
>> |so destructive.
   ...
> Hey! No pulling rank! :) Actually, I think  we heard Mr. Martelli say
> something along these lines at one point, tho I grok that he does know
> his stuff.  As for having "a better understanding", hmmm, check your
> lotus, I think you'll find something in there about Beginner's Mind.

Doug was not talking about understanding, but experience.  I've had
such experience -- perhaps not "extensive" enough for him? -- and I
have personally experienced and suffered the problems.


> Alex reports his experience of The Divergence Problem and blames macros.
> Hell, I worked in Tall Buildings for years. I saw Divergence,
> Convergence, /and/ the dread Regurgitation Problems everywhere I went.
> No macros, tho, just groups of programmers.
> 
> So I think the groups are the problem.

I never claimed that without macros there would be no possible problems
whatsoever.  Human biology guarantees that such sociological problems
remain possible.  However, technology aspects, as well as cultural ones,
can either ameliorate or exacerbate the issues.  Python's overall culture
of consensus and simplicity matters: at a BOF as OSCON, somebody was
asking "...so I don't know if I should just do the simple thing here or
rather do something clever..." and the audience immediately gave their
feedback -- if you think of it as "something clever", _don't do it_.
(Not in production code, not in code that you AND more relevantly many
others will have to maintain, enhance, and change for years to come).

Are you familiar with the "JAPH" idea, those bazillion clever ways that
Perl programmers have dreamed up to emit the string "just another perl
hacker" in delightfully contorted ways?  Well, somebody once asked how
a Pythonista would go about it -- and the answer was unanimous:
    print "Just another Python hacker"
Sure, this will get you no kudos for cleverness, but the point is that
cleverness does NOT garner kudos among Pythonistas.  Simplicity, clarity,
explicitness, directness -- these are the community's core values.  Do
we all always live by them?  No way -- we're not saints, just practical
guys trying to get our jobs done -- and perhaps make the world a little
better along the way.

Technological aspects interplay with the cultural ones.  Again speaking
in terms of ideals and targets, I quote Antoine de Saint-Exupery:
"La perfection est atteinte non quand il ne reste rien à ajouter, mais 
quand il ne reste rien à enlever." (perfection is achieved not when
nothing is left to add, but when nothing is left to take away).  Now,
since "practicality beats purity", one doesn't (e.g.) remove 'if' just
because it can reasonably be substituted by 'while' -- we're not talking,
in fact, about truly minimalist practice.  But the only apparently
irreducible use of macros would appear to be in (some form of) code
that "reasons about itself" (not just by simple reflection and
introspection, quite easy to achieve without macros, but in that
"with-condition-maintained" example which was apparently [or allegedly]
able to analyze and modify reactor-control code to affect the reactor's
temperature limits).  Do I need or want such exoterica in the kind of
code that I am interested in writing, and helping others write?  No way:
such "creative", deep merging of discourse and meta-discourse does not
appear to be at all necessary in these endeavours -- and if it not
strictly necessary, I would MUCH rather use a simpler, lighter-weight
tool that does not support it.  When I need to modify (e.g.) some
class's constructor at runtime, I can do it by such blazingly obvious
code as
    someclass.__new__ = staticmethod(costructor_implementation)
though the Lisp'er originally proposing such needs, in an attempt to
show how complicated Python's approach was, used a hugely messy call to
type.__setattr__ with a weirdly and unjustifiably long lambda in it.

Won't fly, friends.  We're simple, down-to-earth folks, doing simple,
down-to-earth things.  I suspect some kind of 10/90 rules apply: our
simple tools may be barely 10% of what CL has got, but they cover the
needs arising in 90% of applications.  (Maybe it's 15/85 or whatever:
no, I don't have scientific studies in the matter to quote so you
can exert your ingenuity at shooting them down:-).  When we need to
process some specialized language we may use roughly-traditional parser
technology, keeping language and meta-language separated, rather than
embed and entwine them inside each other.

My perhaps-not-extensive-enough experience with macros showed them
being used to merge language and meta-language -- in widely different
ways in different labs or even within a given lab -- while at the
same time other firms were using languages without macros (APL and
variants thereof) and processing them with different and separate
metalanguages AND thereby managing to achieve better (intra-firm, at
least) cooperation.  As "adventures in programming", those glorious
lisp-dialects-cum-hardware-description-languages-inside-them were,
no doubt, a hoot.  For somebody looking for a more productive way to
design chips, and particularly to foster cooperation in this design
task, they looked (and in retrospect still look) sub-optimal to me.

The macros ended up being used to bend and stretch the general
purpose language to express specialized issues (about hardware design,
in that case) which it was not optimally suited to express -- and
since it WAS a case of bending and stretching, it was inevitable that
each different lab and faction would stretch and bend in divergent
directions.  The computer-scientists in question were no doubt happy
as larks with their toys and in some cases their shiny new lisp
machines (I think TI ended up making a LM of their own a bit later,
but that was after my time); us engineers weren't _quite_ as happy,
though.  And the chips didn't get designed as well, nor as fast...


Alex