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

[Bill Atkins]

aleaxit at yahoo.com (Alex Martelli) writes:

> Bill Atkins <NOatkinwSPAM at rpi.edu> wrote:
>    ...
>> >
>> > Read again what I wrote: I very specifically said "ordinary
>> > *single-character* identifier" (as opposed to "one of many characters
>> > inside a multi-character identifier").  Why do you think I said
>> > otherwise, when you just quoted what I had written?  (Even just a
>> > _leading_ ( at the start of an identifier may be problematic -- and just
>> > as trivial as having to give names to functions, of course, see below).
>> 
>> Well, the same technique can obviously be used for:
>> 
>>  (let ((|(| 3)))
>>    (+ |(| 4)))
>>  ;; => 7
>> 
>> The length of the identifier is irrelevant...
>
> But it cannot be a SINGLE CHARACTER, *just* the openparenthesis.
>
> Wow, it's incredible to me that you STILL can't read, parse and
> understand what I have so clearly expressed and repeated!

Read my other post.  It's incredible that you STILL haven't considered
the possibility that you're just wrong.

>
>> Common Lisp does not support unnamed macros (how would these be
>> useful?), but nothing stops me from adding these.  What use case do
>> you envision for anonymous macros?
>
> None, just like there is none for anonymous functions -- there is
> nothing useful I can do with anonymous functions that I cannot do with
> named ones.

Sure there are.

Does Python have any support for closures?  If so, ignore this point.
But if not, what about examples like this:

  (defun make-window (window observer)
    ;; initialization code here
    (add-handler window 'close
                 (lambda (event)
                    (notify observer event)))
    ;; more code)

Being able to keep pass around state with functions is useful.

There are also cases where a function is so trivial that the simplest
way to describe it is with its source code, where giving it a name and
putting it at the beginning of a function is just distracting and
time-consuming.  E.g.:

  (remove-if (lambda (name)
               (find #\- name :test #'char=))   
             list-of-names)

What's the sense of giving that function its own name?  It's much
clearer to simply write it in place.  Yes, it's _possible_ to use
named functions, but in this case its functionality is so simple that
it's clearer to simply type it in place.  Why is this expressiveness a
bad thing, aside from its power to wreck an indentation-significant
language?

>
>> > Anyway, I repeat: *any* design choice (in a language, or for that matter
>> > any other artefact) has consequences.  As Paul Graham quotes and
>> > supports his unnamed friend as saying, Python lets you easily write code
>> > that *looks* good, and, as Graham argues, that's an important issue --
>> > and, please note, a crucial consequence of using significant
>> > indentation.  Alien whitespace eating nanoviruses are no more of a worry
>> > than alien parentheses eating nanoviruses, after all.
>> 
>> It *is* an important issue, but it's also a subjective issue.  I find
>> Lisp to be far prettier than any syntax-based language, so it's far
>> from an objective truth that Python code often looks good - or even at
>> all.
>
> The undeniable truth, the objective fact, is that *to most programmers*
> (including ones deeply enamored of Lisp, such as Graham, Tilton, Norvig,
> ...) Python code looks good; the Lisp code that looks good to YOU (and,
> no doubt them), and palatable to me (I have spoken of "eerie beauty"),
> just doesn't to most prospective readers.  If you program on your own,
> or just with a few people who share your tastes, then only your taste
> matters; if you want to operate in the real world, maybe, as I've
> already pointed out, to build up a successful firm faster than had ever
> previously happened, this *DOESN'T SCALE*. Essentially the same issue
> I'm explaining on the parallel subthread with Tilton, except that he
> fully agrees with my aesthetic sense (quoting Tilton, "No argument. The
> little Python I wrote while porting Cells to Python was strikingly
> attractive") so this facet of the jewel needed no further belaboring
> there.

And I'm sure Kelly Clarkson sounds better *to most listeners* but that
doesn't mean she's a better musician than Hendrix.  The fact that most
people are used to ALGOL-like languages does not mean that ALGOL-like
languages are more aesthetically pleasing on their own merits.

>> 
>> Plus, I can easily write code that looks good without using a language
>> that enforces indentation rules.  Lisp's regular syntax lets Emacs do
>> it for me with a simple C-M-a C-M-q.  What could be easier?
>
> If you need to edit and reformat other people's code with Emacs to find
> it "looks good", you've made my point: code exists to be read, far more
> than it's written, and Python's design choice to keep punctuation scarce
> and unobtrusive obviates the need to edit and reformat code that way.

That's not what I'm saying at all.  My point is that I can write a
function, counting on Emacs to keep it indented for me, and then after
making a series of changes to it, a mere C-M-a C-M-q takes them into
account and bam, no-fuss indenting.

>
> Alex
>  

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