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

[Douglas Alan]

The main point of my original post was that the quoted slam at Python was
based on a misquote of Tim Peters

But it wasn't based on a "misquote of Tim Peters"; it was based on an
*exact* quotation of Tim Peters.

and a mischaracterization of Python

I find Sussman's criticism not to be a mischaracterization at all: I
and others have previous mentioned in this very forum our desire to
have (in an ideal world) a good syntax extension facility for Python,
and when we've done so, we've been thoroughly pounced upon by
prominent members of the Python community as just not understanding
the true "Weltanschauung" of Python. This despite the fact that I
have been happily and productively programming in Python for more than
a decade, and the fact that Guido himself has at times mentioned that
he's been idly considering the idea of a syntax extension facility.

The reason given for why macros wouldn't gel with Python's
Weltanschauung has typically been the "only one obvious way" koan, or
some variant of it.

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.*

I'm not sure what you're getting at. Gerry Sussman has a philosophy
of language design that is different from Python's (at least as it is
commonly expressed around here), and he was using an analogy to help
illuminate what his differences are. His analogy is completely clear
to me, and, I in fact agree with it. I love Python, but I think the
"only one obvious way" philosophy may do more harm than good. It is
certainly used, in my experience, at times, to attempt to squelch
intelligent debate.

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

Sussman's statements are not ironic because Scheme is a language that
is designed to be extended by the end-user (even syntactically), while
keeping the core language minimal. This is a rather different design
philosophy from that of Python.

(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).

There is no one preferred way to scan sequences in Scheme. In fact,
if you were to take SICP at MIT, as I did when I was a freshman, you
would find that many of the problem sets would require you to solve a
problem in several different ways, so you would learn that there are
typically a number of different reasonable ways to approach a problem.
E.g., one of the first problem sets would have you implement something
both iteratively and recursively. I recall another problem set where
we had to find the way out of a maze first using a depth-first search
and then using a breadth-first search.

