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

[Terry Reedy]

|
| > Here's the situation. Python is making inroads at MIT, Scheme home
turf.
| > The co-developer of Scheme, while writing about some other subject,
tosses
| > in an off-the-wall slam against Python. Someone asks what we here
think.
| > I think that the comment is a crock and the slam better directed, for
| > instance, at Scheme itself. Hence 'he should look in a mirror'.
|
| You are ignoring the fact that

This prefactory clause is false and as such it turns what was a true
statement into one that is not. Better to leave off such ad hominisms and
stick with the bare true statement.

| Scheme has a powerful syntax extension mechanism

I did not and do not see this as relevant to the main points of my summary
above. Python has powerful extension mechanisms too, but comparing the two
languages on this basis is a whole other topic.

tjr

 

[Douglas Alan]

You say that like it is a good thing.

A chaque son gout.

|>oug

 

[Douglas Alan]

This prefactory clause is false and as such it turns what was a true
statement into one that is not. Better to leave off such ad hominisms and
stick with the bare true statement.

You went on about how Gerry Sussman's opinion is a crock and how he
should look in the mirror, and then you get bent out of shape over the
phrase, "you are ignoring"??? For the record, "you are ignoring" is
not an ad hominem; "anyone who doesn't know how to spell 'ad hominem'
has the intelligence of a mealworm" is an ad hominem.

I did not and do not see this as relevant to the main points of my
summary above. Python has powerful extension mechanisms too, but
comparing the two languages on this basis is a whole other topic.

How do you know that Prof. Sussman doesn't consider the macro issue to
be essential? Certainly other Lisp aficionados do, as does, I believe
Guy Steele, the other inventor of Scheme.

It appears to me that you are missing the point that having a
minimalist disposition towards programming language design does not
preclude believing that such languages should have features that are
missing from Python.

|>oug

 

[Dennis Lee Bieber]

For instance, I believe that Python is now too big, and that much of
what is in the language itself should be replaced with more general
Scheme-like features. Then a good macro mechanism should be
implemented so that all the conveniences features of the language can
be implemented via macro definitions in the standard library.

You have me for the first part (too big)... Out of the last major
additions to the core language, the only one I've managed to get a grip
on is list comprehensions... They nicely got rid of the need for the
confusing standard functions -- apply, map, filter.

Adding generator expressions, which look identical except that one
typically has () (or the () of an enclosing function call) while the
other must have [] just seems to add confusion to the world. I'll
abstain on "with"... Decorators I've not managed to figure out, and that
refugee from Dr Moreau -- the inside out conditional expression -- is a
prime candidate for termination...

Macros? Unfortunately to my world, macros are those things found in
C, high-powered assemblers, and pre-VBA Office. As such, they do
anything but keep a language small, and one encounters multiple
implementations of similar functionality -- each implementation the
pride of one person, and abhorred by the person who now must edit the
code.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Paul Rubin]

Adding generator expressions, which look identical except that one
typically has () (or the () of an enclosing function call) while the
other must have [] just seems to add confusion to the world. I'll
abstain on "with"... Decorators I've not managed to figure out, and that
refugee from Dr Moreau -- the inside out conditional expression -- is a
prime candidate for termination...

Python has really changed its flavour over the past few releases, if
you develop a style that uses the above features (well maybe not the
if-expression) extensively. The learning curve is steeper but you end
up writing cleaner code that's free of corner cases.

 

[Alex Martelli]

It's in _The Revised^%d Report on Scheme_, Introduction:

Programming languages should be designed not by piling feature
on top of feature, but by removing the weaknesses and
restrictions that make additional features appear necessary.

Of course, that was written well before Scheme had most of its
current features.

The "Spirit of C" section in the preface of the ISO Standard for C
phrases this principle as "Provide only one way to do an operation".

Despite the phrasing variations, this commonality goes well with my
perception that, at their roots, Scheme, C and Python share one
philosophical underpinning (one that's extremely rare among programming
languages as a whole) -- an appreciation of SIMPLICITY AND UNIFORMITY as
language characteristics.


Alex

 

