Dijkstra on Python

[James J. Besemer]

Al Vining [and many others] write:

> "There should be one -- and preferably only one
> -- obvious way to do it."

I have a problem with this particular particle of Python dogma.

My chief problem is that it's every bit as meaningless and ridiculous as
when Larry Wall promotes the "other" way of doing things.

All of Wall's ridiculous talk of postmodern languages notwithstanding, the
simple fact of the matter is that there IS more than one way to solve most
problems in most any modern programming language.  Actually, when Wall et
al. boasts about Perl's "unique" ability in this regard, if you really read
the examples, at bottom, they're usually just saying there are different
ways to implement a solution.  Fact of the matter, in most of their examples
Perl generally doesn't offer any benefit vs. Python.

E.g., consider the implementation of Sets in Python (or Perl).  You could
use dictionaries (as many propose) or plain lists or bitmaps of big
numbers.  If sets are truly gigantic you may want to use b-trees or a
persistent Zope DB.  You probably would encapsulate the abstraction in a
class but that's not necessary for simple implementations.  Even in C, you
have your choice of bitmaps, arrays of numbers or pointers to objects, or
higher order data structures -- only it's more work than in Python or Perl.

So, plainly, "there's more than one way" to solve most problems in any
modern programming language.

This minimalist philosophy does perhaps have some merit in, say, designing
the syntax of the language.  E.g., Perl goes overboard IMO with the various
ways to test a condition:

    if( x ){ y }
    y if x;
    x && y;
    x || y;

... and who knows what all else.  So Python can be viewed as superior to
Perl in this sense.

However, Python itself breaks its own rules at the low level; e.g. with

    for
    while
    map, et al.
    list comprehension

... Python offers at least 4 redundant ways to iterate over a collection.

Now, IMO this is a GOOD thing, not a bad one.  Having a narrow variety of
choices for things like this is good for the programmer.  Larry Wall makes a
small point in that productivity will be higher if the language already
provides the mechanism the programmer first thinks of or is most familiar
with.

With bigger problems, the variety of implementation choices increases
exponentially.

Thus, in practice, this particular rallying call is every bit as meaningless
as Perl's.

Regards

--jb



--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com