| [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.

I suggest that you haven't yet grokked the Weltanschauung of Scheme.
Scheme aficionados would not typically insist that a proposed language
feature is not good because it violates anything like an "only one
obvious way" rule. Rather they would argue that if it can be
implemented as fuctions and/or macros, then it *should* be implemented
that way, rather than polluting the core language. The new facility
should then be included in a library.

|>oug

 

[Neil Cerutti]

Sussman's statements are not ironic because Scheme is a
language that is designed to be extended by the end-user (even
syntactically), while keeping the core language minimal. This
is a rather different design philosophy from that of Python.

Which version Scheme, though? Scheme has only formally had macros
since R4RS, and then only as an extension. Macros are an
extension to Scheme, rather than a founder.

Python could conceivably end up in the same position 15 years
from now, with macros a well-established late-comer, as
generators have become.

I suggest that you haven't yet grokked the Weltanschauung of
Scheme. Scheme aficionados would not typically insist that a
proposed language feature is not good because it violates
anything like an "only one obvious way" rule. Rather they
would argue that if it can be implemented as fuctions and/or
macros, then it *should* be implemented that way, rather than
polluting the core language. The new facility should then be
included in a library.

The SRFIs are cool.

The last time I dipped my toe into the Scheme newsgroup, I was
overwhelmed by the many impractical discussions of Scheme's dark
corners. Python is either much more free of dark corners, or else
simply doesn't attract that kind of aficionado.

 

[Douglas Alan]

|>oug writes:

Which version Scheme, though? Scheme has only formally had macros
since R4RS, and then only as an extension. Macros are an extension
to Scheme, rather than a founder.

Macros were only *standardized* in Scheme with R4RS. This is because
they wanted to figure out the "right" way to do macros before putting
it in stone. (Common Lisp-like non-hygienic macros were considered
inelegant.) All the major implementations of Scheme that I know of
implemented some form of powerful macro mechanism. N.b., Rabbit,
which was Guy Steele's implementation of Scheme, and completed long,
long before the R4RS standard. (Guy Steele was one of the two
inventors of Scheme.) And, as far as I am aware, the plan was always
to eventually come up with a macro mechanism that was as elegant as
the rest of Scheme. The problem with this approach was that achieving
this daunting goal turned out to take quite a while.

Python could conceivably end up in the same position 15 years
from now, with macros a well-established late-comer, as
generators have become.

That would be very cool. The feeling I get, however, is that there
would be too much complaining from the Python community about how such
a thing would be "un-Pythonic".

The SRFIs are cool.

The last time I dipped my toe into the Scheme newsgroup, I was
overwhelmed by the many impractical discussions of Scheme's dark
corners. Python is either much more free of dark corners, or else
simply doesn't attract that kind of aficionado.

I don't really think that Scheme itself has many dark corners -- it's
just that being basically a pristine implementation of lambda
calculus, Scheme lets you directly explore some pretty mind-bending
stuff. I would agree that most of that kind of stuff is not
particularly practical, but it can be fun in a hackerly,
brain-expanding/brain-teaser kind of way.

I think that most people who program in Scheme these days don't do it
to write practical software. They either do it to have fun, or for
academic purposes. On the other hand, most people who program in
Python are trying to get real work done. Which is precisely why I
program a lot in Python and very little in Scheme these days. It's
nice to have the batteries included.

|>oug

 

[Terry Reedy]

|| But it wasn't based on a "misquote of Tim Peters"; it was based on an
| *exact* quotation of Tim Peters.

My mistake. The misquotation is in the subject line and other's posts here
and in other threads.

| > and a mischaracterization of Python

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.

I checked the context of the quote, page 3 (and 4) of
http://swiss.csail.mit.edu/classes/symbolic/spring07/readings/robust-systems.pdf

"(3)Indeed, one often hears arguments against building flexibility into an
engineered system.
For example, in the philosophy of the computer language Python it is
claimed:
'There should be one - and preferably only one - obvious way to do it.'[25]
Science does| not usually proceed this way: In classical mechanics, for
example, one
can construct equations of motion using Newtonian vectoral mechanics, or
using a
Lagrangian or Hamiltonian variational formulation.[30] In the cases where
all three approaches are applicable they are equivalent, but each has its
advantages in particular contexts."

This footnote is in the context of a section discussing redundancy in
biological systems (and the usual lack thereof in engineered physical
systems). 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'.

Leaving that aside, if you consider vector mechanics and variational
formulations as roughly analogous to functional versus procedural
programming (or OOP), then Python has both (or all three). Or if you
consider them to be different languages for expressing and solving
problems, then Python is one just language, but one that intentionally
works well with some others. So Python seems to have the sort of
flexibility that he implicitly claims it does not.

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

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.

But what naive reader could possibly guess any of this from the single
mention of Python quoted above?

Terry Jan Reedy

 

[Douglas Alan]

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

 

[Steven D'Aprano]

I think that most people who program in Scheme these days don't do it
to write practical software. They either do it to have fun, or for
academic purposes. On the other hand, most people who program in
Python are trying to get real work done. Which is precisely why I
program a lot in Python and very little in Scheme these days. It's
nice to have the batteries included.

So, once you've succeeded in your campaign to make Python more like
Scheme, what language will you use for getting real work done?

And how long will it take before Schemers start agitating for it to become
more like Scheme?

There is a huge gulf between the claim that Python needs to be more
Scheme-like, and the fact that by your own admission you use Python, not
Scheme, for real work. What benefit will be gained? The ability to
"directly explore some pretty mind-bending stuff ... in a hackerly,
brain-expanding/brain-teaser kind of way"?

 

[Douglas Alan]

So, once you've succeeded in your campaign to make Python more like
Scheme, what language will you use for getting real work done?

The problem with using Scheme for real work is that it doesn't come
with enough batteries included and there isn't a big enough of a
community behind it that uses it for real work.

Also, the Scheme standard has progressed at a terribly slow pace. I
have heard that the reason for this is due to the way that its
standardizing committees were set up.

One of the whole reasons to use Lisp is for its extensible syntax, but
it took more than a decade for macros to make it into the Scheme
standard. And without a standard macro system, there was no standard
library -- not even for doing OO programming.

And how long will it take before Schemers start agitating for it to
become more like Scheme?

There is a huge gulf between the claim that Python needs to be more
Scheme-like, and the fact that by your own admission you use Python,
not Scheme, for real work. What benefit will be gained? The ability
to "directly explore some pretty mind-bending stuff ... in a
hackerly, brain-expanding/brain-teaser kind of way"?

Well, go to MIT and take SICP and then the graduate-level sequel to
the class, Adventures in Advanced Symbolic Programming, and then
you'll see what some of the advantages would be.

A good multimethod system, e.g., would make Python a significantly
nicer language for my purposes, for instance.

For the record, I have a huge problem with NIH-syndrome, and think
that every programming language in the world could learn a thing or
two from what other languages have gotten right.

|>oug

 

[Paul Rubin]

So, once you've succeeded in your campaign to make Python more like
Scheme, what language will you use for getting real work done?

And how long will it take before Schemers start agitating for it to become
more like Scheme?

While you've dutifully searched the horizon for such intrusion, the
rot has been quietly happening from within ;-). Nested scopes,
first-class functions and closures, internal lambdas, and lazy
evaluation streams (iterators) are all Schemish incursions into
Python. List comprehensions and genexps come from even further in the
functional-programming "beyond". Soon Python will implement a
type system based on the Lambda Cube, well maybe not.

 

[Michele Simionato]

I think that most people who program in Scheme these days don't do it
to write practical software. They either do it to have fun, or for
academic purposes. On the other hand, most people who program in
Python are trying to get real work done. Which is precisely why I
program a lot in Python and very little in Scheme these days. It's
nice to have the batteries included.

|>oug

A few years ago, tired by the endless threads on comp.lang.python
asking from the inclusion of macros in Python, I decided to
learn Scheme and to understand what the fuss was about.

Learning Scheme coming from Python was not difficult for
what concerned the language features properly, but it was
extremely difficult for what concerned the philosophy behind
the language. I remember that I was expecially angry when I
discovered that the famous Sussman's quotation "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" was
just a bunch of nice words.

In practice Scheme follows exactly the opposite route: there are
dozens of different and redundant object systems, module systems,
even record systems, built just by piling up feature over feature.
So the minimalism of the core language is just a lie or at best
a red herring (the core language can be minimalistic, but the core
language is basically useless for any real life job).

I was angry for months, until I finally understood that I had to
look at the language in a different way. I thought Scheme was a
language to build applications, but I was wrong:
Scheme is a language intended for language design experimentations.

So if you have an idea for a new and cool object system,
Scheme would be a good tool for prototyping/implementing it without
going at the Assembler or C level. OTOH, if you have an idea
for a new Web framework, Python would be a much better tool
to implement it (but please, don't publish it!


So I basically view Scheme as a tool for
language designers only, or with people with interest in
language design and I don't use it for anything else.

I see Python or C as much better practical implementations
of Sussman's quote about minimalism than real Scheme (for
an example of real Scheme, I refer for instance to the PLT
implementation).


Michele Simionato

 

[Paul Rubin]

I see Python or C as much better practical implementations
of Sussman's quote about minimalism than real Scheme (for
an example of real Scheme, I refer for instance to the PLT
implementation).

