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

[Paul Rubin]

Douglas Alan <doug at alum.mit.edu> writes:
> I will certainly admit that Lisp programmers at the time were (and
> likely still are) much more enamored of mapping functions than of
> iterators.  Mapping functions certainly get the job done as elegantly
> as iterators most of the time, although I would agree that they are
> not quite so general.

In the Maclisp era functions like mapcar worked on lists, and
generated equally long lists in memory.  It was sort of before my time
but I have the impression that Maclisp was completely dynamically
scoped and as such, it couldn't cleanly make anything like generators
(since it had no way to make lexical closures).

> Scheme, on, the other hand, at least by idiom, has computation
> "streams", and streams are equivalent to iterators.

No not really, they (in SICP) are at best more like class instances
with a method that mutates some state.  There's nothing like a yield
statement in the idiom.  You could do it with call/cc but SICP just
uses ordinary closures to implement streams.

> The canonical way to do this in Lisp would be something like:
>    (mapcar (lambda (x) (blah x)) xs)

At least you could spare our eyesight by writing that as 
(mapcar #'blah xs) ;-).  The point is that mapcar (as the name 
implies) advances down a list using cdr, i.e. it only operates
on lists, not general iterators or streams or whatever.

> >     x = xs[key]
> 
> I'm not sure what you are asserting?  That Common Lisp doesn't have
> hash tables?  That's certainly not the case.  Or that it doesn't
> provide standard generic functions for accessing them

The latter.  Of course there are getf/setf, but those are necessarily
macros.

> A language like Python, which is defined by its implementation,
> rather than by a standard, can move much more quickly.  This debate
> though is really one more of what is the best model for language
> definition, rather than one on what the ideal language is like.

Python is not Perl and it has in principle always been defined by its
reference manual, though until fairly recently it's fostered a style
of relying on various ugly CPython artifacts like the reference
counting GC.

Lisp accumulated a lot of cruft over the decades and it kept some
baggage that it really could have done without.  I don't think
Python's designers learned nearly as much from Lisp as they could
have, and Python has suffered because of it.  Lisp still has an
awesome beauty in both the CL and Scheme incarnations.  But it's like
listening to Elvis music--even if it can still get you dancing, at the
end of the day it's still a reflection of a bygone culture.