A critic of Guido's blog on Python's lambda

[Xah Lee]

Python, Lambda, and Guido van Rossum

Xah Lee, 2006-05-05

In this post, i'd like to deconstruct one of Guido's recent blog about
lambda in Python.

In Guido's blog written in 2006-02-10 at
http://www.artima.com/weblogs/viewpo...?thread=147358

is first of all, the title “Language Design Is Not Just Solving
Puzzles�. In the outset, and in between the lines, we are told that
“I'm the supreme intellect, and I created Python�.

This seems impressive, except that the tech geekers due to their
ignorance of sociology as well as lack of analytic abilities of the
mathematician, do not know that creating a language is a act that
requires little qualifications. However, creating a language that is
used by a lot people takes considerable skill, and a big part of that
skill is salesmanship. Guido seems to have done it well and seems to
continue selling it well, where, he can put up a title of belittlement
and get away with it too.

Gaudy title aside, let's look at the content of his say. If you peruse
the 700 words, you'll find that it amounts to that Guido does not like
the suggested lambda fix due to its multi-line nature, and says that he
don't think there could possibly be any proposal he'll like. The
reason? Not much! Zen is bantered about, mathematician's impractical
ways is waved, undefinable qualities are given, human's right brain is
mentioned for support (neuroscience!) , Rube Goldberg contrivance
phraseology is thrown, and coolness of Google Inc is reminded for the
tech geekers (in juxtaposition of a big notice that Guido works
there.).

If you are serious, doesn't this writing sounds bigger than its
content? Look at the gorgeous ending: “This is also the reason why
Python will never have continuations, and even why I'm uninterested in
optimizing tail recursion. But that's for another installment.� . This
benevolent geeker is gonna give us another INSTALLMENT!

There is a computer language leader by the name of Larry Wall, who said
that “The three chief virtues of a programmer are: Laziness,
Impatience and Hubris� among quite a lot of other ingenious
outpourings. It seems to me, the more i learn about Python and its
leader, the more similarities i see.

So Guido, i understand that selling oneself is a inherent and necessary
part of being a human animal. But i think the lesser beings should be
educated enough to know that fact. So that when minions follow a
leader, they have a clear understanding of why and what.

----

Regarding the lambda in Python situation... conceivably you are right
that Python lambda is perhaps at best left as it is crippled, or even
eliminated. However, this is what i want: I want Python literatures,
and also in Wikipedia, to cease and desist stating that Python supports
functional programing. (this is not necessarily a bad publicity) And, I
want the Perl literatures to cease and desist saying they support OOP.
But that's for another installment.

----
This post is archived at:
http://xahlee.org/UnixResource_dir/w...bda_guido.html

Â* Â* Xah
Â* Â* xa*@xahlee.org
∑ http://xahlee.org/

[Ken Tilton]

Thomas F. Burdick wrote:

Ken Tilton <ke*******@gmai l.com> writes:

<g> Hopefully it can be a big issue and still not justify a flame war.

Mileages will always vary, but one reason for lambda is precisely not
to have to stop, go make a new function for this one very specific
use, come back and use it as the one lambda statement, or in C have an
address to pass. but, hey, what are editors for? :)

the bigger issue is the ability of a lambda to close over arbitrary
lexically visible variables. this is something the separate function
cannot see, so one has to have a function parameter for everything.

but is such lexical scoping even on the table when Ptyhon's lambda
comes up for periodic review?

This is second-hand, as I don't actually follow Python closely, but
from what I've heard, they now have reasonable scoping rules (or maybe
they're about to, I'm not sure). And you can use def as a
Scheme-style inner define, so it's essentially a LABELS that gets the
indentation wrong.

Cool. And I know how much you like labels/flet. :)
This means they have proper closures, just not
anonymous ones. And an egregiously misnamed lambda that should be
fixed or thrown out.

If Python gets proper macros it won't matter one bit that they only
have named closures, since you can macro that away in a blink of an
eye.

Ah, well, there we go again. Without sexpr notation, the lexer/parser
again will be "hard", and "hardly worth it": we get even more sour
grapes, this time about macros not being such a big deal.

One of the hardest things for a technologist to do is admit that a neat
idea has to be abandoned. Initial success creates a giddy
over-commitment to the design choice. After then all difficulties get
brushed aside or kludged.

This would not be a problem for Python if it had stayed a scripting
language... well, maybe "no Macro!s" and "no real lambda!" and "no
continuations!" are GvR's way of keeping Python just a scripting language.

