Dijkstra on Python

[James J. Besemer]

Skip Montanaro wrote:

> You fail to see all the times it's been applied
> successfully because those proposed features never made it into the
> language.  Guido applies it routinely.

I agree Python's primary appeal is that it's fairly well designed and
consistent.

But to me this is simply good design unrelated to the slogans.
It's more akin to common sub expression elimination or normalizing
your database tables than an act of genius.

This is in stark contrast to the crock of random shit that makes
up PERL.  Perl was BADLY designed by hackers who were pretty
friggin' clueless about even simple language design matters.  IIRC
Wall admits he got started by hacking up C-Shell and never looked
back.

> If he didn't, I suspect we'd have a
>
>     do:
>         ...
>     until: ...
>
> or
>
>     repeat:
>         ...
>     while: ...
>
> construct (or some other variant),

HORRORS!

THIS is precisely an example (which I mentioned) where IMO
the slogan does not apply.  Adding a standard construct like do-until
certainly would not create "bloat" where it did not already exist.
It would not be hard to implement.  It would not create a burden
to understanding code.  Practically everybody here already knows
what it means.  For those who don't add a new section to the
language ref between sections 7.2 and 7.3.  Ten or 12 lines
of text and end of issue.

It's a FAQ and a frequent question here precisely because most
programmers expect it.  Y'all spend more time explaining why
it isn't there than it would cost to implement.  The greater burden
for people learning the language is puzzling over the fact that it's
NOT here, not that it would be hard to learn.

Thus here's a case where IMO people echo the slogan without
really understanding the Philosophy.  Rather than say, "that
sounds reasonable," they substitute the slogan for a rational
analysis.  And that's just bullshit.

A switch statement is a slightly better argument for your side.
I appreciate that it would be harder because nothing from any
other language I know of carries directly over.  Thus it requires
some original design and language designers should always be
extra cautious when they're being inventive.  Several perfectly
adequate solutions come to mind but I concede none are significantly
better than if/elif/else.  Too, switch opens several controversial
cans of worms (e.g., fall-through vs. automatic break) that maybe
never can get put back into the can.  I personally put switch on
the cusp -- something certainly not so big and complicated that
it would be hard to do, mess up the language or confuse the
newbies; but also something with complications -- I can see
there may well be bigger fish to fry.  But to simply dismiss
it as "more than one way" is not right.

And FWIW, I don't think I ever openly advocated switch.

And what IF these two reasonable additions had made the cut?
You talk like it would be an awful thing when it really wouldn't
be a big deal at all.  There's still the thousands upon thousands
of other things that still (rightly) got left out.

> Both have been asked for many
> times.  In fact, there's even a PEP for a switch statement.

I know.  In my experience, FAQs often indicate a problem that
should be addressed.  (And PEPs in a way are a kind of FAQ.)
Sometimes the problem can be adequately addressed by the doc
and other times they require a more fundamental change.

I think the Python community is too complacent about blithely
dismissing some of the Most FAQs when perhaps the underlying
decision should be reconsidered.

I submit if someone came out with, say, a Python++ that added
the dozen  or so most often requested features, it would attract a
significant following, both from existing Python users and from
prospective newcomers.  I've researched this just a little and near
as I can tell just about all of the most frequently requested items
could be added to the language in a strictly upward compatible
fashion and they could be implemented in the compiler without
changing the VM.

> I believe the
> fact that you sometimes find overlapping language constructs can be
> attributed to one of the following two reasons:

>     1. They overlap in some respects, but their natural "domains" really
>        don't.  This applies to your for/while/list comprehension/map
>        example.  BTW, you don't really need any of these iterative
>        constructs.  After all, we have functions and the language supports
>        recursion.  I say, let's get back to basics.  ;-)

You guys are the ones arguing minimalist, not me.  I only point to
existing redundancy as evidence the slogan doesn't really apply.

People cite the slogan as reason to deprecate and eventually remove
lambda.  (Not me.  I LIKE lambda.)  I just say the lambda haters
should then apply same argument to list comprehensions because
they're the same domain and they're even less useful because
they're so much slower than the existing constructs.  If it's healthy
for us to manually spell out do-while, why not list comprehensions?

