[pro] The Best Examples of "Code is Data"

[Julian Squires]

On Wed, Sep 8, 2010 at 10:34 AM, Hans Hübner <hans.huebner at gmail.com> wrote:
> The power of macros gives Lisp programmers the freedom to create the
> language that they need, but every single modification of the language
> makes it derive from what another programmer would expect.  Thus, in a
> setting where the written code serves not only as instructions to a
> computer, but also as prose communicating intent to another
> programmer, it is vital to establish borders to the amount of language
> modification permitted.

I want to say that I largely agree with what you're saying, but
disagree with some specifics as a matter of opinion.  I'm not sure
further discussion of it is warranted here, but I finally felt
compelled to mention two things which help reveal where our opinions
split:

Forth (which I love) relates to other terse means of expression
(anaphoric macros, DSLs, J) in that they reward factoring large
problems into tiny pieces (in some cases, perversely, by punishing
other approaches).  This reduction and crystallization process is one
way of dealing with so many of the problems associated with
"industrial software development".  (Also, if the thought "to what
does /it/ refer?" even momentarily crosses my mind, it's time to
factor that bit into its own function.)

The other aspect is that software development in any language requires
a certain degree of good faith on the part of both the author and the
reader.  The reader has an obligation to interpret the author
carefully -- I have never seen a large software project where it was
unnecessary to carefully examine headers and macros, the build system,
utilities, et cetera, to really understand what was happening.  So,
while I agree that borders on language modification must be drawn, I
suggest that those borders be drawn at a project level rather than a
language community level.

I like to use SERIES as well as various pattern matching tools --
these also seem like they might fall outside your list of accepted
macro styles, which would be a shame, since they've been around for
ages, and to me, can increase the legibility of the code by allowing a
more precise (and secondarily, succinct) expression of intent.  When I
act as a reader, I study the author's choice of notation in good faith
that they have chosen it to ultimately improve their communication
with me.

-- 
Julian Squires