By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,402 Members | 1,236 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,402 IT Pros & Developers. It's quick & easy.

Lambda: the Ultimate Design Flaw

P: n/a
Shriram Krishnamurthi has just announced the following elsewhere; it might
be of interest to c.l.s, c.l.f, and c.l.p:
http://list.cs.brown.edu/pipermail/p...il/008382.html
The Fate Of LAMBDA in PLT Scheme v300
or
Lambda the Ultimate Design Flaw

About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp hackers
who missed them from their past experience. To this collection,
Scheme added a lexically-scoped, properly-functioning LAMBDA. But,
despite of the PR value of anything with Guy Steele's name associated
with it, we think these features should be cut from PLT Scheme v300.

We think dropping FILTER and MAP is pretty uncontroversial; (filter P
S) is almost always written clearer as a DO loop (plus the LAMBDA is
slower than the loop). Even more so for (map F S). In all cases,
writing the equivalent imperative program is clearly beneficial.

Why drop LAMBDA? Most Scheme users are unfamiliar with Alonzo Church
(indeed, they don't even know that he was related to Guy Steele), so
the name is confusing; also, there is a widespread misunderstanding
that LAMBDA can do things that a nested function can't -- we still
recall Dan Friedman's Aha! after we showed him that there was no
difference! (However, he appears to have since lapsed in his ways.)
Even with a better name, we think having the two choices side-by-side
just requires programmers to think about their program; not having the
choice streamlines the thought process, and Scheme is designed from
the ground up to, as much as possible, keep programmers from thinking
at all.

So now FOLD. This is actually the one we've always hated most,
because, apart from a few examples involving + or *, almost every time
we see a FOLD call with a non-trivial function argument, we have to
grab pen and paper and imagine the *result* of a function flowing back
in as the *argument* to a function. Plus, there are *more* arguments
coming in on the side! This is all absurdly complicated. Because
almost all the examples of FOLD we found in practice could be written
as a simple loop with an accumulator, this style should be preferred,
perhaps with us providing a simple helper function to abstract away
the boilerplate code. At any rate, FOLD must fold.

--The PLT Scheme Team
Jul 18 '05 #1
Share this Question
Share on Google+
47 Replies


P: n/a
Daniel Silva wrote:
Shriram Krishnamurthi has just announced the following elsewhere; it might
be of interest to c.l.s, c.l.f, and c.l.p:
http://list.cs.brown.edu/pipermail/p...il/008382.html


April Fool's Day again, eh?

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
If you can't fight and you can't flee, flow.
-- Robert Elliot
Jul 18 '05 #2

P: n/a
Daniel Silva wrote:
At*any*rate,*FOLD*must*fold.


I personally think GOTO was unduly criticized by Dijkstra. With the benefit
of hindsight, we can see that giving up GOTO in favor of other primitives
failed to solve the decades-old software crisis.
Jul 18 '05 #3

P: n/a
Daniel Silva wrote:
We think dropping FILTER and MAP is pretty uncontroversial; (filter P
S) is almost always written clearer as a DO loop (plus the LAMBDA is
slower than the loop). Even more so for (map F S). In all cases,
writing the equivalent imperative program is clearly beneficial.


How about using srfi-42 instead of those nasty do loops?
It's pretty clean:
(list-ec (: a lis) (* a a))
is equivalent to
(map (lambda (a) (* a a)) lis)

Before I discovered srfi-42, my code often had hideous things like:

(append-map
(lambda (item)
(map
(lambda
(inner)
(* inner inner))
(cdr item)))
lis)

to return (1 4 9 16 25 36 49 64 81) for
a lis that's '((a 1 2 3) (b 4 5 6) (c 7 8 9))).

This becomes even neater:
(list-ec
(: item lis)
(: inner (cdr item))
(* inner inner))

Have a happy first of april!
Jul 18 '05 #4

P: n/a
>
The Fate Of LAMBDA in PLT Scheme v300
or
Lambda the Ultimate Design Flaw

Why drop LAMBDA?


Why not? Isn't all code eventually anonymous and relocatable?
Jul 18 '05 #5

P: n/a
Hallöchen!

