[blunte]

Clojure has the same number of parens as Javascript, C/C++, Java, and similar languages have parens+squiggle-brackets.

(print "foo") vs print("foo"). same same.

There's so much more to it than this. I can say without reservation that people who do not take a couple/few weeks to learn a Lisp just do not know what they are missing, and their arguments against it are viewed as children who lack enough experience to know what they are rejecting.

[wostusername]

>(print "foo") vs print("foo"). same same.

If you look at things other than function calls, it starts to look different:

    let x = 5,
        y = 10
    foo(x,y)

vs

    (let [x 5 
          y 10]
      (foo x y))

I actually like Lisps and think the S expression syntax is one of their best features, but I'm not going to pretend there are the same number of brackets in Lisps as there are in C family languages.

[ken]

I once took some small but substantial pieces of code I'd written in Java, ported it to Lisp, and counted the grouping characters in each. Java had fewer parens, but many more grouping characters {}[]() overall. I think it was in the neighborhood of 50% to 100% more.

It's easy to prove anything with a sufficiently small micro-benchmark. But "one line of Java" is not equivalent to "one line of Lisp", and even if it were, nobody writes Lisp code in a style that looks like a one-to-one mapping of some Java code.

This is like complaining that Japanese is inefficient because it has thousands of characters, or that English is inefficient because it takes dozens of characters to say what only takes a couple in Japanese. The concepts aren't exactly the same, and you can't just pick a trivial example and conclude that "this has fewer than that".

[blunte]

I can't reply to your lower example because it's too deep, but I would point out that clojure does not have the other symbols - equal and comma.

In your lower example, Clojure has only one more non alphanumeric character than the other example.

Furthermore, in Lisp, you always know that you have (function-name param param etc). Reading it becomes not just easier - it removes an entire layer of abstraction (syntax rules). Also, with smart editors, you gain the ability to move these around rapidly in ways that you simply cannot do with other languages.

Funny thing is, the biggest annoyance I have when not using Clojure is having to type commas between items in data structure. [1 2 3 4 5] just looks so much cleaner than [1, 2, 3, 4, 5]. I forget who wrote it, but they complained of seeing all the mouse turds "," in normal programming languages.

[kazinator]

Even math notation dispenses with the silly commas in matrix notation, which so nice it gets used for vectors also.

[kazinator]

That parenthesis around let is important; it precisely delimits the scope for that x and y:

    (let [x 5 
          y 10]
      (foo x y))
    (foo x y) ;; now different x and y!

In C, I'm often doing:

  {
    foo *ptr = ...; // scope this just to this block.

  }

I don't want ptr to be visible other than in that block, especially if it has gone invalid/null.

The braces will be there if you program sanely and care about scope.

[kgwxd]

The first example is missing the scope brackets likely enclosing the expressions, and there should probably be a few semi-colons.

[wostusername]

>The first example is missing the scope brackets likely enclosing the expressions

Sure, but so is the Clojure one. So I guess it's more like:

    fun bar () {
      let x = 5,
          y = 10
      foo(x,y)
    }

vs

    (defn bar []
      (let [x 5 
            y 10]
        (foo x y)))

[lkschubert8]

The clojure example was not missing the "scope brackets". That's exactly what let is. The equivalent c like in your first example should just be enclosed in brackets.

[blunte]

1st example: 10 symbols: (){=,=(,)} 2nd example: 10 symbols: ([]([]()))

[emsy]

Oh sure what’s the number of parens for (+ 1 (* 2 (/ 3 4))) in C? Granted, you don’t have to bother with precedence in Lisp

[blunte]

I'd bet there have been more bugs related to implicit operator precedence compared to ( ) explicit. And given that it's numeric operations, I'll bet some were very costly...