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! > 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. > > 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. > > 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. Alex -- http://mail.python.org/mailman/listinfo/python-list
