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

[Bill Atkins]

aleaxit at yahoo.com (Alex Martelli) writes:

> 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.
>
> 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.  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.  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.  ``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''.

Not so infeasible:

  (let ((|bizarrely(named()symbol| 3))
     (+ |bizarrely(named()symbol| 4))

   ;; => 7

And in any case, enforced indentation is a policy with vastly more
serious consequences than the naming of identifiers.

>> By contrast, in On Lisp we see Graham toss off Prolog in Chapter 22 and
>
> Oh, is that the same Graham who writes:
>
> """
> 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. That may seem a frivolous reason to
> choose one language over another. But it is not so frivolous as it
> sounds: when you program, you spend more time reading code than writing
> it. You push blobs of source code around the way a sculptor does blobs
> of clay. So a language that makes source code ugly is maddening to an
> exacting programmer, as clay full of lumps would be to a sculptor.
> """
> ...?  [[ I suspect that friend is in fact a common friend of mine and
> Graham's, the guy you also mention later in your post, and who
> introduced Graham and me when G recently came talk at Google (we had
> "brushed" before, speaking in the same sessions at conferences and the
> like, but had never "met", as in, got introduced and _talked_...;-). ]]
> 
> But, no matter, let's get back to Graham's point: significant
> indentation is a large part of what gives Python its own special beauty,
> uncluttered by unneeded punctuation.  And while you, I, Graham, and that
> common friend of ours, might likely agree that Lisp, while entirely
> different, has its own eerie beauty, most people's aesthetics are poles
> apart from that (why else would major pure-FP languages such as *ML and
> Haskell entirely reject Lisp's surface syntax, willingly dropping the
> ease of macros, to introduce infix operator syntax etc...? obviously,
> their designers' aesthetics weigh parenthesized prefixsyntax negatively,
> despite said designers' undeniable depth, skill and excellence).
>
>
> Alex

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan