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

[Douglas Alan]

Neil Cerutti <horpner at yahoo.com> writes:

>>> But why is the ability to abstract syntax good?

>> It allows the community to develop language features in a
>> modular way without having to sully the code base for the
>> language itself.  

> That's not an advantage exclusive to macros, though.

No, but macros are often are necessary to be able to implement such
features in (1) an efficient-enough manner, and (2) in a manner that
is syntactically palatable.  E.g., PEAK for Python implements multiple
predicate-based dispatch, but you have to define the predicates as
Python code within strings.  That's not very pretty.  And probably not
very fast either.  Though Python, in general, is not very fast, so
perhaps that doesn't matter too much for Python.

> Some time last week I found myself writing the following thing in
> Python:

> [...]

> I deleted it right after I tried to use it the first time. Using it
> is more cumbersome than simply repeating myself, due to syntax
> limitations of Python.

See what I mean!

> And other, more bizarre syntax extensions have been perpetrated.
> mx.TextTools uses Python tuples to write a completely different
> programming language.

Sounds like "the Loop macro" for Lisp, which implements a mini sort of
Cobol-like language just for coding gnarly loops within Lisp.  It
turns out that when restricted to just coding gnarly loops, this is a
much better idea than it sounds.

Yes, you can do this sort of thing, sort of, without macros, but, as
we discussed above, the result is often ugly and slow.

>> A prime example of this is how CLOS, the Common Lisp Object
>> System was implemented completely as a loadable library (with
>> the help of many macros) into Common Lisp, which was not an OO
>> language prior to the adoption of CLOS.

> Is there a second example? ;)

Why yes, now that you mention it: the Loop macro.  Also, in many
implementations of Lisp, much of the core language is actually
implemented using macros against an even smaller core.  Keeping this
inside core as small as possible helps make the implementation easier
to construct, maintain, and optimize.

Also, way back when, when I used to code in Maclisp, I implemented my
own object system and exception handling system in macros, as Maclisp
had neither of these off the shelf.  The object system took me a
couple of weeks to do, and the exception handing system a couple of
days.  They worked well, looked good, and ran fast.

> Seriously, maybe Python looks like 'blub' (thanks, Paul Graham), to
> the skilled Lisp user, but it makes a lot of other languages look
> like 'blub', too, including, sometimes, Lisp: Lisp has to 'blub'
> generators.

Actually, Scheme has first class continuations, and with continuations
and macros you could easily implement generators, and I'm sure someone
has.  Whether such a library has been widely adopted for Scheme,
though, I have no idea.

You're probably right about Common Lisp, which is probably missing
generators due to efficiency concerns.  Lisp Machines had "stack
groups", which were basically the same thing as generators, but making
a call to a stack group was 100 times slower than a normal function
call.  This meant that people generally didn't use them even when it
would make their code more elegant, due to the huge performance cost.

Now, since Python is like 100 times slower than Common Lisp anyway,
you don't notice this performance issue with Python's generators.
They just happen to be only as slow as the rest of Python.

|>oug

"Lisp is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days, even if you never
actually use Lisp itself a lot." -- Eric Raymond