[Steven D'Aprano]

The "Spirit of C" section in the preface of the ISO Standard for C
phrases this principle as "Provide only one way to do an operation".

Taken seriously, that rapidly goes to absurdity -- it would mean, for
example, replacing all for loops with while loops.

That's why I get mad at people who misquote (and often misunderstand) the
Zen of Python's OOWTDI, misquoting it as Only One Way To Do It instead of
One Obvious Way To Do It. There can be a hundred unobvious ways to do it,
and it doesn't matter, so long as there is one obvious way.

Needlessly restricting what a language includes leads to a language that
does things badly. After all, all you really need is a virtual Turing
Machine, and you can do anything Python or Lisp or Perl or C can do. Badly.

I'm probably preaching to the converted, because I'm pretty sure Alex
doesn't believe Python should be a minimalist language with _literally_
only one way to do anything.

Despite the phrasing variations, this commonality goes well with my
perception that, at their roots, Scheme, C and Python share one
philosophical underpinning (one that's extremely rare among programming
languages as a whole) -- an appreciation of SIMPLICITY AND UNIFORMITY as
language characteristics.

Out of curiosity, what do you consider some of the worst offenders as far
as overly complex and inconsistent languages go, and why?

 

[Alex Martelli]

Out of curiosity, what do you consider some of the worst offenders as far
as overly complex and inconsistent languages go, and why?

I think the Original Sin in that regard was PL/I: it tried to have all
the "cool features" of the three widespread languages of the time,
Cobol, Algol _and_ Fortran (and then some), because it aimed to replace
all three and become the "one programming language". As a result, it
tended to have two or more ways to perform any given task, typically
inspired by some of the existing languages, often with the addition of
new ones made out of whole cloth.

PL/I (mostly in various subset and "extended subset" forms) was widely
used in the implementation of Multics, and I believe that the statement
in the "Spirit of C" was at least partly inspired by that experience
(just like "Unix" was originally intended as a pun on "Multics"
underscoring the drastically simpler philosophy of the new OS).


Alex

 

[Neil Cerutti]

Taken seriously, that rapidly goes to absurdity -- it would
mean, for example, replacing all for loops with while loops.

We do sometimes have to use a while loop in Python where we could
use a for loop in some other language. It's not really a big
deal.

I'm probably preaching to the converted, because I'm pretty
sure Alex doesn't believe Python should be a minimalist
language with _literally_ only one way to do anything.

It's making me think of the male model in Zoolander who can't
turn left.

Out of curiosity, what do you consider some of the worst
offenders as far as overly complex and inconsistent languages
go, and why?

I vote for C++ as being astoundingly complex. But it provides
complex features, e.g.,the machanisms it provides to deal with
multiple inheritance, or generic, type-safe code. I don't think
it's inconsistent, though. The complexity of a feature *tends* to
mirror the *real* complexity.

 

[Cousin Stanley]

I think the Original Sin in that regard was PL/I: it tried to have all
the "cool features" of the three widespread languages of the time,
Cobol, Algol _and_ Fortran (and then some), because it aimed to replace
all three and become the "one programming language". As a result, it
tended to have two or more ways to perform any given task, typically
inspired by some of the existing languages, often with the addition of
new ones made out of whole cloth.

PL/I (mostly in various subset and "extended subset" forms) was widely
used in the implementation of Multics, and I believe that the statement
in the "Spirit of C" was at least partly inspired by that experience
(just like "Unix" was originally intended as a pun on "Multics"
underscoring the drastically simpler philosophy of the new OS).

Cousin Alex ....

With regards to PL/I a phrase from an old ( 1969 ) song
named "The Night They Drove Old Dixie Down" comes to mind ....

Ya take what you need and ya leave the rest ....

I really liked programming in pl/1
and did a little over 3 years of Multics time
in San Juan, Puerto Rico ....

http://multicians.org/site-prha.html

 

[Paul Rubin]

I vote for C++ as being astoundingly complex. But it provides
complex features, e.g.,the machanisms it provides to deal with
multiple inheritance, or generic, type-safe code.

It gets off-topic but I'm not sure what advantage templates are
supposed to have over ML-like polymorphism.

 

[Douglas Alan]

Macros? Unfortunately to my world, macros are those things
found in C, high-powered assemblers, and pre-VBA Office. As such,
they do anything but keep a language small, and one encounters
multiple implementations of similar functionality -- each
implementation the pride of one person, and abhorred by the person
who now must edit the code.

Comparing C macros to Lisp macros is like comparing a Sawzall to a
scalpel.

Regarding having enough rope to hang yourself, the same claim can be
made about any language abstraction mechanism. E.g., classes are to
data types as macros are to syntax. You can abuse classes and you can
abuse macros. Both abuses will lead to abhorring by your
collaborators. And either abstraction mechanism, when used properly,
will result in more elegant, easier to read and maintain code.

Both abstraction mechanisms also allow language feature exploration to
occur outside of the privileged few who are allowed to commit changes
into the code-base for the interpreter or compiler. I think that this
is one of the things that Gerry Sussman might be getting at when he
talks about how science works. (Or at least that's what I would be
getting at if I were in his shoes.)

In the Lisp community, for instance, there have been lots of language
features that were implemented by people who were not part of the core
language development clique, but that were later widely adopted.
E.g., the Common Lisp OO system with mutimethods (CLOS), and the
"loop" macro. These features didn't require any changes to the core
language implementation, and so you can see that Lisp-style macros are
also a huge modularity boon for language implementation.

|>oug

 

[Neil Cerutti]

It gets off-topic but I'm not sure what advantage templates are
supposed to have over ML-like polymorphism.

I don't know that much about ML. I know is does a really nice job
of generic containers, as does C++. But can it 'foo' any type as
easily as C++?

template <class T> T foo(T);

As an aside, templates are abusable for many sorts of valuable
compile-time computations and type arithmetic, though I'd never
write that code myself--it looks like death.

C++ templates allow for fancy duck-typing in C++, which Python
programmers love. The STL is a good example of the power of
duck-typing (though it oughta been called quack-typing).

 

[Alex Martelli]

...
Cousin Alex ....

With regards to PL/I a phrase from an old ( 1969 ) song
named "The Night They Drove Old Dixie Down" comes to mind ....

Ya take what you need and ya leave the rest ....

I really liked programming in pl/1

I didn't -- been there, hated that. Each project group ended up
defining (formally or informally) the subset of PL/I it was using -- and
when one had to work with multiple groups, it became yet one more
nightmare to recall which features were in the subset of which group(s).

If there are just 30 "operations", for each of which the language offers
two ways to perform it, that one language becomes over a billion
languages when "subsetted" by picking just one choice for each of the
operations. Absolutely crazy -- total and utter waste of effort on the
part of every programmer, every group, every compiler author.

PL/1 is basically gone, but its legacy of "take what you need and leave
the rest" is unfortunately alive in other languages that are blind to
the enormous advantages of simplicity and uniformity.


Alex

 

[Paul Rubin]

PL/1 is basically gone, but its legacy of "take what you need and leave
the rest" is unfortunately alive in other languages that are blind to
the enormous advantages of simplicity and uniformity.

Intercal?

 

[Paul Rubin]

I don't know that much about ML. I know is does a really nice job
of generic containers, as does C++. But can it 'foo' any type as
easily as C++?

template <class T> T foo(T);

I don't know enough C++ to understand what the above means exactly,
but I think the answer is approximately "yes". I actually don't
know ML either, so I'm thinking in terms of Haskell types which
are similar.

 

[Neil Cerutti]

I don't know enough C++ to understand what the above means
exactly,

It means that foo can take an object of any type, T, as a
parameter, and returns an object of type T.

but I think the answer is approximately "yes". I actually
don't know ML either, so I'm thinking in terms of Haskell types
which are similar.

The following academic paper seems to be exactly what we're
looking for:

A comparitive study of language support for generic programming
http://faculty.cs.tamu.edu/jarvi/papers/cmp_gp.pdf

According to the paper, ML have a similar level of support for
generic programming, though in C++ three of the eight features
must be provided in code with template meta-programming.

 

[Magnus Lycka]

PL/1 is basically gone, but its legacy of "take what you need and leave
the rest" is unfortunately alive in other languages that are blind to
the enormous advantages of simplicity and uniformity.

Reminds me of RUP... No wonder Ivar Jacobson gave up and started all over.

 

[Douglas Alan]

|>oug writes:

I did not and do not see this as relevant to the main points of my
summary above. Python has powerful extension mechanisms too, but
comparing the two languages on this basis is a whole other topic.

Please note that Guy Steele in his abstract for "Rabbit: A Compiler
for SCHEME", specifically mentions that Scheme is designed to be a
minimal language in which, "All of the traditional imperative
constructs [...] as well as many standard LISP constructs [...] are
expressed in macros in terms of the applicative basis set. [...] The
macro approach enables speedy implementation of new constructs as
desired without sacrificing efficiency in the generated code."

http://library.readscheme.org/servlets/cite.ss?pattern=Ste-78b

Do you now see how Scheme's syntax extension mechanism is relevant?

|>oug

 

[Terry Reedy]

|
| > |>oug writes:
|
| >> Scheme has a powerful syntax extension mechanism
|
| > I did not and do not see this as relevant to the main points of my
| > summary above.

The main point of my original post was that the quoted slam at Python was
based on a misquote of Tim Peters and a mischaracterization of Python and
that it was out-of-place in the quoted discussion of physics methods and
that it added nothing to that discussion and should better have been
omitted. *All of this has nothing to do with Scheme.*

At the end, I added as a *side note* the irony that the purported author
was the co-developer of Scheme, another 'minimalist algorithm language
(Wikipedia's characterization) with more uniform syntax than Python and
like Python, also with one preferred way to scan sequences (based on my
memory of Scheme use in the original SICP, co-authored by the same
purported quote author, and also confirmed by Wikipedia).

I do not consider it a slam at Scheme to compare it with Python and see
some similarities. Nor is it a slam at Scheme to suggest that it could
just as well have been the subject of an unfair slam, if only the slammer
were not its co-developer ;-)

| [Steele quote deleted]
| Do you now see how Scheme's syntax extension mechanism is relevant?

No. This just partly explains why Scheme gets away with being minimalist.
I explicitly referred to the core language as delivered and as used in
SICP.

tjr