[edflsafoiewq]

Not really. It's true if you compare, like f(x) to (f x), but in general Lisp really does have more.

    // 3 brackets
    float diff(vec3 v1, vec3 v2) {
        float dx = v1.x - v2.x;
        float dy = v1.y - v2.y;
        float dz = v1.z - v2.z;
        return sqrt(dx*dx + dy*dy + dz*dz);
    }

    ;; 18 brackets
    (def (diff v1 v2)
        (let (dx (- (x v1) (x v2))
              dy (- (y v1) (y v2))
              dz (- (z v1) (z v2)))
            (sqrt (+ (* dx dx) (* dy dy) (* dz dz)))))

[memling]

> Not really. It's true if you compare, like f(x) to (f x), but in general Lisp really does have more.

In general I think this is true, but an important caveat that your post brings up is that sometimes it also has to do with how we translate one language to another.

Consider treating a 3-tuple as a list, and assume you have the primitive functions zip, square, sum, and sub (inverse of summing a list). Then the idea of the distance between two points reduces to:

    (defun dist (v1 v2)
      (sqrt (sum (map sq (map sub (zip v1 v2))))))

Of course there really are more parentheses here than in the C snippet you wrote, and it's arguably harder to understand, especially if you're unfamiliar with functional programming; it could be slower, too, and careless use of the zip function truncates at the shortest array. (I'm sure there are other objections I haven't anticipated.)

At the same time, if you want to generalize the C function to arbitrary vectors, you'll have to do a little more work with passing arrays, checking bounds, adding a loop. The Lisp function, by contrast, requires no such effort, and once the concept is understood requires little further explanation.

Even so, the point is that line-for-line translations may not always capture idiomatic usage of the language, which may in turn make it look or feel worse than it really is.

[schpaencoder]

What about operator precedence?