Daniel Silva <ds****@ccs.neu.edu> writes:
Shriram Krishnamurthi has just announced the following elsewhere; it might
be of interest to c.l.s, c.l.f, and c.l.p:
http://list.cs.brown.edu/pipermail/p...il/008382.html
The Fate Of LAMBDA in PLT Scheme v300
or
Lambda the Ultimate Design Flaw

About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp
hackers who missed them from their past experience. To this
collection, Scheme added a lexically-scoped, properly-functioning
LAMBDA. But, despite of the PR value of anything with Guy
Steele's name associated with it, we think these features should
be cut from PLT Scheme v300.

[...]


The whole text seems to be a variant of
<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jul 18 '05 #6

P: n/a
On Thu, 31 Mar 2005 23:30:42 -0800, Erik Max Francis wrote:
Daniel Silva wrote:
Shriram Krishnamurthi has just announced the following elsewhere; it might
be of interest to c.l.s, c.l.f, and c.l.p:
http://list.cs.brown.edu/pipermail/p...il/008382.html


April Fool's Day again, eh?


Yes and no. In the Python community, we're taking all of that pretty
seriously. The scheme community may not seriously be thinking of getting
rid of those things, but it's hardly impossible that some people think it
might be better off without it.
Jul 18 '05 #7

P: n/a
Jeremy Bowers wrote:
Yes and no. In the Python community, we're taking all of that pretty
seriously. The scheme community may not seriously be thinking of getting
rid of those things, but it's hardly impossible that some people think it
might be better off without it.


Lambda is a primitive in Scheme; in some implementations of scheme it's
used to implement things like temporary variables (let), sequences
(begin) and looping (named let/letrec).

Python has other ways of doing these things; and removing things that
has been obsoleted or superfluous makes sense, for Pythons ideal of
having one canonical, explicit way to program.

Having a few very abstract primitives that the rest of the language can
theoretically be built upon is one of the reasons why Scheme/Lisp can
work as a programmable programming language.

Scheme is like Go - a few abstract rules that can be combined in
endless, sprawling ways.

Python is like (hmm, better let some pythonista answer this. I'm
thinking of a game with a clear thematical connection (like Monopoly or
The Creature that Ate Sheboygan) and a few explicit rules that combine
in ways that is supposed to have a clear, readable, consistent result).
Maybe shogi?

