On Wed, Sep 8, 2010 at 10:34 AM, Hans Hübner hans.huebner@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.