For comparison infix notation with the same precedence for all operators:

    (x * (y + z)) eql ((x * z) + (y * z))

Or:

    (y + z * x) eql (x * z + (y * z))

With different precedence:

    x * (y + z) eql x * z + y * z

But now you have to remember precedences and mentally regroup the expression.

I assume you just copy-pasted from parent, but both of you have written `(* x z)` `(* y z)` rather than `(* x y)` `(* x z)`.

Sorry, is it

xz + yz = x(y + z)

when using operators?

That seems wrong.

I don't know any Lisp, but I would decode

    (= (* x (+ y z))
       (+ (* x z) (* y z)))

As

  x*(y + z) = x*z + y*z

e.g. (+ y z) means you add y and z with highest priority.

That is probably not a statement of equality, but a boolean test for it.

Well, technically it solves to x = z when y <> 0 and any x, z when y = 0 though I'm not sure if that's the original intention.

Some would argue that the fact that you have all of those alternative forms is part of the problem. Lisp is one of the (if not the) most individualistic programming languages around. Lisp makes it easy for a programmer to create their very own impenetrable, arcane, domain specific languages. This causes large organizations to avoid it like the plague.

Large teams don't want artists, they want replaceable parts.

The tragedy is that the "large organization" then goes on and writes multiple bad DSL to solve problem X which includes several code transpilers and a varying amount of custom syntax. In the end, they do the same thing as the Lisp folks -> they write a DSL, but because language XYZ they chose is less capable than Lisp, the solution is hacky and difficult to understand (and can't be – in comparison to Lisp – easily extended).

This is true for a lot of "frameworks" and especially true for modern fontend web frameworks (which have a compile/build step).

You have alternative line breaking in infix also. All of it sucks compared to keeping it on one line, though:

  x * (y + z) = x * z + y * z


  x * (y + z) =
  x * z + y * z


  x * (y + z)
  = x * z + y * z


   x *
   (y + 
    z)
  =
   x *
   z
      +
   y *
   z

etc.

Are you talking about macro or formatting?

If it's about formatting, given that this is what this thread is about, you can use code formatter for lisp languages exactly like for any other language, in fact they are even easier to write for lisp because of the consistency of S expressions.

If you are talking about macro, then you're in the same boat as other languages that have macros, C, Rust, ect... And remember that the first rule of macros is to not use macros, except for when you absolutely have to, and in those cases it is the most elegant solution. If you have devs inventing DSLs for everything, then lisp isn't your problem.

I think most people would prefer to be an artist, but art rarely pays the bills, hence the cliche "starving artist." My post was not meant to rip on artists, though that's how it comes off now that I read it again. The truth is that society wants more cogs but needs more artists.

If prefer it if the product of my engineering effort were maintainable and clear. I succeed if someone with no context can understand the system I built without help.