Python and C as programming languages are like democracy as a system
of government--absolutely terrible, but everything else seems to be
even worse.

The real answer (to programming languages, not governments) seems
tantalizingly close, but not here yet.

 

[Steven D'Aprano]

While you've dutifully searched the horizon for such intrusion, the rot
has been quietly happening from within ;-). Nested scopes, first-class
functions and closures, internal lambdas, and lazy evaluation streams
(iterators) are all Schemish incursions into Python. List
comprehensions and genexps come from even further in the
functional-programming "beyond". Soon Python will implement a type
system based on the Lambda Cube, well maybe not.

All of which makes Douglas Alan's accusations of Not Invented Here
syndrome about Python seem rather silly. If there was ever a language
that cherry-picked the best features of other languages, it was Python.
If macros have been left out, it isn't because Guido has an irrational
attitude of NIH.

The point I was making isn't that Scheme/Lisp features are "bad", but
that there is no reason to slavishly follow Scheme just because it is(?)
technically the most "pure" programming language.

Well, obscurity might be a little harsh. Perhaps a lot harsh. I think so
long as there are programmers who want to play with programming, there
will be a place for Scheme, and that place will continue to be sneered at
by the sort of people who just want the job done, never mind whether it
is the purest, most lambda-calculus-esque way of doing it or not.

