alt Hacker NewsIt's hard to reconcile that with the comment they were responding to that claimed that lisp requires you to be the designer of the language a bit. I don't know enough to know who is right, but if the majority of the code is "just" regular functions and classes then I'd argue that it doesn't require custom design as a much as allow it, and the solution you're proposing is to mostly disallow it by convention. Like the comment you're responding to suggests, it's hard for me to imagine why having that much flexibility is worthwhile if it's going to be mostly unused when you can still write that occasional macro you call out in Rust or Elixir.
Replies
The first rule of writing Lisp macros is to not do it if you can get away with using functions. I'd still argue that it requires custom design, but in the same way OOP does. There are established patterns that you know and sometimes iterate on.
It’s going to be used. But at a project and team level rather than at an individual level. You go from lisp, then end up with a DSL that fits the project.
Lisp isn't solely defined by DEFMACRO. There are other reasons to use it too, in ways that can complement or compete with DEFMACRO. I also don't really know or understand what the term "flexible" is supposed to mean precisely. What makes a Rust macro less flexible than a Lisp macro in the context of this discussion? In particular, what do Rust macros tamp down on in terms of power that make them more justified for occasional use compared to a Lisp macro?
Lisp has a handful of language features that allow the definition of new syntactic abstractions: form level (DEFMACRO) and character level (SET-MACRO-CHARACTER). Just like it has operators to define new data structures (DEFSTRUCT and DEFCLASS). Just like it had operators to define new functions (DEFUN, DEFGENERIC, DEFMETHOD). Each of these defining forms materially change the way a programmer writes code. You don't need to add new syntax to change the language, and each kind of language change comes with its own tools and practices for working with them, debugging them, documenting them, and so on. All of this is to say: I don't see a good reason to have all of these remarks about syntactic abstraction when they very well could be made about data abstraction or control abstraction.
A useful language feature isn't something that needs to be maximized in idiomatic code. Syntactic abstraction is useful when it's useful, and when it is useful, it's usually extraordinarily useful—typically because a new syntactic abstraction allows a programmer to specify something much more directly or correctly than otherwise. (Other languages frequently resort to external processors or code generators to the same effect. Anybody who has used them knows how frustrating and difficult to debug they can be. But nonetheless, it's not that people do or don't want syntactic abstractions—they clearly do—it's more a matter of how accessible we want to make it to the programmer.)
I did not suggest disallowing it anymore than I suggested we should disallow the definition of new classes in Java. Being judicious and deciding when it's worth it is key, and there are few general statements we can make about this without additional context.