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

[Douglas Alan]

"Terry Reedy" <tjreedy at udel.edu> writes:

> | I think you are missing the point. Sussman is making a broad
> | criticism software engineering in general, as it is understood
> | today.

> On the contrary, I understood exactly that and said so.  *My* point
> is that in doing so, he made one jab at one specific language in a
> herky-jerky footnote (a sentence on systems design philosopy, one on
> Python, one on physics) that I consider to be at least misleading.
> And so I feel the essay would be better without that wart.

The footnote is only misleading if you read it out of the context of
the essay.  And Sussman clearly only picked on Python, in specific,
because Python is the only language for which this facet of current
engineering "best practices" has been actually been eloquently
committed to paper.  There is nothing in the essay to suggest that
Python is any worse than any other popular production programming
language with respect to the issues that Sussman is addressing.

> | > So Python seems to have the sort of flexibility that he implicitly
> | > claims it does not.

> | For instance, one of the things that he talks about exploring for
> | more robust software systems is predicate dispatching, which is an
> | extension of multiple dispatch.

> Which I obviously read and responded to by noting "And 3.0 may add a new 
> generic function module to dispatch on multiple arguments and possibly 
> predicates."

So, that's great.  Python will once again adopt a wonderful feature
that has been usable in Lisp implementations for 20 years now.  (This
is a good thing, not a bad thing.  I just don't like so much the
having to wait 20 years.)  The problem with Python's model is that you
have to wait for a rather centralized process to agree on and
implement such a feature.  In the Lisp community, *anyone* can easily
implement such features in order to experiment with them.  This allows
much more experimentation to take place, which is one of the reasons
why Gerry Sussman brought the scientific community into the
discussion.  The ability for people to readily conduct such
experiments benefits me, even if I personally never want to write a
macro or implement a language feature myself.

Related to this is the fact that it's much harder to be able to get
new language features right, unless you can get them wrong a few times
first.  It's no accident that when Python adds features from Lisp and
Haskell, etc., that it does a pretty decent job with them, and that's
because it was able to learn from the mistakes and triumphs of others
who tried out various good and not-so-good language features in other
languages first.

The downside of Python's approach is that it makes Python not such a
very good language for exploring these potentially useful features
within Python in the first place.  The Python community has to watch
what is going on in other programming language communities and then
raid these communities for their good ideas.

Perhaps this is not a bad thing if people just want Python to be a
programming language for getting real work done.  But, personally, I
would prefer to have a language that works well for *both* production
work *and* for exploration.  At the moment, neither Python nor Scheme
fits my bill, which is why I would like to see a programming language
that combines the best of both worlds.

> | Although you might be able to cobble something like this together
> | in Python, it would end up being very cumbersome to use.

> Well, talk about shooting down innovations before they happen.
> Perhaps you could wait and see what Eby and others come up with in
> the next year.

I was referring to implementing these sorts of features within Python
(i.e., by writing Python modules in Python to support them) -- not
waiting for Python 3000, which may or may not have the features that I
want.

> [from your other post]
> | A good multimethod system, e.g., would make Python a significantly
> | nicer language for my purposes, for instance.

> Or better yet, read http://www.python.org/dev/peps/pep-3124/
> (tentatively approved by Guido, pending actual code) and perhaps
> some of the discussion thereof on the Python-3000 dev list and help
> design and code something that would be at least usable if not
> 'good'.

Thanks for the pointer -- I will eagerly check it out.

> | You didn't read the paper very carefully.

> Because I don't agree with you?

No, because he clearly is not criticizing Python, in specific, and the
mention of Python is due *solely* to the fact that Python just happens
to mention, in one of its manifestos, a principle that would be
generally held to be true as a current best engineering practice.  I
feel that a careful reading of the paper would have made this
apparent.

Also, I think it a bit counterproductive to get all up in arms about
such minor jabs.  Python is strong enough to withstand all sorts of
valid criticism, as is Scheme.  Even things that are excellent can be
made better, and also the time always eventually comes, as long as
human knowledge progresses, for even the greatest of artifacts to be
replaced with something better.

|>oug