(I don't usually read comp.lang.python and I really don't want to offend
anyone. My apologies if this post is either annoyingly obvious (and thus
contains only stuff that's been said a million times), or totally wrong.)

Sunnan
Jul 18 '05 #8

P: n/a
[Sunnan]
[...] for Pythons ideal of having one canonical, explicit way to
program.


No doubt it once was true, but I guess this ideal has been abandoned a
few years ago.

My honest feeling is that it would be a mis-representation of Python,
assertng today that this is still one of the Python's ideals.

--
François Pinard http://pinard.progiciels-bpi.ca
Jul 18 '05 #9

P: n/a
Jeremy Bowers <je**@jerf.org> writes:
On Thu, 31 Mar 2005 23:30:42 -0800, Erik Max Francis wrote:
Daniel Silva wrote:
Shriram Krishnamurthi has just announced the following elsewhere; it might
be of interest to c.l.s, c.l.f, and c.l.p:
http://list.cs.brown.edu/pipermail/p...il/008382.html


April Fool's Day again, eh?


Yes and no. In the Python community, we're taking all of that pretty
seriously.


The Python community takes many things pretty seriously. Whitespace
and Guido come to mind.

Jul 18 '05 #10

P: n/a
alex goldman wrote:
Daniel Silva wrote:

At any rate, FOLD must fold.

I personally think GOTO was unduly criticized by Dijkstra. With the benefit
of hindsight, we can see that giving up GOTO in favor of other primitives
failed to solve the decades-old software crisis.


The fault of goto in imperative languages is that it has no
arguments, thus creating spaghetti of gotos and assignments.

Continuations rule!
Jul 18 '05 #11

P: n/a
In article <ma**************************************@python.o rg>,
=?iso-8859-1?Q?Fran=E7ois?= Pinard <pi****@iro.umontreal.ca> wrote:
[Sunnan]

[...] for Pythons ideal of having one canonical, explicit way to
program.


No doubt it once was true, but I guess this ideal has been abandoned a
few years ago.

My honest feeling is that it would be a mis-representation of Python,
assertng today that this is still one of the Python's ideals.


Mind providing evidence rather than simply citing your feelings? Yes,
there's certainly redundancy in Python right now, but a large portion of
that will go away in Python 3.0. So where's the abandonment of the
ideal?
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR
Jul 18 '05 #12

P: n/a
Daniel Silva <ds****@ccs.neu.edu> writes:

[...]
So now FOLD. This is actually the one we've always hated most,
because, apart from a few examples involving + or *, almost every time
we see a FOLD call with a non-trivial function argument, we have to
grab pen and paper and imagine the *result* of a function flowing back
in as the *argument* to a function. Plus, there are *more* arguments
coming in on the side! This is all absurdly complicated. Because
almost all the examples of FOLD we found in practice could be written
as a simple loop with an accumulator, this style should be preferred,
perhaps with us providing a simple helper function to abstract away
the boilerplate code. At any rate, FOLD must fold.


Couldn't you leave it in for just another month? And during the
remaining month, we'll just call it the "APRIL FOLD".

--
Tom Breton, the calm-eyed visionary
Jul 18 '05 #13

P: n/a
On 1 Apr 2005 20:00:13 -0500, aa**@pythoncraft.com (Aahz) wrote:
In article <ma**************************************@python.o rg>,
=?iso-8859-1?Q?Fran=E7ois?= Pinard <pi****@iro.umontreal.ca> wrote:
[Sunnan]

[...] for Pythons ideal of having one canonical, explicit way to
program.
No doubt it once was true, but I guess this ideal has been abandoned a
few years ago.

My honest feeling is that it would be a mis-representation of Python,
assertng today that this is still one of the Python's ideals.

^^^^^--in particular?? That makes for a complex sentence ;-)
Mind providing evidence rather than simply citing your feelings? Yes,
there's certainly redundancy in Python right now, but a large portion of
that will go away in Python 3.0. So where's the abandonment of the
ideal?
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR


Regards,
Bengt Richter
Jul 18 '05 #14

P: n/a
Aahz wrote:
"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR


Can anyone please point me to the text that quote was taken from? I
tried to use a search engine but I only found quotations, not the source.
Sunnan
Jul 18 '05 #15

P: n/a
[Aahz]
"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

[Sunnan] Can anyone please point me to the text that quote was taken from? I
tried to use a search engine but I only found quotations, not the source.


That's because it was originally in email to a company-internal
mailing list. If you're willing to move to Fredericksburg, VA and
work for Zope Corp, perhaps they'll let you in to the PythonLabs list
archives. Fair warning: I work for Zope Corp, and I'm not sure I can
get into those archives. So don't switch jobs _just_ for that.
Jul 18 '05 #16

P: n/a
[Aahz]
=?iso-8859-1?Q?Fran=E7ois?= Pinard <pi****@iro.umontreal.ca> wrote:
No doubt it once was true, but I guess this ideal has been
abandoned a few years ago. My honest feeling is that it would be a
mis-representation of Python, assertng today that this is still one
of the Python's ideals.

Mind providing evidence rather than simply citing your feelings?
The important word was "honest", not "feeling". :-)
Yes, there's certainly redundancy in Python right now, [...]
See here, I'm not asking you for proofs. :-)
but a large portion of that will go away in Python 3.0.
And when will that be? The principle of "there is only way to do it"
was observable in Python 1.5.2, and started to disappear at that time.
How many years between 1.5.2 and 3.0?
So where's the abandonment of the ideal?


Many of us are using Python today, week after week, year long. So let's
be pragmatic. Python is what it became and now is. Let's not define it
as a memory from the past nor as a futuristic dream.

--
François Pinard http://pinard.progiciels-bpi.ca
Jul 18 '05 #17

P: n/a
Aahz wrote:
In article <ma**************************************@python.o rg>,
=?iso-8859-1?Q?Fran=E7ois?= Pinard <pi****@iro.umontreal.ca> wrote:
[Sunnan]
[...] for Pythons ideal of having one canonical, explicit way to
program.


No doubt it once was true, but I guess this ideal has been abandoned a
few years ago.

My honest feeling is that it would be a mis-representation of Python,
assertng today that this is still one of the Python's ideals.

