The total number of parens in your examples is about the same, except you also have a bunch of noise like random semicolons sprinkled in. Meanwhile, nesting is a feature, not a bug because it provides you with additional visual information about relationships in code. The only people who incessantly bray about nested parens are the ones who’ve never actually worked with Lisp for any period of time. If this was a genuine problem with the syntax then stuff like sweet expressions would’ve taken off. The reality is, as I already explained and you’ve ignored, is that the editor manages the parens for you. When you work with Lisp, typing opening paren is equivalent to having a command sequence to say I’m starting a new expression.
Let’s take a step back. I feel this discussion has got off track a bit.
The original claim was that Lisp’s reputation as having lots of parentheses was undeserved because it uses the same number of parens as other languages that use () for function calls; Lisp just puts the parens in a different place.
My objection was basically that Lisp also uses parentheses for what in other languages is a declaration, a statement, a block, an operator, etc so just looking at function calls doesn’t give you the whole picture.
You said that “Lisp” is actually a family of languages, that Clojure uses fewer parens than other Lisps (I object: still more than non-Lisps), that there are macros for infix expression syntax (I object: non-standard/3rd-party solutions that only help with operators), that parens don’t even matter because of structural editing tools (I object: irrelevant, the discussion was about the number of parens, not whether they “matter”).
I also disagree with “the total number of parens in your examples is about the same”. This is a micro-example, so when the original Lisp (Clojure) code has 4 pairs of parens and the C-style (JavaScript, Perl) version has 2, that’s twice the parentheses to me, not “about the same”.
(defn ^String trim-newline "Removes all trailing newline \\n or return \\r characters from string. Similar to Perl's chomp." {:added "1.2"} [^CharSequence s] (loop [index (.length s)] (if (zero? index) "" (let [ch (.charAt s (dec index))] (if (or (= ch \newline) (= ch \return)) (recur (dec index)) (.. s (subSequence 0 index) toString))))))(defn blank? "True if s is nil, empty, or contains only whitespace." {:added "1.2"} [^CharSequence s] (if s (loop [index (int 0)] (if (= (.length s) index) true (if (Character/isWhitespace (.charAt s index)) (recur (inc index)) false))) true))(defn ^String escape "Return a new string, using cmap to escape each character ch from s as follows: If (cmap ch) is nil, append ch to the new string. If (cmap ch) is non-nil, append (str (cmap ch)) instead." {:added "1.2"} [^CharSequence s cmap] (loop [index (int 0) buffer (StringBuilder. (.length s))] (if (= (.length s) index) (.toString buffer) (let [ch (.charAt s index)] (if-let [replacement (cmap ch)] (.append buffer replacement) (.append buffer ch)) (recur (inc index) buffer)))))
Total number of pairs of parentheses (not counting doc-strings): 45
My translation of the code to JavaScript:
functiontrim_newline(s) { for (let index = s.length; index > 0; index--) { let ch = s.charAt(index - 1); if (ch != '\n' && ch != '\r') { return s.substr(0, index); } } return"";}functionblank(s) { if (s == null) { returntrue; } for (let index = 0; index < s.length; index++) { if (!Character.isWhitespace(s.charAt(index))) { returnfalse; } } returntrue;}functionescape(s, cmap) { let buffer = ""; for (let index = 0; index < s.length; index++) { let ch = s.charAt(index), replacement = cmap(ch); buffer += replacement !== undefined ? replacement : ch; } return buffer;}
Total number of pairs of parentheses: 15
That’s about a factor of 3. Now, you can argue that I shouldn’t care about the parentheses, but my point is simply that they’re there and you can’t really avoid them if you write in anything resembling idiomatic Lisp.
The total number of parens in your examples is about the same, except you also have a bunch of noise like random semicolons sprinkled in. Meanwhile, nesting is a feature, not a bug because it provides you with additional visual information about relationships in code. The only people who incessantly bray about nested parens are the ones who’ve never actually worked with Lisp for any period of time. If this was a genuine problem with the syntax then stuff like sweet expressions would’ve taken off. The reality is, as I already explained and you’ve ignored, is that the editor manages the parens for you. When you work with Lisp, typing opening paren is equivalent to having a command sequence to say I’m starting a new expression.
Let’s take a step back. I feel this discussion has got off track a bit.
The original claim was that Lisp’s reputation as having lots of parentheses was undeserved because it uses the same number of parens as other languages that use
()for function calls; Lisp just puts the parens in a different place.My objection was basically that Lisp also uses parentheses for what in other languages is a declaration, a statement, a block, an operator, etc so just looking at function calls doesn’t give you the whole picture.
You said that “Lisp” is actually a family of languages, that Clojure uses fewer parens than other Lisps (I object: still more than non-Lisps), that there are macros for infix expression syntax (I object: non-standard/3rd-party solutions that only help with operators), that parens don’t even matter because of structural editing tools (I object: irrelevant, the discussion was about the number of parens, not whether they “matter”).
I also disagree with “the total number of parens in your examples is about the same”. This is a micro-example, so when the original Lisp (Clojure) code has 4 pairs of parens and the C-style (JavaScript, Perl) version has 2, that’s twice the parentheses to me, not “about the same”.
I’ve tried to find a slightly bigger code sample, so I clicked around in the Clojure standard library. Here’s a chunk of
clojure.string: https://github.com/clojure/clojure/blob/ade22645ba5dbf4c0d8115b19938af96d6fb4cd5/src/clj/clojure/string.clj#L275-L317(defn ^String trim-newline "Removes all trailing newline \\n or return \\r characters from string. Similar to Perl's chomp." {:added "1.2"} [^CharSequence s] (loop [index (.length s)] (if (zero? index) "" (let [ch (.charAt s (dec index))] (if (or (= ch \newline) (= ch \return)) (recur (dec index)) (.. s (subSequence 0 index) toString))))))(defn blank? "True if s is nil, empty, or contains only whitespace." {:added "1.2"} [^CharSequence s] (if s (loop [index (int 0)] (if (= (.length s) index) true (if (Character/isWhitespace (.charAt s index)) (recur (inc index)) false))) true))(defn ^String escape "Return a new string, using cmap to escape each character ch from s as follows: If (cmap ch) is nil, append ch to the new string. If (cmap ch) is non-nil, append (str (cmap ch)) instead." {:added "1.2"} [^CharSequence s cmap] (loop [index (int 0) buffer (StringBuilder. (.length s))] (if (= (.length s) index) (.toString buffer) (let [ch (.charAt s index)] (if-let [replacement (cmap ch)] (.append buffer replacement) (.append buffer ch)) (recur (inc index) buffer)))))Total number of pairs of parentheses (not counting doc-strings): 45
My translation of the code to JavaScript:
function trim_newline(s) { for (let index = s.length; index > 0; index--) { let ch = s.charAt(index - 1); if (ch != '\n' && ch != '\r') { return s.substr(0, index); } } return "";}function blank(s) { if (s == null) { return true; } for (let index = 0; index < s.length; index++) { if (!Character.isWhitespace(s.charAt(index))) { return false; } } return true;}function escape(s, cmap) { let buffer = ""; for (let index = 0; index < s.length; index++) { let ch = s.charAt(index), replacement = cmap(ch); buffer += replacement !== undefined ? replacement : ch; } return buffer;}Total number of pairs of parentheses: 15
That’s about a factor of 3. Now, you can argue that I shouldn’t care about the parentheses, but my point is simply that they’re there and you can’t really avoid them if you write in anything resembling idiomatic Lisp.