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

[Douglas Alan]

Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:

> 	Macros? Unfortunately to my world, macros are those things
> found in C, high-powered assemblers, and pre-VBA Office. As such,
> they do anything but keep a language small, and one encounters
> multiple implementations of similar functionality -- each
> implementation the pride of one person, and abhorred by the person
> who now must edit the code.

Comparing C macros to Lisp macros is like comparing a Sawzall to a
scalpel.

Regarding having enough rope to hang yourself, the same claim can be
made about any language abstraction mechanism.  E.g., classes are to
data types as macros are to syntax.  You can abuse classes and you can
abuse macros.  Both abuses will lead to abhorring by your
collaborators. And either abstraction mechanism, when used properly,
will result in more elegant, easier to read and maintain code.

Both abstraction mechanisms also allow language feature exploration to
occur outside of the privileged few who are allowed to commit changes
into the code-base for the interpreter or compiler.  I think that this
is one of the things that Gerry Sussman might be getting at when he
talks about how science works.  (Or at least that's what I would be
getting at if I were in his shoes.)

In the Lisp community, for instance, there have been lots of language
features that were implemented by people who were not part of the core
language development clique, but that were later widely adopted.
E.g., the Common Lisp OO system with mutimethods (CLOS), and the
"loop" macro.  These features didn't require any changes to the core
language implementation, and so you can see that Lisp-style macros are
also a huge modularity boon for language implementation.

|>oug