A critic of Guido's blog on Python's lambda

[Ken Tilton]

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.

As for:

>  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?

>  Considering
> 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.

>  ``An
> 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:

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

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 
special variables.

Then we can just eyeball the code and see if the difference is 
interesting. These abstract discussions do tend to loop.

kenny

-- 
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
    Attorney for Mary Winkler, confessed killer of her
    minister husband, when asked if the couple had
    marital problems.