I'm glad somebody understands lambda calculus and closures and meta-
classes, and that those people have created Python so I don't have to.
And I suspect that for every Douglas Alan enamored with Scheme, there are
ten thousand programmers who just want to use a handful of pre-built
tools to get the work done, never mind using macros to create the tools
they need before they can even start.

It sounds all fine and dandy to talk about creating your own control
structures with macros. Been there, done that: when I was programming in
Forth, I was so excited about the ability to define my own control
structures. Great! Why be limited to boring old IF and WHILE and all the
others, when I can create my own?

But that quickly passed, because, let's be honest, there really aren't
that many useful control structures. There is a reason that most
languages offer the same old boring IFs and WHILEs and FORs, instead of
exciting new ones.

As a Python programmer, maybe I'd like to see a CASE statement, but I
don't _really_ need it. That's just an optimization. Same for REPEAT
UNTIL: it would be a nice to have, not a must have.

Same for macros -- if there is a sufficiently compelling use case for
macros, one which won't end up with Python code turning into a billion
different mini-languages, then I have trust that the Python-dev folk will
eventually add it into the language. But "Scheme has macros" isn't a
justification for why Python should have them.

 

[Steven D'Aprano]

The problem with using Scheme for real work is that it doesn't come with
enough batteries included and there isn't a big enough of a community
behind it that uses it for real work.

And yet there have been so many millions of dollars put into developing
Lisp...

I guess this is another example of perfection being the enemy of the
good. All that development into Lisp/Scheme to make it the best, purest,
most ideal programming language, with such flexibility and extensibility.
that nobody wants to use it. You can write any library and macro system
you need, but nobody has.

I don't mean literally nobody, of course. Its a figure of speech. But it
seems that people tend to program in Scheme for fun, or to stretch the
boundaries of what's possible, and not to Get The Job Done.

Well, go to MIT and take SICP and then the graduate-level sequel to the
class, Adventures in Advanced Symbolic Programming, and then you'll see
what some of the advantages would be.

Are you suggesting that the only way to see the advantages of Scheme is
to do a university course?

A good multimethod system, e.g., would make Python a significantly nicer
language for my purposes, for instance.
http://en.wikipedia.org/wiki/Multimethod#Python


For the record, I have a huge problem with NIH-syndrome, and think that
every programming language in the world could learn a thing or two from
what other languages have gotten right.

Of course. And Python, more than most, has shamelessly copied features
from other languages. So the question is, are Scheme macros one of those
things that "other languages have gotten right"? Could they be a case of
over-generalization? Or somewhere in between?

 

[Terry Reedy]

| I think you are missing the point. Sussman is making a broad criticism
of software
| engineering in general, as it is understood today.

On the contrary, I understood exactly that and said so. *My* point is that
in doing so, he made one jab at one specific language in a herky-jerky
footnote (a sentence on systems design philosopy, one on Python, one on
physics) that I consider to be at least misleading. And so I feel the
essay would be better without that wart.

| > So Python seems to have the sort of flexibility that he implicitly
| > claims it does not.
|
| 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.

Which I obviously read and responded to by noting "And 3.0 may add a new
generic function module to dispatch on multiple arguments and possibly
predicates."

| Although you might be
| able to cobble something like this together in Python, it would end up
| being very cumbersome to use.

Well, talk about shooting down innovations before they happen. Perhaps you
could wait and see what Eby and others come up with in the next year.

[from your other post]
| A good multimethod system, e.g., would make Python a significantly
| nicer language for my purposes, for instance.

Or better yet, read http://www.python.org/dev/peps/pep-3124/
(tentatively approved by Guido, pending actual code)
and perhaps some of the discussion thereof on the Python-3000 dev list and
help design and code something that would be at least usable if not 'good'.

| > 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.

And I never said that he said that they did. He just dropped in a formally
awkward and contentually untrue dig at Python, and only Python, that I
think should be removed.

| You didn't read the paper very carefully.

Because I don't agree with you? Because reading the paper did not much
change my original response to the original poster's request for responses
to the footnote?

I read more than carefully enough to confirm and extend my opinion that the
footnote is a wart that detracts from an otherwise interesting paper.

| He things, for instance, that predicate dispatching,
| backtracking, and first-class continuations will be required.

Yes, I read and understood that. But learning this did not change my
opinion of the bad form and bad content of the footnote.

|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.

Thanks for the additional context. But this still does not change my
negative opinion of the footnote. In fact, it only strengthens it in that
I think the footnote detracts from this aim.

Terry Jan Reedy

 

[Douglas Alan]

| I think you are missing the point. Sussman is making a broad
| criticism software engineering in general, as it is understood
| today.

On the contrary, I understood exactly that and said so. *My* point
is that in doing so, he made one jab at one specific language in a
herky-jerky footnote (a sentence on systems design philosopy, one on
Python, one on physics) that I consider to be at least misleading.
And so I feel the essay would be better without that wart.

The footnote is only misleading if you read it out of the context of
the essay. And Sussman clearly only picked on Python, in specific,
because Python is the only language for which this facet of current
engineering "best practices" has been actually been eloquently
committed to paper. There is nothing in the essay to suggest that
Python is any worse than any other popular production programming
language with respect to the issues that Sussman is addressing.

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

| 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.

Which I obviously read and responded to by noting "And 3.0 may add a new
generic function module to dispatch on multiple arguments and possibly
predicates."

So, that's great. Python will once again adopt a wonderful feature
that has been usable in Lisp implementations for 20 years now. (This
is a good thing, not a bad thing. I just don't like so much the
having to wait 20 years.) The problem with Python's model is that you
have to wait for a rather centralized process to agree on and
implement such a feature. In the Lisp community, *anyone* can easily
implement such features in order to experiment with them. This allows
much more experimentation to take place, which is one of the reasons
why Gerry Sussman brought the scientific community into the
discussion. The ability for people to readily conduct such
experiments benefits me, even if I personally never want to write a
macro or implement a language feature myself.

Related to this is the fact that it's much harder to be able to get
new language features right, unless you can get them wrong a few times
first. It's no accident that when Python adds features from Lisp and
Haskell, etc., that it does a pretty decent job with them, and that's
because it was able to learn from the mistakes and triumphs of others
who tried out various good and not-so-good language features in other
languages first.

The downside of Python's approach is that it makes Python not such a
very good language for exploring these potentially useful features
within Python in the first place. The Python community has to watch
what is going on in other programming language communities and then
raid these communities for their good ideas.

Perhaps this is not a bad thing if people just want Python to be a
programming language for getting real work done. But, personally, I
would prefer to have a language that works well for *both* production
work *and* for exploration. At the moment, neither Python nor Scheme
fits my bill, which is why I would like to see a programming language
that combines the best of both worlds.

| Although you might be able to cobble something like this together
| in Python, it would end up being very cumbersome to use.

Well, talk about shooting down innovations before they happen.
Perhaps you could wait and see what Eby and others come up with in
the next year.

I was referring to implementing these sorts of features within Python
(i.e., by writing Python modules in Python to support them) -- not
waiting for Python 3000, which may or may not have the features that I
want.

[from your other post]
| A good multimethod system, e.g., would make Python a significantly
| nicer language for my purposes, for instance.

Or better yet, read http://www.python.org/dev/peps/pep-3124/
(tentatively approved by Guido, pending actual code) and perhaps
some of the discussion thereof on the Python-3000 dev list and help
design and code something that would be at least usable if not
'good'.

Thanks for the pointer -- I will eagerly check it out.

| You didn't read the paper very carefully.

Because I don't agree with you?

No, because he clearly is not criticizing Python, in specific, and the
mention of Python is due *solely* to the fact that Python just happens
to mention, in one of its manifestos, a principle that would be
generally held to be true as a current best engineering practice. I
feel that a careful reading of the paper would have made this
apparent.

Also, I think it a bit counterproductive to get all up in arms about
such minor jabs. Python is strong enough to withstand all sorts of
valid criticism, as is Scheme. Even things that are excellent can be
made better, and also the time always eventually comes, as long as
human knowledge progresses, for even the greatest of artifacts to be
replaced with something better.

|>oug

 

[Robert Kern]

So, that's great. Python will once again adopt a wonderful feature
that has been usable in Lisp implementations for 20 years now. (This
is a good thing, not a bad thing. I just don't like so much the
having to wait 20 years.) The problem with Python's model is that you
have to wait for a rather centralized process to agree on and
implement such a feature.

No, you don't. Philip Eby has been working on various incarnations of generic
functions for some time now. The only thing new with 3.0 is that they may be
included in the standard library and parts of the rest of the standard library
may use them to implement their features. Implementing generic functions
themselves don't require anyone to convince python-dev of anything.

http://python.org/pypi/simplegeneric/0.6
http://peak.telecommunity.com/DevCenter/RulesReadme

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Douglas Alan]