Mind providing evidence rather than simply citing your feelings? Yes,
there's certainly redundancy in Python right now, but a large portion of
that will go away in Python 3.0. So where's the abandonment of the
ideal?


Mind providing evidence rather than citing your opinions? I don't see
any evidence that Python 3.0 will adopt Turing-machine-like canonical
algorithms, and anything more complex is (at least from a theoretical
point of view) merely syntactic sugar.

regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 18 '05 #18

P: n/a
alex goldman wrote:
Daniel Silva wrote:

At any rate, FOLD must fold.

I personally think GOTO was unduly criticized by Dijkstra. With the benefit
of hindsight, we can see that giving up GOTO in favor of other primitives
failed to solve the decades-old software crisis.


What software crisis? Knuth (among others) has demonstrated that it's
possible to do structured programming in assembly language (though I
have to say that not all his MIX was particularly well-structured).

The danger in GOTO is that it allows the undisciplined programmer to
develop a badly-structured solution to a programming problem. A
disciplined programmer will write well-structured code with whatever
tools come to hand.

regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 18 '05 #19

P: n/a
Tim Peters wrote:
[Aahz]
"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR

[Sunnan]
Can anyone please point me to the text that quote was taken from? I
tried to use a search engine but I only found quotations, not the source.

That's because it was originally in email to a company-internal
mailing list. If you're willing to move to Fredericksburg, VA and
work for Zope Corp, perhaps they'll let you in to the PythonLabs list
archives. Fair warning: I work for Zope Corp, and I'm not sure I can
get into those archives. So don't switch jobs _just_ for that.


