A critic of Guido's blog on Python's lambda
kentilton at gmail.com
Sun May 7 01:55:06 CEST 2006
Alex Martelli wrote:
> Ken Tilton <kentilton at gmail.com> wrote:
>>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.
> In my opinion (and that of several others), the best way for Python to
> grow in this regard would be to _lose_ lambda altogether, since named
> functions are preferable (and it's an acknowledged Python design
> principle that there should ideally be just one obvious way to perform a
> task); GvR used to hold the same opinion, but changed his mind recently,
> alas, so we'll keep the wart.
Yes, I am enjoying watching lambda teetering on the brink. So it has
been re-upped for another tour? Go, lambda! Go, lambda!
> But, quite apart from the whole issue of whether it's desirable to
> languages to change massively ("add new power and capability" meaning
> new enriched features in the language itself), your whole argument is
> bogus: it's obvious that _any_ fundamental design choice in an artefact
> will influence the feasibility and desirability of future design choices
> in future releases of that same, identical artefact.
True but circular, because my very point is that () was a great design
choice in that it made macros possible and they made CL almost
infinitely extensible, while indentation-sensitivity was a mistaken
design choice because it makes for very clean code (I agree
wholeheartedly) but placed a ceiling on its expressiveness.
> At a syntax-sugar
> level, for example, Lisp's choice to use parentheses as delimiter means
> it's undesirable, even unfeasible, to use the single character '(' as an
> ordinary identifier in a future release of the language.
(defun |(| (aside) (format nil "Parenthetically speaking...~a." aside))
(|(| "your Lisp /is/ rusty.")
=> "Parenthetically speaking...your Lisp /is/ rusty.."
:) No, seriously, is that all you can come up with?
> this to mean that Lisp "cannot scale" is just as ridiculous as
> considering that Python "cannot scale" by not having an elegant way to
> make lambdas heavier and richer -- totally laughable and idiotic.
Harsh. :) I demand satisfaction. See end of article.
> unneeded feature "cannot" be added (elegantly) in future releases of the
> language'' is just as trivial and acceptable for the unneded feature
> ``allow ( as an ordinary single-character identifier'' as for the
> unneded feature ``allow unnamed functions with all the flexibility of
> named ones''.
>>By contrast, in On Lisp we see Graham toss off Prolog in Chapter 22 and
> Oh, is that the same Graham who writes:
So we are going to skip the point I was making about Common Lisp being
so insanely extensible? By /application/ programmers? Hell, for all we
know CL does have a BDFL, we just do not need their cooperation.
> A friend of mine who knows nearly all the widely used languages uses
> Python for most of his projects. He says the main reason is that he
> likes the way source code looks.
No argument. The little Python I wrote while porting Cells to Python was
strikingly attractive. But it was a deal with the devil, unless Python
is content to be just a scripting language. (And it should be.)
OK, I propose a duel. We'll co-mentor this:
In the end Python will have a Silver Bullet, and only the syntax will
differ, because Python has a weak lambda, statements do not always
return values, it does not have macros, and I do not know if it has
Then we can just eyeball the code and see if the difference is
interesting. These abstract discussions do tend to loop.
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
More information about the Python-list