X
Xah Lee
A Moronicity of Guido van Rossum
Xah Lee, 200509
On Guido van Rossum's website:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
dated 20050826, 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 the **** is
the former? A function every programer in any language can understand
and appreciate its form and function. What the **** would anyone to
expect everyone to appreciate a Python syntactical idiosyncrasy “[x
for ...]�
also, the argument that the from “filter(F,S)†being cumbersome
because the first argument is a function and that mostly likely it
would be a function that returns true and false thus most people will
probably use the form “lambda†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 morons in 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 being the way they are already, it is unwise to rewrite
every existing Perl program just because somebody invented another
language.
If the predicate in lambda in filter() 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
implementators. And, just before we were using criterion of simplicity.
The concept of a function every programer understands, what the **** 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
)
Guido wrote:
«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 pure
function (lambda) is the gist of a mathematical idea embodied in
computer languages, not something from LISP or Scheme as tech geeking
morons wont to think.
Guido wrote:
«... there is a widespread misunderstanding that lambda can do things
that a nested function can't...».
One is so insulted by a bigshot in the industry of 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 the **** 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.
Guido wrote:
«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, you begin to write things like Java, in three thousand words
just to state you are a moron.
The removing of elements in a language is in general not a good idea.
Removing powerful features so that morons 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 exceedingly moronic. It forces
unnecessary shakeup and can cause death.
Guido wrote:
«So now reduce(). This is actually the one I've always hated
most,...»
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 about bags 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.
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 don't really 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 to have
lambda attitude problem). The function map() could also be considered
for expansion. (see “What is Expresiveness 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. filter() should stay as it is as it is superb and
proper.
---------
This post is archived at:
http://xahlee.org/perl-python/python_3000.html
Xah
(e-mail address removed)
∑ http://xahlee.org/
Xah Lee, 200509
On Guido van Rossum's website:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
dated 20050826, 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 the **** is
the former? A function every programer in any language can understand
and appreciate its form and function. What the **** would anyone to
expect everyone to appreciate a Python syntactical idiosyncrasy “[x
for ...]�
also, the argument that the from “filter(F,S)†being cumbersome
because the first argument is a function and that mostly likely it
would be a function that returns true and false thus most people will
probably use the form “lambda†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 morons in 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 being the way they are already, it is unwise to rewrite
every existing Perl program just because somebody invented another
language.
If the predicate in lambda in filter() 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
implementators. And, just before we were using criterion of simplicity.
The concept of a function every programer understands, what the **** 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
)
Guido wrote:
«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 pure
function (lambda) is the gist of a mathematical idea embodied in
computer languages, not something from LISP or Scheme as tech geeking
morons wont to think.
Guido wrote:
«... there is a widespread misunderstanding that lambda can do things
that a nested function can't...».
One is so insulted by a bigshot in the industry of 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 the **** 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.
Guido wrote:
«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, you begin to write things like Java, in three thousand words
just to state you are a moron.
The removing of elements in a language is in general not a good idea.
Removing powerful features so that morons 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 exceedingly moronic. It forces
unnecessary shakeup and can cause death.
Guido wrote:
«So now reduce(). This is actually the one I've always hated
most,...»
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 about bags 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.
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 don't really 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 to have
lambda attitude problem). The function map() could also be considered
for expansion. (see “What is Expresiveness 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. filter() should stay as it is as it is superb and
proper.
---------
This post is archived at:
http://xahlee.org/perl-python/python_3000.html
Xah
(e-mail address removed)
∑ http://xahlee.org/
