Lambda: the Ultimate Design Flaw

[Daniel Silva]

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/plt-scheme/2005-April/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

 

[Erik Max Francis]

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/plt-scheme/2005-April/008382.html

April Fool's Day again, eh?

 

[alex goldman]

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.

 

[Sunnan]

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!

 

[Hans Oesterholt-Dijkema]

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?

 

[Torsten Bronger]

Hallöchen!

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/plt-scheme/2005-April/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.

 

[Jeremy Bowers]

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.

 

[Sunnan]

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

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

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

 

[Joe Marshall]

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.

 

[Ulrich Hobelmann]

Daniel Silva wrote:




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!

 

[Tom Breton]

[...]

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

 

[Aahz]

[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 ([email protected]) <*> 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

 

[Bengt Richter]

[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 ([email protected]) <*> 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

 

[Sunnan]

"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

 

[Tim Peters]

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

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Aahz]

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.

 

[Steve Holden]

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

Daniel Silva wrote:




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

 

[Sunnan]

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