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

[Douglas Alan]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> 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.

I'm aware, but there were various different mapping functions.  "map",
as opposed to "mapcar" didn't return any values at all, and so you had
to rely on side effects with it.

> It was sort of before my time but I have the impression that Maclisp
> was completely dynamically scoped and as such,

Yes, that's right.

> it couldn't cleanly make anything like generators (since it had no
> way to make lexical closures).

That's right, generators would have been quite difficult to do in
MacLisp.  But a Lisp Machine (with stack groups) could have done them,
and did, with or without 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.

Right -- I wrote "iterators", not "generators".

> You could do it with call/cc but SICP just uses ordinary closures to
> implement streams.

Yes, that's right.

>> 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) ;-).

Good point!  But I just love lambda -- even when I'm just using it as
a NOP....  (Also I couldn't remember the syntax for accessing the
function property of a symbol in MacLisp.)

> 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.

Right, but each sequence type had it's own corresponding mapping
fuctions.

>> >     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.

Right.  OO on primitive data types is kind of hard in a non OO
language.  So, when writing an application in MacLisp, or Lisp Machine
lisp, I might have had to spend a bit of time writing an application
framework that provided the OO features I needed.  This was not
particularly hard to do in Lisp, but surely not nearly as nice as if
they had standardized such things.  This would not be particularly
difficult to do, other than the getting everyone to agree on just what
the interfaces should be.  But Lisp programmers, are of course, just
as recalcitrant as Python programmers.

>> 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,

And in Python's case, the reference manual is just an incomplete
description of the features offered by the implementation, and people
revel in features that are not yet in the reference manual.

> though until fairly recently it's fostered a style of relying on
> various ugly CPython artifacts like the reference counting GC.

That's not ugly.  The fact that CPython has a reference-counting GC
makes the lifetime of object predictable, which means that like in
C++, and unlike in Java, you can use destructors to good effect.  This
is one of the huge boons of C++.  The predictability of lifespan makes
the language more expressive and powerful.  The move to deprecate
relying on this feature in Python is a bad thing, if you ask me, and
removes one of the advantages that Python had over Lisp.

> Lisp accumulated a lot of cruft over the decades and it kept some
> baggage that it really could have done without.

Indeed -- true of most languages.  Of course, there have been quite a
few Lisp dialects that have been cleaned up in quite a few ways (e.g.,
Dylan), but they, of course, have a hard time achieving any
significant traction.

> I don't think Python's designers learned nearly as much from Lisp as
> they could have, and Python has suffered because of it.

Amen.

> Lisp still has an awesome beauty in both the CL and Scheme
> incarnations.

Indeed.

> 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.

Lisp is more like The Beatles.

And it's not bygone -- it's just nichified.  Lisp is forever -- you'll
see.

|>oug