:)

kenny

--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.

[Ken Tilton]

Martin P. Hellwig wrote:

Bill Atkins wrote:
<cut>

How do you define scalability?
http://www.google.com/search?hl=en&q...=Google+Search

Damn! Google can do that?! Omigod!!! Not joking, I never knew that,a
lways used dictionary.com. Thx! I meant:
The ability to add power and capability to an existing system without significant expense or overhead.
www.yipes.com/care/cc_glossary.shtml

The number of definitions explains why most respondents should save
their breath. Natural language is naturally ambiguous. Meanwhile Usenet
is the perfect place to grab one meaning out of a dozen and argue over
the implications of that one meaning which of course is never the one
originally intended, as any reasonable, good faith reader would admit.

kenny
--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.

[Ken Tilton]

Kay Schluehr wrote:

Ken Tilton wrote:

Oh, my, you are preaching to the herd (?!) of lemmings?! Please tell me
you are aware that lemmings do not have ears. You should just do Lisp
all day and add to the open source libraries to speed Lisp's ascendance.
The lemmings will be liberated the day Wired puts John McCarthy on the
cover, and not a day sooner anyway.

And then the 12th vanished Lisper returns and Lispers are not
suppressed anymore and won't be loosers forever. The world will be
united in the name of Lisp and Lispers will be leaders and honorables.
People stop worrying about Lispers as psychpaths and do not consider
them as zealots, equipped with the character of suicide bombers. No,
Lisp means peace and paradise.

"The Twelfth Vanished Lisper"? I love it. Must start a secret society....

:)

kenny

--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.

[Paul Rubin]

"Martin P. Hellwig" <mh******@xs4al l.nl> writes:

This is a weird approach. Why not let the "ticket" by the (maybe
encrypted) PRNG seed that generates the permutation?
Because the server that handles the generate request doesn't need to
be the same as the one that handles the request to give the client
that deck.

Wait a sec, are you giving the entire shuffled deck to the client?
Can you describe the application? I was imagining an online card game
where clients are playing against each other. Letting any client see
the full shuffle is disastrous.
But if the ticket is given to the client, than any other server can
serve back that ticket to give the shuffled deck, unless the ZFS dies
of course but then again thats why I use ZFS so I can mirror them om 4
different machines in 2 different locations.

I don't know what good that hardware crypto is doing you, if you're
then writing out the shuffled deck to disk in the clear.

It's not about access security it's more about the best possible
randomness to shuffle the deck.

Depending on just what the server is for, access security may be a far
more important issue. If I'm playing cards online with someone, I'd
be WAY more concerned about the idea of my opponent being able to see
my cards by breaking into the server, than his being able to
cryptanalyze a well-designed PRNG based solely on its previous
outputs.

[Martin P. Hellwig]

Paul Rubin wrote:

"Martin P. Hellwig" <mh******@xs4al l.nl> writes:

This is a weird approach. Why not let the "ticket" by the (maybe
encrypted) PRNG seed that generates the permutation? Because the server that handles the generate request doesn't need to
be the same as the one that handles the request to give the client
that deck.

Wait a sec, are you giving the entire shuffled deck to the client?
Can you describe the application? I was imagining an online card game
where clients are playing against each other. Letting any client see
the full shuffle is disastrous.

Nope I have a front end service that does the client bit, its about this
(in this context, there are more services of course):

crypto - ZFS - table servers - mirror dispatching - client xmlrpc access
- client ( last one has not been written yet )

<cut>
Depending on just what the server is for, access security may be a far
more important issue. If I'm playing cards online with someone, I'd
be WAY more concerned about the idea of my opponent being able to see
my cards by breaking into the server, than his being able to
cryptanalyze a well-designed PRNG based solely on its previous
outputs.

Only client xmlrpc access is (should be) accessible from the outside and
since this server is user session based they only see their own card.
However this project is still in it's early development, I'm doing now
initial alpha-tests (and stress testing) and after this I'm going to let
some audit bureau's check for security (probably Madison-Ghurka, but I
haven't asked them yet).

--
mph

[Thomas F. Burdick]

[ I pruned the cross-posting down to a reasonable level ]

Ken Tilton <ke*******@gmai l.com> writes:

Thomas F. Burdick wrote:

This is second-hand, as I don't actually follow Python closely, but
from what I've heard, they now have reasonable scoping rules (or maybe
they're about to, I'm not sure). And you can use def as a
Scheme-style inner define, so it's essentially a LABELS that gets the
indentation wrong.