And yet there have been so many millions of dollars put into
developing Lisp...

I guess this is another example of perfection being the enemy of the
good.

That's probably a valid criticism of Scheme. Not so much of Lisp in
general. The reason that Common Lisp hasn't been widely adopted
outside of the AI community, for instance, has more to do with most
programmers apparently not understanding the joys of Cambridge Polish
Notation. Also, Lisp was garbage-collected back when
garbage-collection had a bad name, due to it being considered a
resource hog. And then a large part of the Lisp community decided to
concentrate on building special hardware (i.e. Lisp machines) for
developing Lisp applications, rather than making good Lisp development
environments for Fortran/C machines (i.e., all normal computers).

It was clear to me at the time that it's a very hard sell to convince
people to buy expensive hardware to develop in a programming language
that hasn't yet been popularized. But apparently what was obvious to
me was not so apparent to those who dreamed of IPO riches.

All that development into Lisp/Scheme to make it the best, purest,
most ideal programming language, with such flexibility and
extensibility. that nobody wants to use it. You can write any
library and macro system you need, but nobody has.

Lisp in general has had all sorts of fancy macro packages for it since
the dawn of time. But Lisp wasn't really standardized until Common
Lisp in the early '80s. CLOS (the Common Lisp Object System), which
is implemented via macros entirely within Common Lisp itself, was
completed in the latter half of the '80s.

I don't mean literally nobody, of course. Its a figure of
speech. But it seems that people tend to program in Scheme for fun,
or to stretch the boundaries of what's possible, and not to Get The
Job Done.

Well, most implementations don't have batteries included, the way that
Python does. Guile attempts to, as does the Scheme Shell, but for
various reasons they didn't catch on the way that Python and Perl and
Ruby have.

Are you suggesting that the only way to see the advantages of Scheme
is to do a university course?

No, I was just suggesting *one* way of seeing the light. I think,
though, that it's probably difficult to grasp why Scheme is so
interesting without taking a good class or two on the topic. Not that
acquiring insight on one's own is impossible, but most people would
also have a hard time seeing why group theory or linear algebra are
really interesting without taking good classes one the subjects.

Python doesn't really require taking a class in it because it's really
very similar to many other programming languages. So if you already
know any of the others, Python is very easy to pick up. Scheme, on
the other hand, is more of a departure from what most people would
already be comfortable with.

http://en.wikipedia.org/wiki/Multimethod#Python

Sure, you can do it in Python, but I bet that it's neither very fun,
nor efficient.

Of course. And Python, more than most, has shamelessly copied
features from other languages.

To make myself a bit more clear, I don't think that Python suffers all
that much from NIH. On the other hand, I think that many people in
discussion forums in general often do. Here being no exception.