It's just that I'm having a hard time matching that quote to what I
though python was about. I thought boring code was considered a virtue
in python. ("Explicit is better than implicit", "sparse is better than
dense".)

Because what is "boring"? The opposite of dense, tense, intense. Utterly
predictable; it's like the combination of all my prejudices. Even before
I knew, I thought "Bet Python separates statements from expressions".
Sunnan
PS.
(People easily offended can substitute "boring" for "readable" in the
above text.)
Jul 18 '05 #20

P: n/a
Sunnan wrote:
...Because what is "boring"? The opposite of dense, tense, intense. Utterly
predictable; it's like the combination of all my prejudices. Even before
I knew, I thought "Bet Python separates statements from expressions".


Python is for terse, pithy prose; Python is not for poetry.

--Scott David Daniels
Sc***********@Acm.Org
Jul 18 '05 #21

P: n/a
On Sat, 02 Apr 2005 00:40:15 -0500, Steve Holden <st***@holdenweb.com>
wrote:

The danger in GOTO is that it allows the undisciplined programmer to
develop a badly-structured solution to a programming problem. A
disciplined programmer will write well-structured code with whatever
tools come to hand.

regards
Steve


And how that becomes really clear when you want to modify a large
program that uses GOTOs librally.
Ron

Jul 18 '05 #22

P: n/a
Quoth Scott David Daniels <Sc***********@Acm.Org>:
| Sunnan wrote:
| > ...Because what is "boring"? The opposite of dense, tense, intense. Utterly
| > predictable; it's like the combination of all my prejudices. Even before
| > I knew, I thought "Bet Python separates statements from expressions".
|
| Python is for terse, pithy prose; Python is not for poetry.

That's an odd thing to say. Poetry is verbose, florid?
Python is Dutch.

Donn
Jul 18 '05 #23

P: n/a
In article <Vr*********************@newsc.telia.net>,
Sunnan <su****@handgranat.org> wrote:
[Aahz]

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR


It's just that I'm having a hard time matching that quote to what I
though python was about. I thought boring code was considered a virtue
in python. ("Explicit is better than implicit", "sparse is better than
dense".)

Because what is "boring"? The opposite of dense, tense, intense. Utterly
predictable; it's like the combination of all my prejudices. Even before
I knew, I thought "Bet Python separates statements from expressions".


Note very, VERY, *VERY* carefully that the quote says nothing about
"boring code". The quote explicitly refers to "reams of trivial code"
as boring -- and that's quite true. Consider this distinction:

if foo == 'red':
print 'foo is red'
elif foo == 'blue':
print 'foo is blue'

versus

print "foo is", foo

I'm sure you can think of many other examples -- real examples -- if you
put your mind to work; Guido's point is about the essential necessity of
refactoring and rewriting code for conciseness and clarity.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR
Jul 18 '05 #24

P: n/a
Donn Cave wrote:
Quoth Scott David Daniels <Sc***********@Acm.Org>:
| Sunnan wrote:
| > ...Because what is "boring"? The opposite of dense, tense, intense. Utterly
| > predictable; it's like the combination of all my prejudices. Even before
| > I knew, I thought "Bet Python separates statements from expressions".
|
| Python is for terse, pithy prose; Python is not for poetry.

That's an odd thing to say. Poetry is verbose, florid?
No, poetry is to be read slowly and carefully, appreciating the nuance
at every point. You should be able to read "past" python, while poetry
is at least as much about the form of the expression as it is about
what is being expressed.
Python is Dutch.

Donn

Jul 18 '05 #25

P: n/a
Torsten Bronger wrote:
Hallöchen!

Daniel Silva <ds****@ccs.neu.edu> writes:

Shriram Krishnamurthi has just announced the following elsewhere; it might
be of interest to c.l.s, c.l.f, and c.l.p:
http://list.cs.brown.edu/pipermail/p...il/008382.html
The Fate Of LAMBDA in PLT Scheme v300
or
Lambda the Ultimate Design Flaw

About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp
hackers who missed them from their past experience. To this
collection, Scheme added a lexically-scoped, properly-functioning
LAMBDA. But, despite of the PR value of anything with Guy
Steele's name associated with it, we think these features should
be cut from PLT Scheme v300.

[...]

The whole text seems to be a variant of
<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.

Tschö,
Torsten.

Ya think? ;-)

--ag

--
Artie Gold -- Austin, Texas
http://it-matters.blogspot.com (new post 12/5)
http://www.cafepress.com/goldsays
Jul 18 '05 #26

P: n/a
Artie Gold wrote:
Torsten Bronger wrote:
Hallöchen!

Daniel Silva <ds****@ccs.neu.edu> writes:

Shriram Krishnamurthi has just announced the following elsewhere; it
might be of interest to c.l.s, c.l.f, and c.l.p:
http://list.cs.brown.edu/pipermail/p...il/008382.html
The Fate Of LAMBDA in PLT Scheme v300
or
Lambda the Ultimate Design Flaw

About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp
hackers who missed them from their past experience. To this
collection, Scheme added a lexically-scoped, properly-functioning
LAMBDA. But, despite of the PR value of anything with Guy
Steele's name associated with it, we think these features should
be cut from PLT Scheme v300.

[...]

The whole text seems to be a variant of
<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.

Tschö,
Torsten.

Ya think? ;-)

--ag


Wow, the original is much funnier than the "joke"! (Because it's meant
seriously)
"plus the lambda is slower than the list comprehension" - ROTFL!
Jul 18 '05 #27

P: n/a
Scott David Daniels wrote:
No, poetry is to be read slowly and carefully, appreciating the nuance
at every point. You should be able to read "past" python, while poetry
is at least as much about the form of the expression as it is about
what is being expressed.


Right, I agree with these descriptions of python vs "the poetry
languages". I'm not sure whether I'd consider python particularly terse,
though, but I don't know enough about it yet. (I've read a couple of
programs but never started a project of my own in it, mainly because I
love poetry. I can see the appeal of a "prose language", though.)
Jul 18 '05 #28

P: n/a
Aahz wrote:
Note very, VERY, *VERY* carefully that the quote says nothing about
"boring code". The quote explicitly refers to "reams of trivial code"
as boring -- and that's quite true. Consider this distinction:
Thank you for this important clarification.
if foo == 'red':
print 'foo is red'
elif foo == 'blue':
print 'foo is blue'

versus

print "foo is", foo
Is the space added automatically? (Like awk does, if you add a comma.)
I'm sure you can think of many other examples -- real examples -- if you
put your mind to work; Guido's point is about the essential necessity of
refactoring and rewriting code for conciseness and clarity.


Which is a good point to make in almost any language, for code that is
to be maintained.

Sunnan
Jul 18 '05 #29

P: n/a
Artie Gold wrote:
Torsten Bronger wrote:
The whole text seems to be a variant of
<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.

Tschö,
Torsten.

Ya think? ;-)


Heh. I was glad that Torsten pointed it out; I didn't get what was funny
about the joke until then.
Jul 18 '05 #30

P: n/a
Scott David Daniels wrote:
Sunnan wrote:
...Because what is "boring"? The opposite of dense, tense, intense.
Utterly predictable; it's like the combination of all my prejudices.
Even before I knew, I thought "Bet Python separates statements from
expressions".

Python is for terse, pithy prose; Python is not for poetry.

--Scott David Daniels
Sc***********@Acm.Org


I though that too, until Michael Spencer sent me the following
executable Python limerick, which I declared the PyCon limerick
competition and read as a part of my closing address:

# Freely re-distributable under Poetic License*
# Voice only the alphanumeric tokens

from itertools import repeat
for feet in [3,3,2,2,3]:
print " ".join("DA-DA-DUM"
for dummy in [None]
for foot in repeat("metric", feet))

*thanks to Peter Hansen

regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 18 '05 #31

P: n/a
Donn Cave wrote:

That's an odd thing to say. Poetry is verbose, florid?
Python is Dutch.


Ha. I'm vaguely dutch, whatever that means.

I would say if there is a sister word for "Programming" in the english
language, it isn't Poetry and it surely isn't Prose. It's Dialectic.
I appreciate the idea of "Code Poetry", and I find more than a few
coders out there with more than a rudimentary appreciation of Poetry as
well, but I don't like the analogy. No slight to Poetry is intended.
Rather, I intend it as a compliment. Code has an almost entirely
practical purpose, Malbol et al excluded. Poetry, except in cases of
extraordinarily bad poetry, may have little "practical" purpose.

Now dialectic. I like that word. And I think the art of programming is
somewhere in the Late-Medeival period right now. From Merriam Webster,
meanings 1,5,6 seem rather sympathetic to texts used in the creation of
software:

Dialectic

1. LOGIC
5. Any systematic reasoning, exposition, or argument that juxtaposes
opposed or contradictory ideas and usually seeks to resolve their
conflict/an intellectual exchange of ideas
6 : the dialectical tension or opposition between two interacting forces
or elements

One way to look at Code is as a textual abstraction of a design. Having
been flattened from brain-space into a two dimension matrix of latin
glyphs, certain semantic/meta-data is typically omitted. Thus a
classical programming problem in many languages: The "Write-only-code"
syndrom. You wrote it, it runs, but you're afraid even to touch it
yourself. Python is stronger than other languages I have used. When I
go back to Python code I've written long enough ago to have forgotten
everything about, I am more able to pick it up and work with it than I
am with other less agile languages. I'm not merely talking about
pedantic details of literal code-readability, I'm talking about the
ability to intuit design from implementation, and the orthogonality of
the design of the system to the to the faculty of human reason. (In not
so many words: Python fits my brain.)

Warren

Jul 18 '05 #32

P: n/a
Scott David Daniels wrote:
Sunnan wrote:
...Because what is "boring"? The opposite of dense, tense, intense.
Utterly predictable; it's like the combination of all my prejudices.
Even before I knew, I thought "Bet Python separates statements from
expressions".

Python is for terse, pithy prose; Python is not for poetry.

--Scott David Daniels
Sc***********@Acm.Org


I though that too, until Michael Spencer sent me the following
executable Python limerick, which I declared the PyCon limerick
competition and read as a part of my closing address:

# Freely re-distributable under Poetic License*
# Voice only the alphanumeric tokens

from itertools import repeat
for feet in [3,3,2,2,3]:
print " ".join("DA-DA-DUM"
for dummy in [None]
for foot in repeat("metric", feet))

*thanks to Peter Hansen

regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 18 '05 #33

P: n/a
In article <3g*********************@newsc.telia.net>,
su****@handgranat.org says...
Artie Gold wrote:
Torsten Bronger wrote:
The whole text seems to be a variant of
<http://www.artima.com/weblogs/viewpost.jsp?thread=98196>.

Tschö,
Torsten.

Ya think? ;-)


Heh. I was glad that Torsten pointed it out; I didn't get what was funny
about the joke until then.


Please consider joining the International Sarcasm Society. Our motto is
"Like We Need YOUR Support".

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-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 =----
Jul 18 '05 #34

