Yes, and there is a good reason for that: Most modern Software spanning 100k's lines of code or more are developed in teams. Often these teams need to cooporate with other teams. Often the code has to be picked up 2-3 years later by a different team.
The programming languages used to write these LOC's need to accomodate this, and that means they need to provide A COMMON LANGUAGE all the people in all these teams understand, and will still understand in 2, 3, 5 or 10 years. I recently went through the code of several GNU coreutils, some of which are more than 2 decades old. Doesn't matter, I know C, so I can read and understand these programs codebases. Even if something is written in a language I am not that familiar with, if it is at least somewhat like the languages I know, I can still grasp what is going on.
In LISP, we have the flexibility to create our own domain specific languages. That's great. That's powerful. That's AWESOME (no sarcasm here, it really is).
But that's also dangerous, because the guy who wrote the code I need to work on 3 years later, might have a completely different mindset what the language to tackle the problem with should look like.
So before I can read his code, I have to understand the language he created, the guy who works with me has to understand the language I create, and if we a/l crKDte o0ur ß?wn luanangua!a___ges eviri tim3 __WE__ ::h:a:v:e:: t.insert("o") solve a problem, we can easily see how that may lead to problems.
Long story short: Having a language that can be extended at will is great and powerful and awesome, but it also creates problems. If every carpenter invented his own tools, each of which have to be learned before they can be used, then it becomes really hard to work together on a big house.
every sizeable Java project has a multitude of languages (annotations, XML-based, JSON-based, ...) for configuration, data exchange, etc. Sometimes even 'improved' versions of Java (functional Java, Kotlin, Scala, ...) or use of code generators.
Macros don't necessarily make the program not more difficult to understand from a programming side: an average programmer can write more domain specific code, without the need to understand the technical details. It might make sometimes the maintenance harder, when the implementation of the macro needs to be understood.
Example: the CLOS (Common Lisp Object System) has for the programmer an interface, which is largely based on macros. These make the programming with CLOS easier, than without. The average developer does not care how they are implemented, but they use the macros do describe classes, generic functions and methods. Those could be written in an object-oriented notation, but with much more effort. It's easier to learn the macros, than the object-oriented interface.
Codebases need to allow adding new stuff, or changing old stuff, otherwise the project is frozen and the product cannot be developed further.
And code reviews rely on the fact that both developer and reviewer can read and understand the code. If the developer can use the code to invent a completely new language, it will be difficult to review its correctness. The job of the reviewer is to review the code, not learn a new language I just came up with.
And since we are not using Lisp we don't have a problem with it nor do we blame it for anything ;-)
Macro isn't your entire product. Loop macro is a thing since 1990's, yet it hasn't changed and everyone is fine with that. Macro can be extensible BTW, look at iterate macro in Common Lisp as an example.
You don't have to accept the code if you are worry about maintainability. But rejecting macro altogether is stupid.
>since we are not using Lisp
I know since you just invent imaginary problem and farm those internet points.
Nope; if Lisp were popular, all the fungible programmers would readily learn it and be productively employed, just like the are currently doing with languages that borrow heavily from Lisp.
Employers don't actually want fungible programmers, as in mediocre. They want programmers who are replaceable not because their work is mediocre, but because their work is well-designed and organized with a view toward maintainability, documented, and covered by test cases.
One can easily be a mediocre programmer (who therefore ought to be fungible, because their work isn't clever) but whose work is difficult to understand, take over, and get working by the next mediocre programmer.
Yes, and there is a good reason for that: Most modern Software spanning 100k's lines of code or more are developed in teams. Often these teams need to cooporate with other teams. Often the code has to be picked up 2-3 years later by a different team.
The programming languages used to write these LOC's need to accomodate this, and that means they need to provide A COMMON LANGUAGE all the people in all these teams understand, and will still understand in 2, 3, 5 or 10 years. I recently went through the code of several GNU coreutils, some of which are more than 2 decades old. Doesn't matter, I know C, so I can read and understand these programs codebases. Even if something is written in a language I am not that familiar with, if it is at least somewhat like the languages I know, I can still grasp what is going on.
In LISP, we have the flexibility to create our own domain specific languages. That's great. That's powerful. That's AWESOME (no sarcasm here, it really is).
But that's also dangerous, because the guy who wrote the code I need to work on 3 years later, might have a completely different mindset what the language to tackle the problem with should look like.
So before I can read his code, I have to understand the language he created, the guy who works with me has to understand the language I create, and if we a/l crKDte o0ur ß?wn luanangua!a___ges eviri tim3 __WE__ ::h:a:v:e:: t.insert("o") solve a problem, we can easily see how that may lead to problems.
Long story short: Having a language that can be extended at will is great and powerful and awesome, but it also creates problems. If every carpenter invented his own tools, each of which have to be learned before they can be used, then it becomes really hard to work together on a big house.