I've just read an article "Building Robust System" by Gerald Jay
Sussman. The article is here: http://swiss.csail.mit.edu/classes/s...st-systems.pdf
In it there is a footprint which says:
"Indeed, one often hears arguments against building exibility into an
engineered sys-
tem. 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 equa-
tions 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."
I'm not sure how reasonable this statement is and personally I like
Python's simplicity, power and elegance. So I put it here and hope to
see some inspiring comments.
Jun 9 '07
206  8144 
"Steve Howell" <sh*******@yahoo.comwrote in message
news:72*************@web33511.mail.mud.yahoo.com.. .
|
| You would just change the language definition to say
| that once you enter f(), any call to f() from within
| f() behaves as if the recursively called f() still
| points to the originally bound version of f.
I am pretty sure such a context-dependent rule cannot be written as a
context-free grammar rule. In any case, the function object does not exist
when code is being compiled to a code object. So this requires
implementation-dependent post-patching of the code object. R.
Hetchinger(sp?) posted a Cookbook recipe for doing this for CPython.
Anyone wanting the speedup (with CPython) can use it.
tjr
"Diez B. Roggisch" <de***@nospam.web.dewrites:
And if only the html-parsing is slow, you might consider creating an
extension for that. Using e.g. Pyrex.
I just tried using BeautifulSoup to pull some fields out of some html
files--about 2 million files, output of a web crawler. It parsed very
nicely at about 5 files per second. Of course Python being Python, I
wanted to run the program a whole lot of times, modifying it based on
what I found from previous runs, and at 5/sec each run was going to
take about 4 days (OK, I probably could have spread it across 5 or so
computers and gotten it to under 1 day, at the cost of more effort to
write the parallelizing code and to scare up extra machines). By
simply treating the html as a big string and using string.find to
locate the fields I wanted, I got it up to about 800 files/second,
which made each run about 1/2 hour. Simplest still would be if Python
just ran about 100x faster than it does, a speedup which is not
outlandish to hope for.
Paul Rubin wrote:
"Diez B. Roggisch" <de***@nospam.web.dewrites:
>>And if only the html-parsing is slow, you might consider creating an
extension for that. Using e.g. Pyrex.
I just tried using BeautifulSoup to pull some fields out of some html
files--about 2 million files, output of a web crawler. It parsed very
nicely at about 5 files per second.
That's about what I'm seeing. And it's the bottleneck of
"sitetruth.com".
By
simply treating the html as a big string and using string.find to
locate the fields I wanted, I got it up to about 800 files/second,
which made each run about 1/2 hour.
For our application, we have to look at the HTML in some detail,
so we really need it in a tree form.
Simplest still would be if Python
just ran about 100x faster than it does, a speedup which is not
outlandish to hope for.
Right. Looking forward to ShedSkin getting good enough to run
BeautifulSoup.
(Actually, the future of page parsing is probably to use some kind
of stripped-down browser that reads the page, builds the DOM,
runs the startup JavaScript, then lets you examine the DOM. There
are too many pages now that just come through as blank if you don't
run the OnLoad JavaScript.)
John Nagle
"Terry Reedy" <tj*****@udel.eduwrites:
Try suggesting on a Lisp or Scheme group that having only one type
of syntax (prefix expressions) lacks something and that they should
add variety in the form of statement syntax ;-) Hint: some Lispers
have bragged here about the simplicity of 'one way to do it' and put
Python down for its mixed syntax. (Of course, this does not mean
that some dialects have not sneaked in lists of statements thru a
back door ;-).
Almost all Lisp dialects have an extremely powerful macro mechanism
that lets users and communities extend the syntax of the language in
very general ways. Consequently, dialects such a Scheme try to keep
the core language as simple as possible. Additional ways of doing
things can be loaded in as a library module.
So, a language such as Scheme may have no *obvious* way of something,
and yet may provide excellent means to extend the language so that
many obvious ways might be provided.
|>oug
"Terry Reedy" <tj*****@udel.eduwrites:
My only point was that Sussman is an odd person to be criticizing
(somewhat mistakingly) Python for being minimalist.
I think that being a language minimalist is very different from
believing that there should be exactly one obvious way to do
everything.
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.
Macros, however, are typically claimed in these parts to violate the
"only one way" manifesto.
|>oug
"Terry Reedy" <tj*****@udel.eduwrites:
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 Scheme has a powerful syntax extension
mechanism (i.e., hygenic macros), which means that anyone in the world
can basically extend Scheme to include practically any language
feature they might like it to have.
|>oug
On 15 Jun., 22:58, Douglas Alan <d...@alum.mit.eduwrote:
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.
And why sould anyone reimplement the whole standard library using
macro reductions? Because this is the "one obvious way to do it" for
people who are addicted to Scheme?
Kay Schluehr <ka**********@gmx.netwrites:
On 15 Jun., 22:58, Douglas Alan <d...@alum.mit.eduwrote:
>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.
And why sould anyone reimplement the whole standard library using
macro reductions? Because this is the "one obvious way to do it" for
people who are addicted to Scheme?
(1) By, "should be replaced", I meant in an ideal world. I'm not
proposing that this be done in the real world anytime soon.
(2) I didn't suggest that a single line of the standard library be
changed. What would need to be changed is the core Python language,
not the standard library. If this idea were implemented, the core
language could be made smaller, and the features that were thereby
removed from the language core could be moved into the standard
library instead.
(3) My reasons for wanting this have nothing to do with being
"addicted to Scheme", which I almost never use. It has to do more
with my language design and implementation aesthetics, and my desire
for a syntax extension mechanism so that I can add my own language
features to Python without having to hack on the CPython source code.
|>oug
On Fri, 15 Jun 2007 17:05:27 -0400, Douglas Alan wrote:
You are ignoring the fact that Scheme has a powerful syntax extension
mechanism (i.e., hygenic macros), which means that anyone in the world
can basically extend Scheme to include practically any language
feature they might like it to have.
You say that like it is a good thing.
--
Steven.
"Douglas Alan" <do**@alum.mit.eduwrote in message
news:lc************@gaffa.mit.edu...
| "Terry Reedy" <tj*****@udel.eduwrites:
|
| 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
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
On Fri, 15 Jun 2007 17:05:27 -0400, Douglas Alan wrote:
>You are ignoring the fact that Scheme has a powerful syntax extension
mechanism (i.e., hygenic macros), which means that anyone in the world
can basically extend Scheme to include practically any language
feature they might like it to have.
You say that like it is a good thing.
A chaque son gout.
|>oug
"Terry Reedy" <tj*****@udel.eduwrites:
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.
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.
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.
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 <wl*****@ix.netcom.comwrites:
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.
Neil Cerutti <ho*****@yahoo.comwrote:
On 2007-06-12, Antoon Pardon <ap*****@forel.vub.ac.bewrote:
On 2007-06-11, Terry Reedy <tj*****@udel.eduwrote:
More so than supporters of most other languages, in particular
Scheme?
Well to my knowledge (which could be vastly improved), scheme
doesn't have some Zen-rules that include something like this.
I tried to google for similar remarks in relation to scheme but
I got no results. Maybe your google skills are better.
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
On Fri, 15 Jun 2007 22:25:38 -0700, Alex Martelli wrote:
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?
--
Steven.
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
...
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?
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
On 2007-06-16, Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
On Fri, 15 Jun 2007 22:25:38 -0700, Alex Martelli wrote:
>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.
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. ;)
>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?
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.
--
Neil Cerutti
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
...
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?
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
--
Stanley C. Kitching
Human Being
Phoenix, Arizona
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Neil Cerutti <ho*****@yahoo.comwrites:
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.
Dennis Lee Bieber <wl*****@ix.netcom.comwrites:
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
On 2007-06-16, Paul Rubin <httpwrote:
Neil Cerutti <ho*****@yahoo.comwrites:
>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.
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 TT 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).
--
Neil Cerutti
Cousin Stanley <co***********@hotmail.comwrote:
...
I think the Original Sin in that regard was PL/I: it tried to have all
...
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.
...
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 al***@mac.com (Alex Martelli) writes:
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?
Neil Cerutti <ho*****@yahoo.comwrites:
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 TT 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.
On 2007-06-17, Paul Rubin <httpwrote:
Neil Cerutti <ho*****@yahoo.comwrites:
>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 TT foo(T);
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.
--
Neil Cerutti
Alex Martelli wrote:
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.
"Terry Reedy" <tj*****@udel.eduwrites:
|>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. 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/servle...attern=Ste-78b
Do you now see how Scheme's syntax extension mechanism is relevant?
|>oug
"Douglas Alan" <do**@alum.mit.eduwrote in message
news:lc************@gaffa.mit.edu...
| "Terry Reedy" <tj*****@udel.eduwrites:
|
| |>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
"Terry Reedy" <tj*****@udel.eduwrites:
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
On 2007-06-19, Douglas Alan <do**@alum.mit.eduwrote:
"Terry Reedy" <tj*****@udel.eduwrites:
>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.
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.
--
Neil Cerutti
Let us join David and Lisa in the celebration of their wedding and bring their
happiness to a conclusion. --Church Bulletin Blooper
Neil Cerutti <ho*****@yahoo.comwrites:
|>oug writes:
>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.
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
"Douglas Alan" <do**@alum.mit.eduwrote in message
news:lc************@gaffa.mit.edu...
|| 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/s...st-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
"Terry Reedy" <tj*****@udel.eduwrites:
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
On Tue, 19 Jun 2007 17:46:35 -0400, Douglas Alan wrote:
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"?
--
Steven.
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
On Tue, 19 Jun 2007 17:46:35 -0400, Douglas Alan wrote:
>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?
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
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
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. :)
Douglas Alan wrote:
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
Michele Simionato <mi***************@gmail.comwrites:
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.
On Tue, 19 Jun 2007 19:22:33 -0700, Paul Rubin wrote:
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
>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. :)
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.
On Tue, 19 Jun 2007 20:16:28 -0400, Douglas Alan wrote:
Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
>On Tue, 19 Jun 2007 17:46:35 -0400, Douglas Alan wrote:
>>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?
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.
>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.
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?
--
Steven.
"Douglas Alan" <do**@alum.mit.eduwrote in message
news:lc************@gaffa.mit.edu...
| 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
"Terry Reedy" <tj*****@udel.eduwrites:
| 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
Douglas Alan wrote:
"Terry Reedy" <tj*****@udel.eduwrites:
>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.
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
Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrites:
On Tue, 19 Jun 2007 20:16:28 -0400, Douglas Alan wrote:
>Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:
>>On Tue, 19 Jun 2007 17:46:35 -0400, Douglas Alan wrote:
>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.
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.
>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?
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.
>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
Sure, you can do it in Python, but I bet that it's neither very fun,
nor efficient.
>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.
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
Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrites:
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
Michele Simionato <mi***************@gmail.comwrites:
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
Robert Kern <ro*********@gmail.comwrites:
>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
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
Paul Rubin wrote:
Michele Simionato <mi***************@gmail.comwrites:
>>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.
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
On Wed, 20 Jun 2007 17:23:42 -0400, Douglas Alan wrote:
>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.
But why is the ability to abstract syntax good?
One criticism of operator overloading is that when you see X + Y you have
no real idea of whether it is adding X and Y together, or doing something
bizarre.
Now allow syntax to be over-ridden as well, and not only can't you tell
what X + Y does, but you can't even tell what it *means*. Maybe its a for-
loop, calling the function Y X times.
The usual response is "That's insane, no sane programmer would do that!",
and that's true as far as it goes (except for the programmers who are
just too clever for their own good). Nevertheless there is a real issue
there. When I program in Python, I always know what the syntax means,
because there is no possible way it can be changed. That's one less thing
I have to keep in my head, one less thing to worry about.
Sometimes, more freedom is not better. If you had a language that let you
redefine the literal 1 to mean the integer zero, wouldn't that make it
much harder to understand what even basic arithmetic meant?
If I wanted a bondage-and-discipline language, I'd use something with
static typing and declared variables and a compiler that made sure my
shoelaces were tied correctly before I did anything. But I don't, I use
Python, and I appreciate the dynamic typing and runtime errors and the
relatively few compiler checks.
But that doesn't mean I want a language where anything goes -- there's a
balance between too little freedom and too much. If Python became the
sort of language where I had to think about every module imported, every
function called, just to be sure that 1+1 would equal 2, I'd have to
reconsider whether Python was the language for me. There would have to be
some serious advantages before I'd be comfortable.
--
Steven.
Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrites:
On Wed, 20 Jun 2007 17:23:42 -0400, Douglas Alan wrote:
>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.
But why is the ability to abstract syntax good?
It allows the community to develop language features in a modular way
without having to sully the code base for the language itself. A
prime example of this is how CLOS, the Common Lisp Object System was
implemented completely as a loadable library (with the help of many
macros) into Common Lisp, which was not an OO language prior to the
adoption of CLOS.
The fact that CLOS could be developed in a modular way allowed for a
number of different groups to work on competing object systems. After
some experience with the pros and cons of the various object systems,
the developers of CLOS were able to incorporate most of the best ideas
from the entire field and then get it adopted as a defacto standard.
This allowed, for instance, the inclusion of multimethods, which are
an extremely nice feature for modular code development. In prior Lisp
dialects I had used, the object systems were more like the
single-object dispatching OO system in Python, which is substantially
inferior. The fact that the entire OO system in Common Lisp could be
loaded as a module that is coded entirely within Common Lisp allowed
for a large jump in the quality of its OO subsystem.
One criticism of operator overloading is that when you see X + Y you
have no real idea of whether it is adding X and Y together, or doing
something bizarre.
Yes, and despite this, operator overloading is an essential feature
for a modern language. (Java's lack of it notwithstanding.)
Now allow syntax to be over-ridden as well, and not only can't you tell
what X + Y does, but you can't even tell what it *means*. Maybe its a for-
loop, calling the function Y X times.
(1) With operator overloading you have no idea what X + Y *means*. It
could be feeding the cat, for all you know. If that turns out to
be the case, you fire the programmer in question. Just because a
language feature *can* be abused is no reason to leave it out of a
language. Power always comes with responsibility, but we still
need powerful programming languages.
(2) In Lisp, you cannot redefine existing syntax (without modifying
the standard library, which would be considered very rude), so the
problem that you are talking about is moot. You can only add
*new* syntactic constructs. I would suggest that any proposed
syntax extension mechanisms for other languages behave like Lisp
in this regard.
Sometimes, more freedom is not better. If you had a language that
let you redefine the literal 1 to mean the integer zero, wouldn't
that make it much harder to understand what even basic arithmetic
meant?
But we're not talking about anything like this. E.g., in some
dialects of Lisp it used to be possible to set the variable that
contained the value for *true* to the value for *false*. If you
actually did this, however, just imagine the havoc that it would
wreak. So ultimately, this capability was removed.
Alas, in Python, you can still do such a crazy thing!
But that doesn't mean I want a language where anything goes
You are imagining something very different from what is proposed.
Lisp-like macros don't allow "anything goes".
|>oug This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Stephen C. Waterbury |
last post by:
This seems like it ought to work, according to the
description of reduce(), but it doesn't. Is this
a bug, or am I missing something?
Python 2.3.2 (#1, Oct 20 2003, 01:04:35)
on linux2
Type...
|
by: Tuang |
last post by:
I'm checking out Python as a candidate for replacing Perl as my "Swiss
Army knife" tool. The longer I can remember the syntax for performing
a task, the more likely I am to use it on the spot if...
|
by: Michele Simionato |
last post by:
So far, I have not installed Prothon, nor I have experience with Io, Self
or other prototype-based languages. Still, from the discussion on the
mailing list, I have got the strong impression that...
|
by: John Morgan |
last post by:
Though I have designed and implemented a number of large reasonably
well received web sites I do not consider myself a graphics designer
I am now for the first time going to work with a ...
|
by: Russell Mangel |
last post by:
I have been doing some C++ Interop using the new VS2005 (June Beta).
I am exposing these methods to .NET clients.
I ran into some WinAPI methods which use LPVOID types, and I don't
understand...
|
by: tony |
last post by:
If you have any PHP scripts which will not work in the current releases
due to breaks in backwards compatibility then take a look at
http://www.tonymarston.net/php-mysql/bc-is-everything.html and...
|
by: Xah Lee |
last post by:
Software Needs Philosophers
by Steve Yegge, 2006-04-15.
Software needs philosophers.
This thought has been nagging at me for a year now, and recently it's
been growing like a tumor. One...
|
by: Xah Lee |
last post by:
The Nature of the “Unix Philosophy”
Xah Lee, 2006-05
In the computing industry, especially among unix community, we often
hear that there's a “Unix Philosophy”. In this essay, i...
|
by: Mathias Panzenboeck |
last post by:
Hi.
I wrote a small hashlib for C. Because I'm new to hashes I looked at pythons implementation and
reused *some* of the code... or more the mathematical "hash-function", not really the code.
...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
