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

[Cameron MacKinnon]

Alex Martelli wrote:
> Ken Tilton <kentilton at gmail.com> wrote:
>    ...
> 
>>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.
> 
> 
> Having to give functions a name places no "ceiling on expressiveness",
> any more than, say, having to give _macros_ a name.

As was pointed out, if a Lisper wants anonymous macros, it's a cinch to 
create a scheme to allow this. Whether or not it's a good idea in 
general, if someone feels they need it, they can do it. An attitude like 
that beats "No you can't do that, but you shouldn't do it anyway."

>>(defun |(| (aside) (format nil "Parenthetically speaking...~a." aside))
>>=> |(|
>>(|(| "your Lisp /is/ rusty.")
>>=> "Parenthetically speaking...your Lisp /is/ rusty.."

> Interestingly, the SECOND lisper to prove himself unable to read the
> very text he's quoting.  Reread carefully, *USE THE ***SINGLE***
> CHARACTER* ... *AS AN ORDINARY IDENTIFIER*.  What makes you read a
> ``PART OF''  that I had never written?  You've shown how to use the
> characters as *PART* of an identifier [[and I believe it couldn't be the
> very start]], and you appear to believe that this somehow refutes my
> assertion?

Those vertical bars are just quoting characters, rather like the quoting 
characters you'd undoubtedly need in Python to create a variable name 
with a space in it.

> The point is, OF COURSE any design choice places limitations on future
> design choices; but some limitations are even DESIRABLE (a language
> where *every* single isolated character could mean anything whatsoever
> would not be "expressive", but rather totally unreadable) or at least
> utterly trivial (syntax-sugar level issues most typically are).

Yeah, a language like that would probably have some strange name like 
"TeX." But we'd never know, because nobody would ever use it.


> Yes, we are, because the debate about why it's better for Python (as a
> language used in real-world production systems, *SCALABLE* to extremely
> large-scale ones) to *NOT* be insanely extensible and mutable is a
> separate one -- Python's uniformity of style allows SCALABILITY of
> teams, and teams-of-teams, which is as crucial in the real world as
> obviously not understood by you (the law you misquoted was about adding
> personnel to a LATE project making it later -- nothing to do with how
> desirable it can be to add personnel to a large and growing collection
> of projects, scaling and growing in an agile, iterative way to meet
> equally growing needs and market opportunities).

You seem to be using the most primitive definition of scalable that 
there is, viz, if one coder can write one one page program in a day, two 
coders can write two (or more likely 1.8) one page programs in a day. 
Lispers tend to the view that *OF COURSE* most other decent languages 
scale linearly, but what we want is force multipliers and exponential 
scaling, not "throw money at it" scaling. Thus program writing programs, 
program analyzing programs, compiled domain specific languages and great 
quotes like

"I'd rather write programs to write programs than write programs."

"Programs that write programs are the happiest programs in the world."