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/

[Tomasz Zielonka]

Alex Martelli wrote:

Tomasz Zielonka <to************ *@gmail.com> wrote:

Alex Martelli wrote:

> Having to give functions a name places no "ceiling on expressiveness" ,
> any more than, say, having to give _macros_ a name.

And what about having to give numbers a name?

Excellent style, in most cases; I believe most sensible coding guides
recommend it for most numbers -- cfr
<http://en.wikipedia.or g/wiki/Magic_number_(p rogramming)> , section
"magic numbers in code".

I was a bit unclear. I didn't mean constants (I agree with you on
magic numbers), but results of computations, for example

(x * 2) + (y * 3)

Here (x * 2), (y * 3) and (x * 2) + 3 are anonymous numbers ;-)

Would you like if you were forced to write it this way:

a = x * 2
b = y * 3
c = a * b

?

Thanks for your answers to my questions.

Best regards
Tomasz

[Serge Orlov]

Ken Tilton wrote:

It is vastly more disappointing that an alleged tech genius would sniff
at the chance to take undeserved credit for PyCells, something probably
better than a similar project on which Adobe (your superiors at
software, right?) has bet the ranch. This is the Grail, dude, Brooks's
long lost Silver Bullet. And you want to pass?????

C'mon, Alex, I just want you as co-mentor for your star quality. Of
course you won't have to do a thing, just identify for me a True Python
Geek and she and I will take it from there.

Here's the link in case you lost it:

http://www.lispnyc.org/wiki.clp?page=PyCells

:)

peace, kenny

ps. flaming aside, PyCells really would be amazingly good for Python.
And so Google. (Now your job is on the line. <g>) k

Perhaps I'm missing something but what's the big deal about PyCells?
Here is 22-lines barebones implementation of spreadsheet in Python,
later I create 2 cells "a" and "b", "b" depends on a and evaluate all
the cells. The output is

a = negate(sin(pi/2)+one) = -2.0
b = negate(a)*10 = 20.0

=============== ==== spreadsheet.py =============== ===
class Spreadsheet(dic t):
def __init__(self, **kwd):
self.namespace = kwd
def __getitem__(sel f, cell_name):
item = self.namespace[cell_name]
if hasattr(item, "formula"):
return item()
return item
def evaluate(self, formula):
return eval(formula, self)
def cell(self, cell_name, formula):
"Create a cell defined by formula"
def evaluate_cell() :
return self.evaluate(f ormula)
evaluate_cell.f ormula = formula
self.namespace[cell_name] = evaluate_cell
def cells(self):
"Yield all cells of the spreadsheet along with current values
and formulas"
for cell_name, value in self.namespace. items():
if not hasattr(value, "formula"):
continue
yield cell_name, self[cell_name], value.formula

import math
def negate(x):
return -x
sheet1 = Spreadsheet(one =1, sin=math.sin, pi=math.pi, negate=negate)
sheet1.cell("a" , "negate(sin (pi/2)+one)")
sheet1.cell("b" , "negate(a)* 10")
for name, value, formula in sheet1.cells():
print name, "=", formula, "=", value

[Bill Atkins]

"Serge Orlov" <Se*********@gm ail.com> writes:

Ken Tilton wrote:

It is vastly more disappointing that an alleged tech genius would sniff
at the chance to take undeserved credit for PyCells, something probably
better than a similar project on which Adobe (your superiors at
software, right?) has bet the ranch. This is the Grail, dude, Brooks's
long lost Silver Bullet. And you want to pass?????

C'mon, Alex, I just want you as co-mentor for your star quality. Of
course you won't have to do a thing, just identify for me a True Python
Geek and she and I will take it from there.

Here's the link in case you lost it:

http://www.lispnyc.org/wiki.clp?page=PyCells

:)

peace, kenny

ps. flaming aside, PyCells really would be amazingly good for Python.
And so Google. (Now your job is on the line. <g>) k

Perhaps I'm missing something but what's the big deal about PyCells?
Here is 22-lines barebones implementation of spreadsheet in Python,
later I create 2 cells "a" and "b", "b" depends on a and evaluate all
the cells. The output is

a = negate(sin(pi/2)+one) = -2.0
b = negate(a)*10 = 20.0

