Re: Macros and little languages

[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?
> 
> You can do this, if you really need to, but you do it at runtime, not
> compile time. As I said before, it simplifies the programmer's mental
> model if they have to think only about runtime OR compile time, but not
> both.
> 

When you say you do it at runtime, do you mean you in effect
call eval?  Because you can do that in Lisp too; it's just
considered a hack.

> Peter Norvig says: "Python supports all of Lisp's essential features
> except macros, and you don't miss macros all that much because it does
> have eval, and operator overloading, so you can create custom languages
> that way." -- i.e. at runtime, not compile time.
> 
> On the one hand, if you must create the custom language at runtime you
> probably don't have as much control over its syntax. But then Lisp
> hardly gives you much control over syntax at all, does it?

Lisp gives you a great deal of control over syntax.
Y! Store's Rtml had infix math and indentation-based
structure.  It was all written in Common Lisp.  It
might not seem it gives you much control, because Lisp
hackers rarely take advantage of the possibility.  It
adds no power, though it does as you've said before make
the language more accessible to novices.  That was why we
did it in Rtml-- because Rtml was designed to be used
by online merchants, not programmers.  (If you can
choose whether to have syntax or not, you don't have
to force everyone to use the tool designed for non-
programmers.)

> 
> Also, as I said earlier, one must get used to variability at runtime
> because a programming language where you can't choose your function and
> variable names is essentially useful. But it is demonstrably the case
> that you can avoid variability at compile time, so maybe Occam's razor
> suggests that a programming language *should*.

I'm not sure I follow.  Do you mean to say useful, or is that a
typo?  If you do, I would argue that any sentence of the form
"a programming language where you can't choose ___ is useful"
is prima facie suspect.

> 
> >...
> > I think we agree that readability is an important goal.
> 
> As long as it doesn't interfere with succinctness, right? ;)
> 
> >...
> > 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.
> 
> *If* but I don't personally believe that this will happen. Common Lisp
> versus Java? Sure. Java programmers spend days on boilerplate code
> because reflection is so painful. Common Lisp versus Python or Ruby or
> Perl? I don't think you'll find a way to use macros to make that big of
> a difference.
> 
> > 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?
> 
> That presumes that infix notation is merely a whimsical preference that
> could change soon whereas I think that it probably evolved over millenia
> as the best solution to keeping operators close to their operands.
> 
Horses as a form of transportation also evolved over millenia,
(though indeed I can't think of any infix notation that's
actually 1000 years old).  In technology, you've got to
watch out for choosing custom over something that actually
works better.  That's why HP scientific calculators use
postfix.  Though indeed their *business* calculators use
infix.  If that's Python's niche, I wouldn't disagree with
you...