I do not object to overlapping language constructs.  I think it's perfectly
normal and A GOOD THING.  It's even more to be expected in a
high level language such as Python.  I think it's unavoidable.  Within
reason, the costs are negligible and the benefits are significant.

But that perspective makes the inclusion of this or that PARTICULAR
feature that much more arbitrary and it makes the slogans seem all that
much more vapid.

>     2. Language design being what it is (an art rather than a science) and
>        Guido's time machine notwithstanding, even the Dutch don't have a
>        crystal ball to look into the future to see what the perfect language
>        is.

So mistakes are inevitable.  I agree.  Again my present complaint is not
the redundancy, per se, but rather to the inappropriate application of the
slogans -- either to justify removing some useful existing function or to
justify keeping out some genuinely useful new one.

> Generally, Guido's gotten it right. That's why so many of us
> enjoy using Python.

I absolutely agree.  Even with the benefit of hindsight, there are not
very many things I would propose to change.

However, you all are deluded to think Python is this cute, simple little
language, particularly if you take into account (as you should) all the
built-ins and important library modules.  Actually Python's excellent
design and ease of learning misleads people into thinking it's a lot
smaller and simpler than it really is.

I have a collection of pocket reference cards/booklets.  They all do
a decent and complete job of summarizing the languages in question.
Discounting the summary of all Linux commands, Python is by far
the longest one:

    Pages    Language
    174      Linux Command Summary
    124      Python
     97      XML
     89      Java Script
     85      English (Strunk & White)
     48      Perl 5
     30      C++ (c lang, c++ lang, stdio lib)
     26      Korn Shell Reference
     18      Perl 4
     10      Awk

The Python doc is more than twice the length of Perl5 and about 4X
the size of C++.

A similar pattern emerges from the seminal books on my bookshelf:

    Pages    Language
    880      Lutz' Programming Python
    465      Wall/Schwartz Programming Perl
    398      Beazley's Python Essential Ref.
    350      SQL Instant Ref.
    328      Stroustrup's C++
    272      K&R's C
    106      Lisp 1.5

All the books cover the base language plus key library modules.  All
include numerous examples.  In my experience, each is sufficient
to become proficient in the language, as they were in fact the principal
books I relied on when learning and using each language (augmented
with pocket references once I got started).

You can argue that the Python books always are more complete and
somehow are proportionally longer than the language merits but even
then, we're still talking a large, sophisticated body of knowledge.
Perl may be terribly ugly and confused and C++ may include many
unnecessary complexities -- and yet they're all documented in fewer
pages than Python.  Some criticisms of those other languages are
valid.  However, Python is hardly small by comparison.

When we want to consider the impact of adding or removing a
particular language feature, it needs to be considered in the context
of the entire language.  In practice, now in 2002 with Python 2.1+,
each of these changes are practically insignificant compared to the
entire body of knowledge.

So it's ridiculous to parrot "small is beautiful" or "one way to do it" to
argue that removing lambda() will somehow materially improve the
language or that adding the occasional do-while will precipitate chaos.

> Still, he admits to the occasional weak moment
>        (lambda, for example).

Then he should really be kicking himself over list comprehensions.  ;o)

I mean this strikes me as crazy.  People are saying get rid of lambda
and map when they're typically faster than for or while loops and
then they praise comprehensions when they're the most unusual
and slowest of all.

In this case I'm not saying get rid of comprehensions.  Just stop
talking about getting rid of lambda.

> As Steve Holden pointed out, once in the
>        language, core features take a long time to get rid of.  That's an
>        application of "practicality beats purity".  If Guido deleted every
>        feature from the language as soon as he developed something better to
>        replace it, I suspect he and Tim might be the only people using
>        Python.  It would be a very "pure" language, but not very
>        "practical".

This is an important point which I mostly agree with (at length with
in a different thread).

I am not advocating deleting any features.  Rather, if you read carefully,
part of my tirade is objecting to where people cite these slogans to
justify removing features.

Thanks for the thoughtful response.  Even though we disagree on some
points I hope you find this discussion as interesting as I do.

Regards

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