=============== ==== spreadsheet.py =============== ===
class Spreadsheet(dic t):
def __init__(self, **kwd):
self.namespace = kwd
def __getitem__(sel f, cell_name):
item = self.namespace[cell_name]
if hasattr(item, "formula"):
return item()
return item
def evaluate(self, formula):
return eval(formula, self)
def cell(self, cell_name, formula):
"Create a cell defined by formula"
def evaluate_cell() :
return self.evaluate(f ormula)
evaluate_cell.f ormula = formula
self.namespace[cell_name] = evaluate_cell
def cells(self):
"Yield all cells of the spreadsheet along with current values
and formulas"
for cell_name, value in self.namespace. items():
if not hasattr(value, "formula"):
continue
yield cell_name, self[cell_name], value.formula

import math
def negate(x):
return -x
sheet1 = Spreadsheet(one =1, sin=math.sin, pi=math.pi, negate=negate)
sheet1.cell("a" , "negate(sin (pi/2)+one)")
sheet1.cell("b" , "negate(a)* 10")
for name, value, formula in sheet1.cells():
print name, "=", formula, "=", value

I hope Ken doesn't mind me answering for him, but Cells is not a
spreadsheet (where did you get that idea?). It does apply the basic
idea of a spreadsheet to software - that is, instead of updating value
when some event occurs, you specify in advance how that value can be
computed and then you stop worrying about keeping it updated.

Incidentally, is this supposed to be an example of Python's supposed
"aesthetic pleasantness"? I find it a little hideous, even giving you
the benefit of the doubt and pretending there are newlines between
each function. There's nothing like a word wrapped in pairs of
underscores to totally ruin an aesthetic experience.

P.S. Is this really a spreadsheet? It looks like it's a flat
hashtable...

--
This is a song that took me ten years to live and two years to write.
- Bob Dylan

[Bill Atkins]

Bill Atkins <NO**********@r pi.edu> writes:

Incidentally, is this supposed to be an example of Python's supposed
"aesthetic pleasantness"? I find it a little hideous, even giving you
the benefit of the doubt and pretending there are newlines between
each function. There's nothing like a word wrapped in pairs of
underscores to totally ruin an aesthetic experience.

I don't mean to suggest that your code in particular is hideous -
sorry if it came off that way. It's just that Python code seems a
disappointingly un-pretty after all the discussion about its beauty in
this thread.

--
This is a song that took me ten years to live and two years to write.
- Bob Dylan

[Kay Schluehr]

Tomasz Zielonka wrote:

On the other hand, what do you get by allowing ( as an indentifier?

Significant whitespace is a good thing, but the way it is designed in
Python it has some costs. Can't you simply acknowledge that?

One can admit this but what is it worth or how should those costs be
evaluated? This problem is unsolvable because we cannot agree on a
common standard of the value of PL design. All we can do is making the
decisions more visible. Obviously Lispers want the boundary between
application-level and interpreter-level programming as low as possible.
It is still present but making it invisible and expressing language
semantics through the language is regarded of high value. This makes
application level meta-programming as simple as it could be. Others
tend to separate the concerns/boundaries more strictly and standardize
the language while implementing all features regarded necessary for
application-level programming in a huge opaque runtime and a vast
amount of libraries. Application level metaprogramming is restricted to
runtime-reflection, metaclass-protocols, annotations etc. From this
point of view a programming language is basically an interface to a
virtual machine that is much like an operating system i.e. it supports
basic functions and hides complexity. This is the way Java and Python
have gone. The benefit of the latter approach lies not so much in
creating new language capabilities but considering the language as just
another application where requirement engineering and carefull design
can be done without sprawling in every possible direction ( see Forth
as an example for this tendency ). This way standard libraries (
"batteries included" ) become almost equal important and
"language-designer" is a job that is not once be done. This is roughly
my interpretation of GvRs "design view" on PLs that Xah Lee obviously
doesn't get - Xah is not important here, because he never gets anything
right but here are enough Lispers with quite some working brain cells
who seem to think that the best thing to do is giving a programmer
unlimited programming power.

Concluding remark: I'm not sure I want to defend one point of view all
the way long. Although not being a Lisper myself I can clearly see that
the DSL topic is hot these days and the pendulum oscillates into the
direction of more liberty. I have mixed feelings about this but I have
my own strong opinion of how those *can* fit into the CPython design
space and a working model that is to be published soon. As with the
dialectic double negation there is no return to a former position.

[brian]

Bill Atkins wrote:

Does Python have any support for closures? If so, ignore this point.
But if not, what about examples like this:

(defun make-window (window observer)
;; initialization code here
(add-handler window 'close
(lambda (event)
(notify observer event)))
;; more code)

Being able to keep pass around state with functions is useful.
I agree and Python supports this. What is interesting is how
counter-intuitive many programmers find this. For example, one of my
colleges (who is a reasonably average programmer), was completely
stumped by this:

def right_partial(f n, *args): .... def inner(*innerarg s):
.... return fn(*(innerargs + args))
.... return inner
.... square = right_partial(p ow, 2)
square(5) 25 cube = right_partial(p ow, 3)
cube(5)

125

(for those of you unfamiliar with Python, the '>>>' and '...' means
that I typed this in the interactive shell)

So I try to use this sort of pattern sparingly because many programmers
don't think of closures as a way of saving state. That might be because
it is not possible to do so in most mainstream languages.

There are already some people in the Python community who think that
Python has already gone too far in supporting "complex" language
features and now imposes two steep a learning curve i.e. you now have
to know a lot to be considered a Python expert. And there is a lot of
resistance to adding features that will raise the bar even higher.
There are also cases where a function is so trivial that the simplest
way to describe it is with its source code, where giving it a name and
putting it at the beginning of a function is just distracting and
time-consuming. E.g.:

(remove-if (lambda (name)
(find #\- name :test #'char=))
list-of-names)
There are some ways to write it in Python (if I understand the code):

# prefered
[name for name in list_of_names if '-' not in name]

OR:

# 2nd choice
def contains_no_das h(name):
return '-' not in name

filter(contains _no_dash, list_of_names)

# not recommended
filter(lambda name: return '-' not in name, list_of_names)

What's the sense of giving that function its own name? It's much
clearer to simply write it in place. Yes, it's _possible_ to use
named functions, but in this case its functionality is so simple that
it's clearer to simply type it in place. Why is this expressiveness a
bad thing, aside from its power to wreck an indentation-significant
language?

There are a few people in the Python community who think that unnamed
functions are inherently inferior to named ones because the name
provides documentation. The majority probably just don't care about the
issue at all. I will say that I am not sure that I know what your LISP
code does. However, even if you didn't understand the Python code in my
named-function version, the name "contains_no_da sh" might provide you
with a small clue.

Cheers,
Brian

[Serge Orlov]

Bill Atkins wrote:

"Serge Orlov" <Se*********@gm ail.com> writes:

Ken Tilton wrote:

It is vastly more disappointing that an alleged tech genius would sniff
at the chance to take undeserved credit for PyCells, something probably
better than a similar project on which Adobe (your superiors at
software, right?) has bet the ranch. This is the Grail, dude, Brooks's
long lost Silver Bullet. And you want to pass?????

C'mon, Alex, I just want you as co-mentor for your star quality. Of
course you won't have to do a thing, just identify for me a True Python
Geek and she and I will take it from there.

Here's the link in case you lost it:

http://www.lispnyc.org/wiki.clp?page=PyCells

:)

peace, kenny

ps. flaming aside, PyCells really would be amazingly good for Python.
And so Google. (Now your job is on the line. <g>) k
Perhaps I'm missing something but what's the big deal about PyCells?
Here is 22-lines barebones implementation of spreadsheet in Python,
later I create 2 cells "a" and "b", "b" depends on a and evaluate all
the cells. The output is

a = negate(sin(pi/2)+one) = -2.0
b = negate(a)*10 = 20.0

=============== ==== spreadsheet.py =============== ===
class Spreadsheet(dic t):
def __init__(self, **kwd):
self.namespace = kwd
def __getitem__(sel f, cell_name):
item = self.namespace[cell_name]
if hasattr(item, "formula"):
return item()
return item
def evaluate(self, formula):
return eval(formula, self)
def cell(self, cell_name, formula):
"Create a cell defined by formula"
def evaluate_cell() :
return self.evaluate(f ormula)
evaluate_cell.f ormula = formula
self.namespace[cell_name] = evaluate_cell
def cells(self):
"Yield all cells of the spreadsheet along with current values
and formulas"
for cell_name, value in self.namespace. items():
if not hasattr(value, "formula"):
continue
yield cell_name, self[cell_name], value.formula

import math
def negate(x):
return -x
sheet1 = Spreadsheet(one =1, sin=math.sin, pi=math.pi, negate=negate)
sheet1.cell("a" , "negate(sin (pi/2)+one)")
sheet1.cell("b" , "negate(a)* 10")
for name, value, formula in sheet1.cells():
print name, "=", formula, "=", value

I hope Ken doesn't mind me answering for him, but Cells is not a
spreadsheet (where did you get that idea?).

It's written on the page linked above, second sentence: "Think of the
slots as cells in a spreadsheet, and you've got the right idea". I'm
not claiming that my code is full PyCell implementation.

It does apply the basic
idea of a spreadsheet to software - that is, instead of updating value
when some event occurs, you specify in advance how that value can be
computed and then you stop worrying about keeping it updated.
The result is the same. Of course, I don't track dependances in such a
tiny barebones example. But when you retrieve a cell you will get the
same value as with dependances. Adding dependances is left as an
exercise.

Incidentally, is this supposed to be an example of Python's supposed
"aesthetic pleasantness"?
Nope. This is an example that you don't need macros and
multi-statements. Ken writes: "While the absence of macros and
multi-statement lambda in Python will make coding more cumbersome". I'd
like to see Python code doing the same if the language had macros and
multi-statement lambda. Will it be more simple? More expressive?
I find it a little hideous, even giving you
the benefit of the doubt and pretending there are newlines between
each function. There's nothing like a word wrapped in pairs of
underscores to totally ruin an aesthetic experience.
I don't think anyone who is not a master of a language can judge
readability. You're just distracted by insignificant details, they
don't matter if you code in that language for many years. I'm not going
to tell you how Lisp Cell code looks to me ;)
P.S. Is this really a spreadsheet? It looks like it's a flat
hashtable...

Does it matter if it's flat or 2D?

[brian]

Bill Atkins wrote:

Buh? The project doesn't have to be late for Brooks's law to hold;
adding programmers, so goes Brooks reasoning, will always increase the
time required to complete the project because of various communication
issues.
1. This is not what Brooks says. Brooks was talking about late
projects. Please provide a supporting quote if you wish to continue
to claim that "adding programmers will always increase the time
required to complete the project".
2. There has to be a mechanism where an organization can add
developers - even if it is only for new projects. Python advocates
would say that getting developers up to speed on Python is easy
because:

- it fits most programmers brains i.e. it is similar enough to
languages that most programmers have experience with and the
differences are usually perceived to beneficial (exception:
people from a Java/C/C++ background often perceive dynamic
typing as a misfeature and have to struggle with it)
- the language is small and simple
- "magic" is somewhat frowned upon in the Python community i.e.
most code can be taken at face value without needing to learn a
framework, mini-language, etc. (but I think that the Python
community could do better on this point)

I'm sure that smarter people can think of more points.
Fair enough. But what does Python offer above any garbage-collected
language that makes it so scalable?

See above point - you can more easily bring programmers online in your
organization because most programmers find Python easily learnable.
And, as a bonus, it is actually a pretty flexible, powerful language.

Cheers,
Brian

[I V]

On Sat, 06 May 2006 23:05:59 -0700, Alex Martelli wrote:

Tomasz Zielonka <to************ *@gmail.com> wrote:
...

higher level languages. There are useful programming techniques, like
monadic programming, that are infeasible without anonymous functions.
Anonymous functions really add some power to the language.

Can you give me one example that would be feasible with anonymous
functions, but is made infeasible by the need to give names to
functions? In Python, specifically, extended with whatever fake syntax
you favour for producing unnamed functions?

Monads are one of those parts of functional programming I've never really
got my head around, but as I understand them, they're a way of
transforming what looks like a sequence of imperative programming
statements that operate on a global state into a sequence of function
calls that pass the state between them.

So, what would be a statement in an imperative language is an anonymous
function that gets added to the monad, and then, when the monad is run,
these functions get executed. The point being, that you have a lot of
small functions (one for each statement) which are likely not to be used
anywhere else, so defining them as named functions would be a bit of a
pain in the arse.

Actually, defining them as unnamed functions via lambdas would be annoying
too, although not as annoying as using named functions - what you really
want is macros, so that what looks like a statement can be interpreted is
a piece of code to be executed later.

Here, for instance, is an article about using scheme (and, in particular,
macros), to produce a fairly elegant monad implementation:

http://okmij.org/ftp/Scheme/monad-in-Scheme.html

[Bill Atkins]

"Serge Orlov" <Se*********@gm ail.com> writes:

Bill Atkins wrote:

"Serge Orlov" <Se*********@gm ail.com> writes:

> Ken Tilton wrote:
>> It is vastly more disappointing that an alleged tech genius would sniff
>> at the chance to take undeserved credit for PyCells, something probably
>> better than a similar project on which Adobe (your superiors at
>> software, right?) has bet the ranch. This is the Grail, dude, Brooks's
>> long lost Silver Bullet. And you want to pass?????
>>
>> C'mon, Alex, I just want you as co-mentor for your star quality. Of
>> course you won't have to do a thing, just identify for me a True Python
>> Geek and she and I will take it from there.
>>
>> Here's the link in case you lost it:
>>
>> http://www.lispnyc.org/wiki.clp?page=PyCells
>>
>> :)
>>
>> peace, kenny
>>
>> ps. flaming aside, PyCells really would be amazingly good for Python.
>> And so Google. (Now your job is on the line. <g>) k
>
> Perhaps I'm missing something but what's the big deal about PyCells?
> Here is 22-lines barebones implementation of spreadsheet in Python,
> later I create 2 cells "a" and "b", "b" depends on a and evaluate all
> the cells. The output is
>
> a = negate(sin(pi/2)+one) = -2.0
> b = negate(a)*10 = 20.0
>
> =============== ==== spreadsheet.py =============== ===
> class Spreadsheet(dic t):
> def __init__(self, **kwd):
> self.namespace = kwd
> def __getitem__(sel f, cell_name):
> item = self.namespace[cell_name]
> if hasattr(item, "formula"):
> return item()
> return item
> def evaluate(self, formula):
> return eval(formula, self)
> def cell(self, cell_name, formula):
> "Create a cell defined by formula"
> def evaluate_cell() :
> return self.evaluate(f ormula)
> evaluate_cell.f ormula = formula
> self.namespace[cell_name] = evaluate_cell
> def cells(self):
> "Yield all cells of the spreadsheet along with current values
> and formulas"
> for cell_name, value in self.namespace. items():
> if not hasattr(value, "formula"):
> continue
> yield cell_name, self[cell_name], value.formula
>
> import math
> def negate(x):
> return -x
> sheet1 = Spreadsheet(one =1, sin=math.sin, pi=math.pi, negate=negate)
> sheet1.cell("a" , "negate(sin (pi/2)+one)")
> sheet1.cell("b" , "negate(a)* 10")
> for name, value, formula in sheet1.cells():
> print name, "=", formula, "=", value
>

