Today i ran into one of Guido van Rossum's blog article titled
“Language Design Is Not Just Solving Puzzles” at
http://www.artima.com/weblogs/viewpost.jsp?thread=147358
The article reads very kooky. The bottom line is that Guido simply
does not like the solution proposed for fixing the lambda construct
in Python, and for whatever reasons thinks that no solution would
satisfy him about this. But instead, he went thru sophistry on the
ignorance and psychology of coder mass in the industry, with mentions
of the mysterious Zen, the cool Google, the Right Brain, Rube
Goldberg contraption irrelevancies.
From his article, i noticed that there's largish thread of
discussions on lambda.
The following is a essay i wrote after reading another one of Guido
blog, in which shows prejudice and ignorance about functional
programing. I hope it can reduce the ignorance about lambda and
functional programing.
--
Lambda in Python 3000
Xah Lee, 20050930
On Guido van Rossum's website:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196 (local copy)
dated 20050310, he muses with the idea that he would like to remove
lambda, reduce(), filter() and map() constructs in a future version
Python 3000.
Guido wrote:
«filter(P, S) is almost always written clearer as [x for x in S
if P(x)], and this has the huge advantage that the most common usages
involve predicates that are comparisons, e.g. x==42, and defining a
lambda for that just requires much more effort for the reader (plus
the lambda is slower than the list comprehension)»
The form “[x for x in S if P(x)]” is certainly not more clear
than “filter(P, S)”. The latter is clearly a function, what is the
former? A function every programer in any language can understand and
appreciate its form and function. Why would anyone to expect everyone
to appreciate a Python syntactical idiosyncrasy “[x for ...]”?
Also, the argument that the form “filter(F,S)” being cumbersome
because the first argument is a function and that mostly likely it
would be a function that returns true/false thus most people will
probably use the inline “lambda” construct and that is quite
cumbersome than if the whole thing is written with the syntactical
idiosyncrasy “[x for ...]”, is rather inane, as you can now see.
The filter(decision_function,list) form is clean, concise, and helps
thinking. Why it helps thinking? Because it condenses the whole
operation into its mathematical essence with the most clarity. That
is, it filters, of a list, and by a yes/no decision function. Nothing
is more, and nothing can be less. It is unfortunate that we have the
jargon Lambda and Predicate developed by the tech geekers of the
functional programing community. The lambda could be renamed Pure
Function and the Predicate could be called True/False function, but
the world of things being the way they are already, it is unwise to
rewrite every existing Perl program just because somebody invented
another language.
If the predicate P in filter(P,S) is cumbersome, so would exactly the
same thing appear in the syntactical idiosyncrasy: “[x for x in S if
P(x)]”.
Guido added this sting as a afterthought:
«(plus the lambda is slower than the list comprehension)»
Which is faster is really the whim and capacity of Python compiler
implementators. And, weren't we using clarity as the judgement a
moment ago? The concept of a function every programer understands,
but what the heck is a List Comprehension? Why don't you scrap list
comprehension in Python 3000 and create a table() function that's
simpler in syntax and more powerful in semantics? ( See http://
xahlee.org/perl-python/list_comprehension.html )
«Why drop lambda? Most Python users are unfamiliar with Lisp or
Scheme, so the name is confusing; also, there is a widespread
misunderstanding that lambda can do things that a nested function
can't -- I still recall Laura Creighton's Aha!-erlebnis after I
showed her there was no difference! Even with a better name, I think
having the two choices side-by-side just requires programmers to
think about making a choice that's irrelevant for their program; not
having the choice streamlines the thought process. Also, once map(),
filter() and reduce() are gone, there aren't a whole lot of places
where you really need to write very short local functions; Tkinter
callbacks come to mind, but I find that more often than not the
callbacks should be methods of some state-carrying object anyway (the
exception being toy programs).»
In the outset Guido here assumes a moronitude about the set of Python
users and what they are familiar of. Python users 10 years ago are
not the same Python users today, and will certainly not be the same
10 years later if you chop off lambda. Things change, math literacy
advances, and what users you have changes with what you are. A
function is the gist
