I agree that Lispers sometimes overestimate the usefulness of macros. A lot of supposedly powerful macros can be (and are, in other languages) replaced by plain functions. I ranted about this on the Arc forum recently, but no one seemed to share my concern.
Also, many common macros (e.g. HTML generators) confer a performance advantage by doing computation at compile time, but do not confer any expressive advantage.
But, this is not to say that macros can't increase expressivity. You agree that the creation of new languages (metalinguistic abstraction) is an important tool, right? Think of a macro as a compiler for an arbitrary language or sub-language into Lisp. Lisp's homoiconic syntax just makes such compilers extremely easy to write. The trade-off is that the homoiconic syntax is harder to read (IMO).
If you want an example of a useful macro, here's one I used in a recent program. The interface was a simple command line where commands and their arguments generally corresponded to functions and their arguments. Much of the code looked like this (highly simplified):
(define (add a b) (print (+ a b)))
(new-command 'add add "Adds two integers" (a integer) (b integer))
The program would then display "add" among the list of available commands, along with its description and syntax. When the user typed e.g. "add 1 2" it would validate the input and call add on it.
Obviously, there's a lot of duplication above, because the properties of a function (its name, its parameters, etc.) aren't available at runtime; theoretically some reflection system could provide this, but it would be kind of a mess. So I wrote a macro that unified define and new-command, roughly like this:
(define-command add (a integer b integer)
"Adds two integers"
(print (+ a b)))
In short, I designed a domain-specific language to attack my problem, and Lisp made it easier than any other language would have.
Also, I'd suggest dropping the rhetoric about Lisp "culture," which you clearly have only a vague understanding of. Have some trust in your fellow humans.
Also, many common macros (e.g. HTML generators) confer a performance advantage by doing computation at compile time, but do not confer any expressive advantage.
But, this is not to say that macros can't increase expressivity. You agree that the creation of new languages (metalinguistic abstraction) is an important tool, right? Think of a macro as a compiler for an arbitrary language or sub-language into Lisp. Lisp's homoiconic syntax just makes such compilers extremely easy to write. The trade-off is that the homoiconic syntax is harder to read (IMO).
If you want an example of a useful macro, here's one I used in a recent program. The interface was a simple command line where commands and their arguments generally corresponded to functions and their arguments. Much of the code looked like this (highly simplified):
The program would then display "add" among the list of available commands, along with its description and syntax. When the user typed e.g. "add 1 2" it would validate the input and call add on it.Obviously, there's a lot of duplication above, because the properties of a function (its name, its parameters, etc.) aren't available at runtime; theoretically some reflection system could provide this, but it would be kind of a mess. So I wrote a macro that unified define and new-command, roughly like this:
In short, I designed a domain-specific language to attack my problem, and Lisp made it easier than any other language would have.Also, I'd suggest dropping the rhetoric about Lisp "culture," which you clearly have only a vague understanding of. Have some trust in your fellow humans.