Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Steven D'Aprano <steven at REMOVE.THIS.cybersource.com.au> writes:

> On Thu, 21 Jun 2007 15:25:37 -0400, Douglas Alan wrote:

>> You are imagining something very different from what is proposed.
>> Lisp-like macros don't allow "anything goes".

> Provided people avoid doing anything "which would be considered very 
> rude" (your own words).

No, Lisp macros are entirely contained within a begin and end
delimiter, which is introduced by the name of the macro.  E.g., here
is a real example of some Lisp code that I wrote aeons ago using the
loop macro:

   (loop for index from 0 below size
          for element in contents
          do (store (arraycall t array index)
                    element)
          finally (return (make-htable BUCKETS size
                                       ARRAY array
                                       KEY-PRINTER key-printer
                                       ITEM-PRINTER item-printer)))))

The syntactical extensions supported by the loop macro can only begin
starting immediately after "(loop " and they end with the matching
closing parenthesis.  There's no way in Lisp to write a macro whose
syntactical extensions can extend outside of this very explicitly
delimited scope.  Nor can they mess with Lisp's tokenization.

> Python already allows me to shoot myself in the foot, if I wish. I'm 
> comfortable with that level of freedom. I'm not necessarily comfortable 
> with extensions to the language that would allow me the freedom to shoot 
> myself in the head.

Lisp macros don't let you shoot yourself in the head -- only in the
foot.  Being able to do

   True = False

is being able to shoot yourself in the head.  And Python certainly
lets you do that.

> I would need to be convinced of the advantages, as would many other
> people, including the BDFL.

The proof is in the pudding for anyone who has seen the advantages it
brings to Lisp.  As Paul Graham points out, it's hard to look up and
see the advantages of what is up there in a more powerful language.
It's only easy to look down and see the disadvantages of what is
missing from a less powerful language.  To understand the advantages,
one has to be willing to climb the hill and take in the view.

> It isn't clear exactly what functionality a hypothetical Python macro 
> system would include,

It should be largely equivalent to what is provided by Lisp.
Admittedly this is a bit more difficult for Python, as Lisp's syntax
is eminently suited for macros, while Python's is not.  One would
probably want to take a look at how Dylan solved this problem, as
Dylan implements Lisp-like macros even though it has an Algol-like
syntax.  Or you could look at the paper I wrote (for a class) on the
design of Python-like language that would support macros.  My paper is
only a rough sketch, however.

> let alone whether the benefits would outweigh the costs,

They pay off in boatloads in the Lisp community.

> (It took Lisp half a century and millions of dollars of corporate
> funding to reach where it is now.

Ummm, not really.  Lisp hasn't really changed very much since the late
'70s, and prior to that, most of the work on Lisp was just done in a
few university labs (e.g., MIT) and at Xerox Parc.  Any work and money
that has been spent on Lisp since then has just been in trying to
market it, or standardize it, or design hardware suited to running it
faster, or build better development environments for it, or optimizing
compilers, etc.

Lisp, itself, is rather easily to implement.  (Getting it to run as
fast as C is more of a challenge, what with good garbage collectors
and all being non-trivial to implement, but performance doesn't seem
to be much of an issue for the Python community.)  I made my own Lisp
implementation in C++ in two weeks.  (Not really a production dialect,
but it worked.)  Kyoto Common Lisp, which was definitely a production
implementation, was implemented by two people in a couple of years.
(It compiled Common Lisp into C.)

|>oug