P: n/a
T.D. Lassagne wrote:
Please consider joining the International Sarcasm Society. Our motto is
"Like We Need YOUR Support".


I *recognize* sarcasm; I just don't think it's very funny. Now parody,
which this turned out to be, I can appreciate.
Jul 18 '05 #35

P: n/a
In article <ma**************************************@python.o rg>,
=?iso-8859-1?Q?Fran=E7ois?= Pinard <pi****@iro.umontreal.ca> wrote:
[Aahz]
=?iso-8859-1?Q?Fran=E7ois?= Pinard <pi****@iro.umontreal.ca> wrote:

No doubt it once was true, but I guess this ideal has been
abandoned a few years ago. My honest feeling is that it would be a
mis-representation of Python, assertng today that this is still one
of the Python's ideals.


Mind providing evidence rather than simply citing your feelings?


The important word was "honest", not "feeling". :-)


Fair enough.
Yes, there's certainly redundancy in Python right now, but a large
portion of that will go away in Python 3.0.


And when will that be? The principle of "there is only way to do it"
was observable in Python 1.5.2, and started to disappear at that time.
How many years between 1.5.2 and 3.0?
So where's the abandonment of the ideal?


Many of us are using Python today, week after week, year long. So
let's be pragmatic. Python is what it became and now is. Let's not
define it as a memory from the past nor as a futuristic dream.


You're free to continue using 1.5.2. Why don't you? Because you want
shiny new features only available in current releases. To maintain true
"only one way", existing features would need to be removed -- but that
would break backward compatibility. Given the tension of the various
requirements, I think that Python has broken "only one way" as little as
possible, with the full intention of getting closer to its ideal when the
time comes to break backward compatibility.

You just can't have your cake and eat it, too.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code --
not in reams of trivial code that bores the reader to death." --GvR
Jul 18 '05 #36

P: n/a
Hi All--

Aahz wrote:
Given the tension of the various
requirements, I think that Python has broken "only one way" as little as
possible, with the full intention of getting closer to its ideal when the
time comes to break backward compatibility.


I wrote my mayalib package under 1.3.0. It still runs perfectly well.
I will only have to rewrite parts of it when the string module goes
away. Everything else works, and will continue to work for the
forseeable future.

That's actually less change than happened with C over the same time
period. But there, the language didn't change, just the environment
around it--includes, libs, where things lived, etc.

Metta,
Ivan
----------------------------------------------
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/worksh...oceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Jul 18 '05 #37

P: n/a
>>>>> "Sunnan" == Sunnan <su****@handgranat.org> writes:

Sunnan> It's just that I'm having a hard time matching that quote
Sunnan> to what I though python was about. I thought boring code
Sunnan> was considered a virtue in python. ("Explicit is better
Sunnan> than implicit", "sparse is better than dense".)

Boring code is code that numbs your senses with constant flow of
boilerplate crap, memory management and redundant type declarations
and general blah blah that you skip when you are trying to figure out
what a piece of code does. It's a code that you wish you could train a
monkey to write for you while you go for lunch. Think C++ or Java.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #38

P: n/a
>>>>> "Sunnan" == Sunnan <su****@handgranat.org> writes:

Sunnan> languages". I'm not sure whether I'd consider python
Sunnan> particularly terse, though, but I don't know enough about
Sunnan> it yet. (I've read a

Read up on list comprehensions and generator expressions. You'll see
the terse side of Python (and genexps look kinda poetic too ;-).

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #39

P: n/a
Ville Vainio wrote:
Read up on list comprehensions and generator expressions. You'll see
the terse side of Python (and genexps look kinda poetic too ;-).


I am familiar with lc:s/genexps, I usually program in scheme which also
has them (srfi-42).
They're very nice and I use them a lot.
Jul 18 '05 #40

P: n/a
Ville Vainio wrote:
Boring code is code that numbs your senses with constant flow of
boilerplate crap, memory management and redundant type declarations
and general blah blah that you skip when you are trying to figure out
what a piece of code does.
The python code I've read so far has looked like that. Not type
declarations, but loooong class declarations.

Also, Guido recently urged people to explicitly write recursions rather
than to use reduce - which I thought was completely in line with what
I've seen as python's goals: readability/understandability as more
important than terseness/non-boringness.
It's a code that you wish you could train a
monkey to write for you while you go for lunch. Think C++ or Java.


Oh, yes. C++ and Java can be super boring. C++ can also be pretty hard
to understand - it's not all boilerplate.

I'm not saying Python is always boring (maybe I've just been in an
easily bored mood when I've read Python stuff), and I'm not saying that
boring is always bad.

Yesterday, I read some marketing prop describing a proprietary IDE
(don't remember what language) as "exciting", and I went "Ugh, no
thanks! Give me calm computing." And then I thought - wait: I just
ranted about boringness on comp.lang.python. Can't boring and calm
sometimes mean the same thing?
Jul 18 '05 #41

P: n/a
>>>>> "Sunnan" == Sunnan <su****@handgranat.org> writes:

Sunnan> Ville Vainio wrote:

Sunnan> Also, Guido recently urged people to explicitly write
Sunnan> recursions rather than to use reduce - which I thought was
Sunnan> completely in line with what I've seen as python's goals:
Sunnan> readability/understandability as more important than
Sunnan> terseness/non-boringness.

The problem w/ reduce is that it's not intuitive. You'll have to stop
to think what the code w/ reduce does - effectively converting it to a
normal loop (not recursion!) in your head. It's a net loss when you
compare it to just reading an explicit loop as written in code.

Sunnan> Yesterday, I read some marketing prop describing a
Sunnan> proprietary IDE (don't remember what language) as
Sunnan> "exciting", and I went "Ugh, no thanks! Give me calm
Sunnan> computing." And then I thought - wait: I just ranted about
Sunnan> boringness on comp.lang.python. Can't boring and calm
Sunnan> sometimes mean the same thing?

Not for me at least. 'Boring' implies a certain sense of frustration,
not getting anywhere and generally feeling like you are wasting your
time. Human attention is a limited resource, and being bored leads to
loss of attention.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #42

P: n/a
Sunnan:
The python code I've read so far has looked like that. Not > type

declarations, but loooong class declarations.

What do you mean? Lots of repetitive
"self.variable=variable" in the __init__ method? Use of classes when
you would use closures? Or maybe you
are comparing with CLOS classes, which are pretty
slim, since the (multi)methods are defined outside
them?

Michele Simionato

Jul 18 '05 #43

P: n/a
[Aahz]
[François]
Many of us are using Python today, week after week, year long. So
let's be pragmatic. Python is what it became and now is. Let's not
define it as a memory from the past nor as a futuristic dream.

You're free to continue using 1.5.2. [...]


Sure, of course. Yet, our friendly argument is sliding away from was it
originally was. The point was about not asserting in this forum that
Python "has only one way to do it", because this is not true anymore.

The principle has been, it may be back in some distant future, but now
it is not.

--
François Pinard http://pinard.progiciels-bpi.ca
Jul 18 '05 #44

P: n/a
Aahz wrote:
You just can't have your cake and eat it, too.


I've always wondered about this turn of phrase. I seldom
eat a cake at one sitting.

-Scott David Daniels
Sc***********@Acm.Org
Jul 18 '05 #45

P: n/a
On Apr 6, 2005 4:42 PM, Scott David Daniels <Sc***********@acm.org> wrote:
I've always wondered about this turn of phrase. I seldom
eat a cake at one sitting.


Clearly you're just not trying. ;-)

--
Cheers,
Simon B,
si***@brunningonline.net,
http://www.brunningonline.net/simon/blog/
Jul 18 '05 #46

P: n/a
Sunnan wrote:
Aahz wrote:

(snip)
print "foo is", foo

Is the space added automatically? (Like awk does, if you add a comma.)


Yes. But you can also format it how you like:
print "foo is %s and that's a good news, my friends" % foo

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Jul 18 '05 #47

P: n/a
Simon Brunning <si************@gmail.com> writes:
On Apr 6, 2005 4:42 PM, Scott David Daniels <Sc***********@acm.org> wrote:
I've always wondered about this turn of phrase. I seldom
eat a cake at one sitting.


Clearly you're just not trying. ;-)


:-)))
John

Jul 18 '05 #48

This discussion thread is closed

Replies have been disabled for this discussion.