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 of a mathematical idea embodied in computer languages, not something from LISP or Scheme as tech geekers wont to think. «... there is a widespread misunderstanding that lambda can do things that a nested function can't...» One is so insulted by a industrial big shot in quoting something so disparate then shot it down as if showing his perspicacity. A lambda is a syntax for function or a name for the concept of function. What does it mean that a lambda isn't as powerful as nested function?? The lambda in Python is really ill. It is designed with a built-in limitation in the first place, and regarded as some foreign substance in the Imperative Crowd such as the Pythoners. If there's any problem with lambda, it is with lambda in Python and Pythoner's attitude. «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;» Of course, one begins to write things like Java: in three thousand words just to show you are a moron. The removing of elements in a language is in general not a good idea. Removing powerful features so that coding monkeys can use it is moronic. (e.g. Java) Removing “redundant” constructs is not always smart (e.g. Scheme), because it pinches on practicality. Removing existing language features by a visionary upgrade is a waste. It forces unnecessary shakeup and can cause death. «So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.» The existence of reduce() in Python is probably caused by tech geeking clowns of the computing industry. Basically, nobody really have a clear understanding of mathematics or computing semantics, but every elite tech geeker knew one bag of constructs of various languages. So, you add this, i want that, and the language becomes a incoherent soup of constructs, with the backlash of wanting to chop off things again, with that good things. reduce() in fact embodies a form of iteration/recursion on lists, very suitable in a functional language environment. If Python's lambda and other functional facilities are more powerful or complete, reduce() would be a good addition. For instance, in functional programing, it is a paradigm to nest or sequence functions. (most readers will be familiar in the form of unix shell's “pipe”). When you sequence functions, you can't stop in the middle and do a loop construct. So, reduce() and other functional forms of iteration are convenient and necessary. Suggestions: lambda, reduce(), filter() and map() all should stay. I'm not sure exactly what's the ins and outs of Python 3000. If one wants to shake things up based on a vision: don't. There are already gazillion languages and visions; the world really don't need another bigshot's say for their personal advancement. As for improvement, lambda in Python should be expanded to remove its built-in limitation (and Imperative Programing Crowd such as Pythoners should cease and desist with their lambda attitude problem). The function map() could also be considered for expansion. (see “What is Expressiveness in a Computer Language” at http://xahlee.org/perl-python/ what_is_expresiveness.html ) Function reduce() should stay because it's already there, even if it is not very useful and odd in Python. filter() should stay as it is as it is superb and proper. ... the rest of the article explaining the functions of the functions in question is at: http://xahlee.org/perl-python/python_3000.html Xah [EMAIL PROTECTED] ∑ http://xahlee.org/ ☄ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
