It will depend on whom you talk to - perhaps how old they are, and certainly where they come from (experience wise, education wise, etc.)
The usual easy excuse is about parens, but that complaint has been put to rest so many times that it's not worth replying to anymore. (And people said the same thing about Python whitespace, but now Python is at or near the top of the pile.)
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.
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.
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".
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.
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.
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...
Young children tend to look with disgust upon many meals that adults find especially delicious. Is it a problem with the food, or is it a matter of experience and perspective?
I'm very tempted to give examples, but it's not worth it here. Suffice to say, this falls squarely in the category of "you don't know what you're missing".
In this long essay by Paul Graham - http://www.paulgraham.com/avg.html - if you're willing to search for and begin reading at "The Blub Paradox", you'll get a sense of what I mean.
And then if you want to really be enlightened, at least to concepts that really what matter regarding programming languages, go watch videos from Rich Hickey (Clojure).
I think I do. I've had the argument many times here, code-as-data, metaprogramming, structured-programming. Things I don't want, aren't worth the trade-off, and things I don't want to see colleagues inflicting on others.
I've already watched (almost) every Rich Hickey video (well his main "talks"). I love them, agree with the vast majority of what he says and it has shaped me as a programmer, but I don't agree with the final conclusion being to code using lisps ;)
The claimed problem that exists however is... lame. It really boils to "if it doesn't look like C, I'm not learning it", which is a fairly pathetic argument, and not one that can actually be bested with any targeted marketing or discussion.
Most developers only learn a new language because they're forced to: at work, or joining an existing project as part of their hobby, or because the library they need requires it, or because its the only option available to them. At the point, the fact that it looks like C, or doesn't, won't matter. And they'll get over it. No one claims Nginx/Apache DSL is great, or terribly C-like. Or even really claim that its un-C-like. But I'll reluctantly learn it (to a minimum need) because I want my damned site up. Most languages are learned like that.
Developers who learn a new language for the sake of learning a new language will likely not be drawn in by it being C-like syntax, or not. At least, most who've gone around that rodeo a few times will quickly realize that the superficial syntax isn't that interesting -- It takes 20 minutes to learn the syntax (maybe not APL). You're in it for the different semantics.
What you need for mass lisp adoption is to get a hype cycle going, and pathetic justifications for parenthesis isn't going to get you there. Babbling about how hyper-parameterized cooperatively consistent parenthesized datastructures will change the world is likely more effective.
> It really boils to "if it doesn't look like C, I'm not learning it"
I think it's funny that most people who complain about this are likely coming from Java, JS, or Python, not C. And they probably would suffer a lot in C...
I've made the jump to Clojure, and to be honest, it's painful going back to other languages, but not just because of the syntax, but rather the lack of expressive power, and the excess of boilerplate. I had to do some Python work last year, and it felt like coding with a straightjacket on.
The usual easy excuse is about parens, but that complaint has been put to rest so many times that it's not worth replying to anymore. (And people said the same thing about Python whitespace, but now Python is at or near the top of the pile.)