[EMAIL PROTECTED] (Alex Martelli) writes:
> Bill Atkins <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
