Macros and little languages

[Paul Prescod <address@hidden>]

Paul Graham wrote:
> 
> 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.

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?

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 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.

 Paul Prescod