Cool. And I know how much you like labels/flet. :)

Well, I love LABELS but I hate inner defines with an equal passion --
so for me it's a wash :-)

As much as I like nice low-level, close-to-the-machine mechanisms as
labels and lambda, sometimes you just want the high-level
expressiveness of tagbody/go, which Python doesn't have ... which in
my opinion is quite a crime to readability and the ability to
transcribe Knuth algorithms, which any engineer should find offensive
to their sensibilities.

This means they have proper closures, just not
anonymous ones. And an egregiously misnamed lambda that should be
fixed or thrown out.
If Python gets proper macros it won't matter one bit that they only
have named closures, since you can macro that away in a blink of an
eye.

Ah, well, there we go again. Without sexpr notation, the lexer/parser
again will be "hard", and "hardly worth it": we get even more sour
grapes, this time about macros not being such a big deal.

One of the hardest things for a technologist to do is admit that a
neat idea has to be abandoned. Initial success creates a giddy
over-commitment to the design choice. After then all difficulties get
brushed aside or kludged.

Y'never know, they could always Greenspun their way to almost-sexps.
What with the way that selective pressure works, it's gonna be that or
die, so it is a possibility.

[Alex Martelli]

Ken Tilton <ke*******@gmai l.com> wrote:

Martin P. Hellwig wrote:

Bill Atkins wrote:
<cut>

How do you define scalability?
http://www.google.com/search?hl=en&q...=Google+Search

Damn! Google can do that?! Omigod!!! Not joking, I never knew that,a

You're welcome; we do have several little useful tricks like that.
lways used dictionary.com. Thx! I meant:

The ability to add power and capability to an existing system without
significant expense or overhead. www.yipes.com/care/cc_glossary.shtml

Excellent -- just the definition of "scalabilit y" that Google and its
competitor live and die by ((OK, OK, I'm _not_ implying that such issues
as usability &c don't matter, by no means -- but, I live mostly in the
world of infrastructure, where scalability and reliability reign)).

The number of definitions explains why most respondents should save
their breath. Natural language is naturally ambiguous. Meanwhile Usenet
is the perfect place to grab one meaning out of a dozen and argue over
the implications of that one meaning which of course is never the one
originally intended, as any reasonable, good faith reader would admit.

However, you and I are/were discussing exactly the same nuance of
meaning, either by a funny quirk of fate or because it's the one that
really matters in large-scale programming (and more generally,
large-scale systems). E.g., if your existing system can gracefully
handle your current traffic of, say, a billion queries of complexity X,
you want to be able to rapidly add a feature that will increase the
average query's complexity to (X+dX) and attract 20% more users, so
you'll need to handle 1.2 billion queries just as gracefully: i.e., you
need to be able to add power and capability to your existing system,
rapidly and reliably, just as that definition says.

When this is the challenge, your choice of programming language is not
the first order of business, of course -- your hardware and network
architecture loom large, and so does the structuring of your
applications and infrastructure software across machines and networks.
Still, language does matter, at a "tertiary" level if you will. Among
the potential advantages of Lisp is the fact that you could use Lisp
across almost all semantic levels ("almost" because I don't think "Lisp
machines" are a realistic option nowadays, so lower levels of the stack
would remain in C and machine language -- but those levels may probably
be best handled by a specialized squad of kernel-level and device-driver
programmers, anyway); among the potential advantages of Python, the fact
that (while not as suited as Lisp to lower-level coding, partly because
of a lack of good solid compilers to make machine language out of it),
it brings a powerful drive to uniformity, rather than a drive towards a
host of "domain-specific" Little Languages as is encouraged by Lisp's
admirably-powerful macro system.

One key axis of scalability here is, how rapidly can you grow the teams
of people that develop and maintain your software base? To meet all the
challenges and grasp all the opportunities of an exploding market,
Google has had to almost-double its size, in terms of number of
engineers, every year for the last few years -- I believe that doing so
while keeping stellar quality and productivity is an unprecedented feat,
and while (again!) the choice of language(s) is not a primary factor
(most kudos must go to our management and its approaches and methods, of
course, and in particular to the strong corporate identity and culture
they managed to develop and maintain), it still does matter. The
uniformity of coding style and practices in our codebase is strong.

