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

[Douglas Alan]

Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:

>> You seem oblivious to the fact that one of the huge benefits of Python
>> is its elegant and readable syntax.  The problem with not having a
>> "flexible syntax", is that a programming language can't provide
>> off-the-shelf an elegant syntax for all functionality that will ever
>> be needed.

> It is hardly "off-the-shelf" if somebody has to create new syntax
> for it.

Ummm. that's my point.  No language can provide all the syntax that
will ever be needed to write elegant code.  If module authors can
provide the syntax needed to use their module elegantly, then problem
solved.

>> Eventually programmers find themselves in need of new
>> elegant functionality, but without a corresponding elegant syntax to
>> go along with the new functionality, the result is code that does not
>> look elegant and is therefore difficult to read and thus maintain.

> That's true, as far as it goes, but I think you over-state your
> case.

I do not.

It is so easy for you, without *any* experience with a language (i.e.,
Lisp) or its community to completely dismiss the knowledge and wisdom
acquired by that community.  Doesn't that disturb you a bit?

> The syntax included in Python is excellent for most things, and even
> at its weakest, is still good. I can't think of any part of Python's
> syntax that is out-and-out bad.

The proposed syntax for using the proposed predicate-based multimethod
library is ungainly.

Until decorators were added to the language, the way to do things that
decorators are good for was ugly.  Decorators patch up one ugliness,
but who wants Python to become an old boat with lots of patches?

Nearly every addition made to Python since 1.5 could have been done in
the standard library, rather than being made to the core language, if
Python had a good macro system.  The exceptions, I think, being
objects all the way down, and generators.  Though generators could
have been done in the standard library too, if Python had first class
continuations, like Scheme and Ruby do.

Over time, an infinite number of examples will turn up like this, and
I claim (1) that it is better to modify the standard library than to
modify the language implementation, and that (2) it is better to allow
people to experiment with language features without having to modify
the implementation, and (3) that it is better to allow people to
distribute new language features for experimentation or production in
a loadable modular fashion, and (4) that it is better to allow
application developers to develope new language features for their
application frameworks than to not.

> The reality is, one can go a long, long, long distance with Python's
> syntax.

And you can go a long, long way with Basic, or Fortran, or C, or C++,
or Haskell, or Lisp.  None of this implies that there aren't
deficiencies in all of these languages.  Python is no exception.
Python just happens to be better than most in a number of significant
regards.

> Most requests for "new syntax" I've seen fall into a few
> categories:

> * optimization, e.g. case, repeat, multi-line lambda

I don't give a hoot about case or repeat, though a Lisp-like "loop
macro" might be nice.  (The loop macro is a little mini language
optimized for coding complicated loops.)  A multi-line lambda would
be very nice.

> * "language Foo looks like this, it is kewl"

Sometimes language Foo has features that are actually important to for
a specific application or problem domain.  It's no accident, for
instance, that Lisp is still the preferred language for doing AI
research.  It's better for Python if Python can accommodate these
applications and domains than for Python to give up these markets to
Foo.

> * the usual braces/whitespace flamewars
> * trying to get static type checking into the language
>
>
> So let's be specific -- what do you think Python's syntax is missing? If
> Python did have a macro facility, what would you change?

In addition to the examples given above, symbols would be nice.  Lisp
has 'em, Ruby has 'em, Python doesn't.  They are very useful.

An elegant multimethod based object system will be essential
for every language someday, when the time is right for people to
understand the advantages.

Manifest typing will be essential.

A backtracking system is important for some applications.  Perhaps all
applications, someday.

The ability to make mini-languages for specific domains, like fields
of math and science, is very useful, so the mathematicians and
scientists can denote things in a notation that is closer to the
notation that they actually work in.

Etc., etc., etc.  The future is long, and our ability to peer into it
is blurry, and languages that can adapt to the unforeseen needs of that
blurry future are the ones that will survive.

For instance, I can state with almost 100% certainty that one hundred
years from now, some dialect of Lisp will still be around and in
common usage.  I can't say the same thing about Python.  I can't say
that about Python ten years from now with Ruby popularity now hot on
the heels of Python's.

>> Take the issue up with Paul Graham.  Since making a fortune developing
>> software in Lisp (making heavy use of macros), he now has much more
>> free time to write essays defending the truth than I do:

>>    http://www.paulgraham.com/avg.html

> I think the #1 advantage to using Lisp in a commercial enterprise is
> only indirectly related to the language. Lisp coders are a
> self-selecting above-average bunch -- no VB drones or C code monkeys
> need apply.

And it's self-selecting because the people don't want to live within
the limits of VB or C or perhaps even Python.  Why should Python want
to alienate these uber-hackers rather than attract them?

> Graham talks about 25% of the Viaweb code base being macros. Imagine how
> productive his coders would have been if the language was not quite
> so minimalistic, so that they could do what they wanted without the
> _lack_ of syntax getting in the way.

You just prove Graham's point--that one is not qualified to judge the
features of a more powerful language without actually learning and
using the language--when you say things like this.  Viaweb almost
certainly used Common Lisp, not Scheme, and Common Lisp is anything
but a minimalistic language.  Python looks like a minimalistic
language compared to Common Lisp.

*Scheme* is the most well-known minimalistic Lisp, and was created, in
part, as a response to the the feature-creep of Common Lisp.  (Or
actually to the immediate precursors of Common Lisp.)  But few people
use Scheme for real work (as opposed to academic work).  Common Lisp
is the production Lisp work horse.

(The reasons for Common Lisp being dominant for production are as
complex as the reasons that other languages win or lose in market
place, but they have something to do with there being very efficient
implementations of Common Lisp, people actually wanting all those
creeping features, and the Scheme standardizing committees operating
so slowly.)

|>oug