Hacker News Reader

Comment by QuadrupleA | Hacker News Reader

Lisp is pretty ugly :)

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

I wonder if its famed sense of enlightenment is partly just overcoming the mental hurdle of it's syntax.

Edit: typo fix, had x/z mixed up

View on HN

You don't have to do it like that. You could do:

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

Or:

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

Or:

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

Or:

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

Or:

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

Or:

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

I think the last one makes the relationships quite clear.

Writing legible equations is an art form, as is writing sexps.

Edit: If you think lisp is ugly, compare with regexps. For bonus points, explore writing regexps with lisp, e.g. with Emacs's `rx` macro. I think you won't find a more easily maintainable way to write them.

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.

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.

Some would argue that Lego and Technic are too complicated, and we should all play with Duplo.

Thankfully, Michelangelo and Leonardo were not in large teams.

Which do you aspire to be: a cog or an artist?

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.

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.

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).

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)))

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

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

Which is incorrect, they aren't equal.

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.

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

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)`.

I think lisp is beautiful in a mathematical sense, but not in the ‘producing practical code’ sense.

tbh, if you're writing a lot of equations like this in a program, the Lisp version should probably be something like

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

where you write and test an `eqn` macro that rewrites everything in the correct syntax.

using rm-hull/infix in clojure

        x * (y + z) = x * z + y * z reduces to
    ($= x * (y + z) = x * z + y * z)

Specifically its more complex only in that the entire expression is wrapped in ($= )

In order to give x y and z values to run it simply wrap it in a let and give them values.

    (let [x 1 y 2 z 1]
      ($= x * (y + z) = x * z + y * z))

alternatively wrap it in a function

    (defn testme [x y z]
      ($= x * (y + z) = x * z + y * z))

Reply on news.ycombinator.com