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@cipht.net wrote:
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.
-- Julian Squires
pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro