Re: Accumulator

[Paul Graham <address@hidden>]

If a design goal of Python is to make all source code look 
familiar, you're then saying you don't want the language 
to be used for bottom-up programming, where by definition 
you make a custom language for the app.  Are you sure you 
want that? 

It *is* a problem in Lisp when people use lots of hairy
macros that e.g. change the Lisp evaluation rule.  (Nearly 
any macro will, in fact.)  The answer is not to forbid 
macros, but only to use them when they are a net win in 
readability.

I think we agree that readability is an important goal.
My mantra is SICP's 

  "Programs must be written for people to read, and only
   incidentally for machines to execute."

But I think the test of readability is the amount of 
work you have to do to read the whole program, not the
amount of work you have to do per line.  If some fairly
complex macro will make your program 1000 lines shorter,
it is probably a net win for readability.

BTW, I don't think infix languages are intrinsically more
readable than prefix.  Except for math, I find prefix
more readable, and would prefer it regardless of its
handiness in macros.  I think we need to distinguish 
between intrinsic readability and familiarity.  I agree
that infix might be more familiar to people, but if you
design your language to be similar to whatever crap
people learn in high school, what happens if they start 
teaching them different crap?  

--pg

>    Date: Fri, 24 May 2002 12:45:11 -0700
>    From: Paul Prescod <paul@prescod.net>
>    X-Accept-Language: en
>    To: Guy Steele - Sun Microsystems Labs <Guy.Steele@sun.com>, 
> ll1-discuss@ai.mit.edu
>    Subject: Re: Accumulator
> 
>    
>    Guy Steele - Sun Microsystems Labs wrote:
>    > 
>    >...
>    > 
>    > I am puzzled.  Could you please elaborate on what you
>    > mean by "decreasing the regularity"?
>    
>    Sure. But I won't get drawn into a debate on it because I've been
>    through the debate often enough on Python mailing lists.
>    
>    Simply when you pick up someone else's code, how much does it look like
>    the Python you are used to? This is a subtle issue because obviously we
>    can't force everyone to use the same function names. But we can add a
>    large library so that people feel less need to reinvent things. And we
>    can make the language syntactically rich enough that they feel less
>    inclined to reinvent primitives (e.g. exceptions, generators, maybe
>    someday coroutines). ...
> 
> Ah, I see; thank you.  I wasn't sure whether you were
> usng "regularity" to mean "familiarity/standardization"
> (which is what you seem to mean after all) or "internal
> design consistency" or "orthogonality of design/
> separation of concerns".
> 
> --Guy Steele
>