We don't demand Python knowledge from all the engineers we hire: for any
"engineerin g superstar" worth the adjective, Python is really easy and
fast to pick up and start using productively -- I've seen it happen
thousands of times, both in Google and in my previous career, and not
just for engineers with a strong software background, but also for those
whose specialties are hardware design, network operations, etc, etc. The
language's simplicity and versatility allow this. Python "fits people's
brains" to an unsurpassed extent -- in a way that, alas, languages
requiring major "paradigm shifts" (such as pure FP languages, or Common
Lisp, or even, say, Smalltalk, or Prolog...) just don't -- they really
require a certain kind of mathematical mindset or predisposition which
just isn't as widespread as you might hope. Myself, I do have more or
less that kind of mindset, please note: while my Lisp and scheme are
nowadays very rusty, proficiency with them was part of what landed me my
first job, over a quarter century ago (microchip designers with a good
grasp of lisp-ish languages being pretty rare, and TI being rather
hungry for them at the time) -- but I must acknowlegde I'm an exception.

Of course, the choice of Python does mean that, when we really truly
need a "domain specific little language", we have to implement it as a
language in its own right, rather than piggybacking it on top of a
general-purpose language as Lisp would no doubt afford; see
<http://labs.google.com/papers/sawzall.html> for such a DSLL developed
at Google. However, I think this tradeoff is worthwhile, and, in
particular, does not impede scaling.
Alex

[Luc The Perverse]

"John Bokma" <jo**@castleamb er.com> wrote in message
news:Xn******** *************** *@130.133.1.4.. .

Reported for excessive crossposting.

Did u report yourself?

--
LTP

:)

[Ken Tilton]

Alex Martelli wrote:

Ken Tilton <ke*******@gmai l.com> wrote:

Martin P. Hellwig wrote:

Bill Atkins wrote:
<cut>

How do you define scalability?
http://www.google.com/search?hl=en&q...=Google+Search

Damn! Google can do that?! Omigod!!! Not joking, I never knew that,a

You're welcome; we do have several little useful tricks like that.

lways used dictionary.com. Thx! I meant:

The ability to add power and capability to an existing system without
significan t expense or overhead. www.yipes.com/care/cc_glossary.shtml

Excellent -- just the definition of "scalabilit y" that Google and its
competitor live and die by ((OK, OK, I'm _not_ implying that such issues
as usability &c don't matter, by no means -- but, I live mostly in the
world of infrastructure, where scalability and reliability reign)).

The number of definitions explains why most respondents should save
their breath. Natural language is naturally ambiguous. Meanwhile Usenet
is the perfect place to grab one meaning out of a dozen and argue over
the implications of that one meaning which of course is never the one
originally intended, as any reasonable, good faith reader would admit.

However, you and I are/were discussing exactly the same nuance of
meaning, either by a funny quirk of fate or because it's the one that
really matters in large-scale programming (and more generally,
large-scale systems). E.g., if your existing system can gracefully
handle your current traffic of, say, a billion queries of complexity X,
you want to be able to rapidly add a feature that will increase the
average query's complexity to (X+dX) and attract 20% more users, so
you'll need to handle 1.2 billion queries just as gracefully: i.e., you
need to be able to add power and capability to your existing system,
rapidly and reliably, just as that definition says.

When this is the challenge, your choice of programming language is not
the first order of business, of course ...

Looks like dictionaries are no match for the ambiguity of natural
language. :) Let me try again: it is Python itself that cannot scale, as
in gain "new power and capability", and at least in the case of lambda
it seems to be because of indentation-sensitivity.

Is that not what GvR said?

By contrast, in On Lisp we see Graham toss off Prolog in Chapter 22 and
an object system from scratch in Chapter 25. Lite versions, to be sure,
but you get the idea.

My sig has a link to a hack I developed after doing Lisp for less than a
month, and without lambda (and to a lesser degree macros) it would be
half the tool it is. It adds a declarative paradigm to the CL object
system, and is built on nothing but ansi standard Lisp. Yet it provides
new power and capability. And that by an application programmer just
working on a nasty problem, never mind the language developer.

I just find it interesting that sexpr notation (which McCarthy still
wants to toss!) is such a huge win, and that indentation seems to be so
limiting.
-- your hardware and network architecture loom large, and so does the structuring of your
applications and infrastructure software across machines and networks.
Still, language does matter, at a "tertiary" level if you will. Among
the potential advantages of Lisp is the fact that you could use Lisp
across almost all semantic levels ("almost" because I don't think "Lisp
machines" are a realistic option nowadays, so lower levels of the stack
would remain in C and machine language -- but those levels may probably
be best handled by a specialized squad of kernel-level and device-driver
programmers, anyway); among the potential advantages of Python, the fact
that (while not as suited as Lisp to lower-level coding, partly because
of a lack of good solid compilers to make machine language out of it),
it brings a powerful drive to uniformity, rather than a drive towards a
host of "domain-specific" Little Languages as is encouraged by Lisp's
admirably-powerful macro system.

One key axis of scalability here is, how rapidly can you grow the teams
of people that develop and maintain your software base?
I am with Brooks on the Man-Month myth, so I am more interested in /not/
growing my team. If Lisp is <pick a number, any numer> times more
expressive than Python, you need exponentially fewer people.

In some parallel universe Norvig had the cojones to dictate Lisp to
Google and they listened, and in that universe... I don't know, maybe
GMail lets me click on the sender column to sort my mail? :)
To meet all the
challenges and grasp all the opportunities of an exploding market,
Google has had to almost-double its size, in terms of number of
engineers, every year for the last few years -- I believe that doing so
while keeping stellar quality and productivity is an unprecedented feat,
and while (again!) the choice of language(s) is not a primary factor
(most kudos must go to our management and its approaches and methods, of
course, and in particular to the strong corporate identity and culture
they managed to develop and maintain), it still does matter. The
uniformity of coding style and practices in our codebase is strong.
Well, you said it for me. Google hires the best and pays a lot. Hey, I
wrote great code in Cobol. So as much as you want to brag on yourself
and Google <g>, your success does not address:

Indentation-sensitivity: Is it holding Python back?

We don't demand Python knowledge from all the engineers we hire: for any
"engineerin g superstar" worth the adjective, Python is really easy and
fast to pick up and start using productively -- I've seen it happen
thousands of times, both in Google and in my previous career, and not
just for engineers with a strong software background, but also for those
whose specialties are hardware design, network operations, etc, etc. The
language's simplicity and versatility allow this. Python "fits people's
brains" to an unsurpassed extent -- in a way that, alas, languages
requiring major "paradigm shifts" (such as pure FP languages, or Common
Lisp, or even, say, Smalltalk, or Prolog...) just don't -- they really
require a certain kind of mathematical mindset or predisposition which
just isn't as widespread as you might hope.
Talk about Lisp myths. The better the language, the easier the language.
And the best programmers on a team get to develop tools and macrology
that empower the lesser lights, so (a) they have fun work that keeps
them entertained while (b) the drones who just want to get through the
day are insanely productive, too.

Another myth (or is this the same?) is this "pure FP" thing. Newbies can
and usually do code as imperatively as they wanna be. Until someone else
sees their code, tidies it up, and the light bulb goes on. But CL does
not force a sharp transition on anyone.

Myself, I do have more or
less that kind of mindset, please note: while my Lisp and scheme are
nowadays very rusty, proficiency with them was part of what landed me my
first job, over a quarter century ago (microchip designers with a good
grasp of lisp-ish languages being pretty rare, and TI being rather
hungry for them at the time) -- but I must acknowlegde I'm an exception.

Of course, the choice of Python does mean that, when we really truly
need a "domain specific little language", we have to implement it as a
language in its own right, rather than piggybacking it on top of a
general-purpose language as Lisp would no doubt afford; see
<http://labs.google.com/papers/sawzall.html> for such a DSLL developed
at Google.

No lambdas? Static typing?! eewwwewww. :) Loved the movie, tho.

Come on, try just one meaty Common Lisp project at Google. Have someone
port Cells to Python. I got halfway done but decided I would rather be
doing Lisp. uh-oh. Does Python have anything like special variables? :)

Kenny

--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.

[Ken Tilton]

Ken Tilton wrote:

Come on, try just one meaty Common Lisp project at Google. Have someone
port Cells to Python. I got halfway done but decided I would rather be
doing Lisp. uh-oh. Does Python have anything like special variables? :)

Omigod. I scare myself sometimes. This would be a great Summer of Code
project. Port Cells (see sig) to Python. Trust me, this is Silver Bullet
stuff. (Brooks was wrong on that.)

If a strong Pythonista wants to submit a proposal, er, move fast. I am
mentoring through LispNYC: http://www.lispnyc.org/soc.clp

Gotta be all over Python metaclasses, and everything else pure Python.
PyGtk would be a good idea for the demo, which will involve a GUI mini
app. Just gotta be able to /read/ Common Lisp.

kenny

--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.