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

[Hans Hübner]

Julian,

thank you for adding your opinion to the discussion.  I agree with
what you write, and I certainly did not mean to come up with a
universal definition as to what macro styles would be acceptable.  My
intent was to come up with some more reasoning as to why anaphoric
macros have not been picked up widely, even though they are
compellingly cute and a strikingly good example of the power of Common
Lisp macros.  They are an example.

Industrial software development as I meant it refers to projects that
consist of many people and that have a relatively large fluctuation in
the developer base.  In such contexts, the number of unusual
constructs should be kept low, and it is not generally a good idea to
allow individual programmers to modify the language as such.  If a
project as a whole decides to pick up particular macros or language
extensions, it is helpful to choose extensions which add value beyond
cuteness.  Also, it is good to allow only language extensions that are
either idiomatic (i.e. it is easy to infer the meaning of private
constructs because a certain extension pattern is followed, like
WITH-* or DO-*), or that are documented well.  Being disciplined about
language extensions helps getting new people into the project, and
also benefits the overall quality of the source base.

SERIES is a particularily good example of an extension that is large
and documented:  It does something that can be valuable and that can't
easily be emulated with standard idioms.  It is also documented in a
way that makes it possible, for someone joining in to a project, to
really learn what it is capable of doing.  If I'd be the language
lawyer in a new project, SERIES might be a candidate for inclusion.
In an existing project, I'm not sure if I would want to be the one
that started using it.  Embedded Prolog, CLOS and AspectL are other
examples of such a heavyweight language extensions that one might want
to choose, consciously.  One may also want to disallow the use of
certain language extensions even though they're in the ANSI standard
(heh).

This list is meant to be a forum for professional programmers and I am
well aware of the fact that many of you don't require any advice on
this level.  I'm just trying to banter, mind you.

-Hans

On Thu, Sep 9, 2010 at 19:23, Julian Squires <julian at cipht.net> wrote:
> 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
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>