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

[Douglas Alan]

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

> Nonetheless, picking on and characterizing Tim's statement as
> anti-flexibility and un-scientific is to me writing of a sort that I
> would not tolerate from my middle-school child.

Now it is you who are taking Sussman's comments out of context.
Sussman does not claim that Python is "un-scientific" -- he merely
holds it up as a example of canonical engineering that eschews the
kinds of flexibility that is to be found in biological systems and in
the practice of science.  In this regard, Sussman is merely
criticizing engineering "best practices" in general, not Python in
specific, and is arguing that if we want to engineer systems that are
as robust as biological systems then we need to start exploring
radically different approaches to software design.

> Python is an algorithm language and a tool used to engineering
> information systems, which is something different.  The next
> sections are about exploratory behavior.  Languages do not 'behave',
> let alone 'explore'.

I think you are missing the point.  Sussman is making a broad
criticism of software engineering in general, as it is understood
today.  The essay in questions was written for a graduate-level MIT
computer science class that aims to explore potential avenues of
research into new languages and approaches that encourage and
facilitate more robust software systems.  As good as Python is, it is
still largely an encapsulation of the best ideas about software
engineering as it was understood in the early 80's.  We're now 20+
years on, and it behooves our future Computer Science researchers to
consider if we might not be able to do better than we could in 1984.

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

Python most certainly does *not* have the type of flexibility that he
is talking about.  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.  Although you might be
able to cobble something like this together in Python, it would end up
being very cumbersome to use.  (E.g., Guido wrote an essay on doing
multiple dispatch in Python, but you wouldn't actually want to write
Python code that way, because it would be too syntactically
cumbersome.)  In dialects of Lisp (such as Scheme), however,
subsystems to explore such alternative programming models can be
written completely within the language (due, in part to their syntax
extension facilities).  This is how the Common Lisp Object System came
to be, for instance.  CLOS supports all sorts of OO stuff that even
Python doesn't, and yet Lisp without CLOS isn't even an OO language.

> The general problems of software inflexibility that he mentioned in
> a previous section have nothing specific to do with Python.

Right.  And he never said they did.

> When he gets to solutions, one long section (page 13) somewhat
> specific to languages, versus applications thereof, is about
> extensible generic operations "where it is possible to define what
> is meant by addition, multiplication, etc., for new datatypes
> unimagined by the language designer."  Well, golly gee.  Guess what?
> Not only is Python code generic unless specialized (with isinstance
> tests, for instance), but it is highly extensible for new datatypes,
> just as Sussman advocates.  There is a special method for just about
> every syntactic construct and builtin function.  And 3.0 may add a
> new generic function module to dispatch on multiple arguments and
> possibly predicates.

You didn't read the paper very carefully.  Sussman points out that
traditional OO languages are up to this sort of stuff to some extent,
but not to the extent which he thinks is required to solve future
challenges.  He things, for instance, that predicate dispatching,
backtracking, and first-class continuations will be required.

|>oug