So the question is, are Scheme macros one of those things that
"other languages have gotten right"? Could they be a case of
over-generalization? Or somewhere in between?

I don't know of any language that is not a dialect of Lisp that has a
good syntax extension mechanism. Lisp dialects tend to get it right,
more or less, but solving the issue is much more difficult for any
language that doesn't have a Lisp-like syntax. Lisp's syntax is
particularly amenable to syntax extension.

|>oug

 

[Douglas Alan]

All of which makes Douglas Alan's accusations of Not Invented Here
syndrome about Python seem rather silly.

I've never made such an accusation about Python itself -- just about
the apparent attitude of some pontiffs.

The point I was making isn't that Scheme/Lisp features are "bad",
but that there is no reason to slavishly follow Scheme just because
it is(?) technically the most "pure" programming language.

I don't argue in favor of purity. I argue in favor of functionality
that would help me write better programs more easily.

Having a somewhat pure and minimalistic core language, however,
probably does help to make a language easier to implement, maintain,
and understand.

I'm glad somebody understands lambda calculus and closures and meta-
classes, and that those people have created Python so I don't have
to. And I suspect that for every Douglas Alan enamored with Scheme,
there are ten thousand programmers who just want to use a handful of
pre-built tools to get the work done, never mind using macros to
create the tools they need before they can even start.

I don't typically want to write that many macros myself. I want to be
part of a community where cool macro packages are actively developed
that I can then use. For instance, in Common Lisp, the entire OO
system is just a big macro package that was implemented entirely
within the language.

With macros and first class continuations, as Sussman points out in
his essay, people can then implement very interesting features like
backtracking. Again, I don't want to implement a backtracking macro
package myself; I want to be able to use what the community might come
up with.

But "Scheme has macros" isn't a justification for why Python should
have them.

No one ever gave that justification. The justification is that they
are *good*.

Macros are a way to abstract syntax the way that objects are used to
abstract data types and that iterators and generators abstract
control, etc.

|>oug

 

[Douglas Alan]

In practice Scheme follows exactly the opposite route: there are
dozens of different and redundant object systems, module systems,
even record systems, built just by piling up feature over feature.

The solution to this is to have a standard library which picks the
best of each and standardizes on them. (E.g., for Common Lisp, CLOS
became the standard object system, but there was certainly competition
for a while. E.g., Flavors, Common Loops, etc.) The problem with this
for Scheme is that the Scheme standardizing committees operate at a
glacial pace.

|>oug

 

[Douglas Alan]

No, you don't. Philip Eby has been working on various incarnations
of generic functions for some time now. The only thing new with 3.0
is that they may be included in the standard library and parts of
the rest of the standard library may use them to implement their
features. Implementing generic functions themselves don't require
anyone to convince python-dev of anything.

http://python.org/pypi/simplegeneric/0.6
http://peak.telecommunity.com/DevCenter/RulesReadme

The first one doesn't do multiple dispatch. I'll have to have a look
at the second one. It looks interesting. This link

http://www.ibm.com/developerworks/library/l-cppeak2/

shows PEAK being used to do multiple dispatch based on predicates, but
the code to implement the predicates is in strings! Sure, if you
don't have macros, you can always use eval instead if you have it, but
(1) doing so is ugly and dangerous, and (2) it's inefficient. Lisp
implementations these days do fancy stuff (multiple dispatch, etc.)
implemented as macros and yet typically end up generating code that
runs within a factor of 2 of the speed of C code.

In addition to having to code predicates in strings, using PEAK seems
syntactically rather cumbersome. Macros would help solve this
problem. Decorators seem to help to a large extent, but they don't
help as much as macros would.

Thanks for the pointers.

|>oug

 

[John Nagle]

Python and C as programming languages are like democracy as a system
of government--absolutely terrible, but everything else seems to be
even worse.

The real answer (to programming languages, not governments) seems
tantalizingly close, but not here yet.

Modula 3 was getting close, but it was being developed
at DEC, which had no software business outside of selling for DEC systems.
Then Compaq bought DEC and HP bought Compaq and all the research units
disappeared.

John Nagle