I hope Ken doesn't mind me answering for him, but Cells is not a
spreadsheet (where did you get that idea?).

It's written on the page linked above, second sentence: "Think of the
slots as cells in a spreadsheet, and you've got the right idea". I'm
not claiming that my code is full PyCell implementation.

Unfortunately, it's *nothing* like a full PyCell implementation. I
explained what Cells is above. It is not merely a spreadsheet - it is
an extension that allows the programmer to specify how the value of
some slot (Lisp lingo for "member variable") can be computed. It
frees the programmer from having to recompute slot values since Cells
can transparently update them. It has to do with extending the object
system, not with merely setting tables in a hash and then retrieving
them.

It does apply the basic
idea of a spreadsheet to software - that is, instead of updating value
when some event occurs, you specify in advance how that value can be
computed and then you stop worrying about keeping it updated.

The result is the same. Of course, I don't track dependances in such a
tiny barebones example. But when you retrieve a cell you will get the
same value as with dependances. Adding dependances is left as an
exercise.

Incidentally, is this supposed to be an example of Python's supposed
"aesthetic pleasantness"?

Nope. This is an example that you don't need macros and
multi-statements. Ken writes: "While the absence of macros and
multi-statement lambda in Python will make coding more cumbersome". I'd
like to see Python code doing the same if the language had macros and
multi-statement lambda. Will it be more simple? More expressive?

FWIW (absolutely nothing, I imagine), here is my take on your
spreadsheet:

http://paste.lisp.org/display/19766

It is longer, for sure, but it does more and I haven't made any
attempt to stick to some minimum number of lines.

I find it a little hideous, even giving you
the benefit of the doubt and pretending there are newlines between
each function. There's nothing like a word wrapped in pairs of
underscores to totally ruin an aesthetic experience.

I don't think anyone who is not a master of a language can judge
readability. You're just distracted by insignificant details, they
don't matter if you code in that language for many years. I'm not going
to tell you how Lisp Cell code looks to me ;)

P.S. Is this really a spreadsheet? It looks like it's a flat
hashtable...

Does it matter if it's flat or 2D?

Not really, because this is not Cells.

--
This is a song that took me ten years to live and two years to write.
- Bob Dylan