> Start to develop macros where you do not know how arguments are evaluated or when, half of which you do not know and good luck figuring out how to use and combine things with functions/macros in other places.

I would guess a team would be so clever to develop maintainable macros.

In many places it's actually the very idea not to know how the thing is evaluated. One writes more descriptive software and does not specify execution details.

You can write unmaintainable software in many ways. Macros are a tool for code generation. How to write and use them can be learned, just like people learn to maintain large class libraries in Java.

Really, there are many of examples of Lisp code bases which make heavy use of macros and where the code was written by tens to hundreds of people.

For example much of the user facing Lisp functionality itself is macros.

Something like CLOS has much of its functionality exposed to the programmer as macros, which sit on top of functions and OOP. It's a domain specific extension to Common Lisp for OOP.

GUI libraries use macros, tools for 3d modeling use macros, ...

Whenever groups of people use code, macros are a tool to provide common language extensions. Like any tool, it needs to be learned how to use it.

> You can write unmaintainable software in many ways. Macros are a tool for code generation. How to write and use them can be learned, just like people learn to maintain large class libraries in Java.

Macros are inherently more complex: they can transform ASTs, they can evaluate in several ways, they can inject variables in the same scope, they caan use the surrounding scope in surprising ways.

Functions have very well-defined input and output marks on it, which gives more structure.

I think you will agree that while macros are more powerful, it is way easier to write code more difficult to maintain and look at than with functions.

> Really, there are many of examples of Lisp code bases which make heavy use of macros and where the code was written by tens to hundreds of people.

I wonder when why people move to "inferior" languages like Python, Java or Go. Because they give you MORE structure, not construction material. The construction material can be used in so many clever ways that it is not even funny.

If there is a reason why people move to less powerful languages for team development that is because in some ways you find it easier.

In theory, Lisp is super powerful. It is true, I do not deny that. But it looks to me like macros are most of the time more trouble than not. With higher order functions and without macro abuse you can have more structure and code that maybe is not as terse or "good" at some point, but clearly readable and without any suprise in scope, hygiene or many things that can go deeply buried.

I would not remove macros from Lisp, though. But their use should be limited. I heard some reports (sorry I do not remember the source) that macros usually end up in DSLs that only the makers understand or that are at least difficult to understand for others. For sure there are ways to mitigate it with better docs and others, but they are still macros.

> Something like CLOS has much of its functionality exposed to the programmer as macros, which sit on top of functions and OOP. It's a domain specific extension to Common Lisp for OOP.

Yes: well-known, a few and well-documented. Now give that power to literally every programmer and let them use it freely. Then the cognitive overhead is unavoidable, like with anything else. But with macros things can get way more obtuse than with functions and a few pre-made mechanisms in a language that everyone understands.

Have you worked on a professional software engineering team where every member was able to do things "freely"? That's a project management failure, not a language failure.

Usually there are rules. But it is way easier to gollow Java or Go than Lisp full of macros or random memory-management C++ bc those are possible. In Java it is just more restricted , hence more streamlined.