This is false. Lisp uses parentheses where other languages use (), [], {} or nothing at all. For example, in C I can write int i = 0, but the equivalent Lisp code involves three pairs of parentheses. Or take something like a[i] = f(i + 1) / 2 + p. The equivalent Lisp code is something like (setf (aref ai) (+ (/ (f (+ i1)) 2) p)), and you can’t tell me that’s not a lot of parentheses.
This is false, Lisp is a family of languages. Clojure is an example of a Lisp where you have different types of literals using () for lists, [] for vectors, {} for maps, and #{} for sets. Furthermore, there are plenty of libraries for doing infix syntax which can be trivially expressed using macros. For example, infix library in Clojure lets you write math using infix syntax. That said, it’s pretty rare that you’re actually writing a bunch of math expressions in regular code unless you’re working in a specific domain, so this hardly comes up in practice.
OK, my code snippets are Common Lisp. But note that none of them involve list/vector/set literals. I was thinking of [] for array indexing and {} for code blocks.
As for infix macros, sure, that’s not hard to do, but it’s not built into the language and there being “plenty of libraries” is part of the problem: They’re all subtly different, none are standard, and I suspect most people don’t use them anyway. (Plus there’s fun little design issues like whether a*x + b should parse the same as a * x + b, and if it does, then how do you refer to a variable called a*x from an infix environment?)
It doesn’t solve the main issue anyway. Take this snippet from the “infix” readme:
It ends with a cluster of )))) (reinforcing the “lots of parentheses” impression) and all of those parentheses mean something different: From the outside in, we have the end of a symbol definition (def ...), the end of a function (fn ...), the end of a macro invocation (infix ...), and the end of a function call sqrt(...). It definitely isn’t just “the same number [of parentheses] as any other language that uses parentheses to make function calls”.
Compare e.g. these versions written in Haskell:
hypot = \x y -> sqrt (x ** 2 + y ** 2)
… or Perl:
subhypot($x, $y) { sqrt($x ** 2 + $y ** 2)}
… or if you want to separate the function and symbol definition parts:
OK, my code snippets are Common Lisp. But note that none of them involve list/vector/set literals. I was thinking of [] for array indexing and {} for code blocks.
Again, Clojure uses vectors for arguments, so you end up with syntax like this which provides the same visual information as any mainstream language.
It doesn’t solve the main issue anyway. Take this snippet from the “infix” readme:
Yes it does actually because you have syntax hints indicating the type of data structure you’re looking at. For example, in the snippet you highlight, the function arguments are in a vector.
It ends with a cluster of )))) (reinforcing the “lots of parentheses” impression) and all of those parentheses mean something different
First of all, you have exact same amount of parens as you would in a mainstream language like Java, C, or Js. Second, the parens do mean the same thing in that example. The big benefit with s-exps though is that you have structural editing, and you don’t actually manage parens by hand or even think about them. You treat expressions as building blocks that you manipulate and compose together. There’s nothing even remotely comparable to this available in languages like Haskell.
However, here’s an example for you where you don’t have same parens.
here you have different data structures manipulated, and you have different parens representing them.
From the outside in, we have the end of a symbol definition (def …), the end of a function (fn …), the end of a macro invocation (infix …), and the end of a function call sqrt(…). It definitely isn’t just “the same number [of parentheses] as any other language that uses parentheses to make function calls”.
It’s just broken down in the example. In practice you have defn and you just write:
(defn hypot [x y] (infix sqrt(x ** 2 + y ** 2)))
The huge advantage over Haskell is that syntax is very simple and regular. You don’t have to think about it at all. Languages like Haskell and Perl introduce a lot of mental overhead because you have to memorize all the special cases and behaviors the syntax introduces. You can write really concise code, but there’s a cost to it. There’s a reason people refer to Perl as a write only language. On the other hand, Clojure hits the sweet spot of being very concise without needing a complex syntax.
I disagree with pretty much everything you write here, but especially this:
First of all, you have exact same amount of parens as you would in a mainstream language like Java, C, or Js.
My Perl example uses “mainstream language” syntax. Apparently that doesn’t count because it’s Perl (scary! mental overhead! write only!), so here’s exactly the same thing in JavaScript:
function hypot(x, y) { return Math.sqrt(x ** 2 + y ** 2);}
… or
const hypot = function (x, y) { returnMath.sqrt(x ** 2 + y ** 2);};
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.
This is false. Lisp uses parentheses where other languages use
(),[],{}or nothing at all. For example, in C I can writeint i = 0, but the equivalent Lisp code involves three pairs of parentheses. Or take something likea[i] = f(i + 1) / 2 + p. The equivalent Lisp code is something like(setf (aref a i) (+ (/ (f (+ i 1)) 2) p)), and you can’t tell me that’s not a lot of parentheses.This is false, Lisp is a family of languages. Clojure is an example of a Lisp where you have different types of literals using
()for lists,[]for vectors,{}for maps, and#{}for sets. Furthermore, there are plenty of libraries for doing infix syntax which can be trivially expressed using macros. For example, infix library in Clojure lets you write math using infix syntax. That said, it’s pretty rare that you’re actually writing a bunch of math expressions in regular code unless you’re working in a specific domain, so this hardly comes up in practice.OK, my code snippets are Common Lisp. But note that none of them involve list/vector/set literals. I was thinking of
[]for array indexing and{}for code blocks.As for infix macros, sure, that’s not hard to do, but it’s not built into the language and there being “plenty of libraries” is part of the problem: They’re all subtly different, none are standard, and I suspect most people don’t use them anyway. (Plus there’s fun little design issues like whether
a*x + bshould parse the same asa * x + b, and if it does, then how do you refer to a variable calleda*xfrom an infix environment?)It doesn’t solve the main issue anyway. Take this snippet from the “infix” readme:
(def hypot (fn [x y] (infix sqrt(x ** 2 + y ** 2))))It ends with a cluster of
))))(reinforcing the “lots of parentheses” impression) and all of those parentheses mean something different: From the outside in, we have the end of a symbol definition(def ...), the end of a function(fn ...), the end of a macro invocation(infix ...), and the end of a function callsqrt(...). It definitely isn’t just “the same number [of parentheses] as any other language that uses parentheses to make function calls”.Compare e.g. these versions written in Haskell:
hypot = \x y -> sqrt (x ** 2 + y ** 2)… or Perl:
sub hypot($x, $y) { sqrt($x ** 2 + $y ** 2)}… or if you want to separate the function and symbol definition parts:
*hypot = sub ($x, $y) { sqrt($x ** 2 + $y ** 2) };Again, Clojure uses vectors for arguments, so you end up with syntax like this which provides the same visual information as any mainstream language.
Yes it does actually because you have syntax hints indicating the type of data structure you’re looking at. For example, in the snippet you highlight, the function arguments are in a vector.
First of all, you have exact same amount of parens as you would in a mainstream language like Java, C, or Js. Second, the parens do mean the same thing in that example. The big benefit with s-exps though is that you have structural editing, and you don’t actually manage parens by hand or even think about them. You treat expressions as building blocks that you manipulate and compose together. There’s nothing even remotely comparable to this available in languages like Haskell.
However, here’s an example for you where you don’t have same parens.
(defn foo [{:keys [x y]}] (let [z (str x " " y)] {:result z}))here you have different data structures manipulated, and you have different parens representing them.
It’s just broken down in the example. In practice you have
defnand you just write:(defn hypot [x y] (infix sqrt(x ** 2 + y ** 2)))The huge advantage over Haskell is that syntax is very simple and regular. You don’t have to think about it at all. Languages like Haskell and Perl introduce a lot of mental overhead because you have to memorize all the special cases and behaviors the syntax introduces. You can write really concise code, but there’s a cost to it. There’s a reason people refer to Perl as a write only language. On the other hand, Clojure hits the sweet spot of being very concise without needing a complex syntax.
I disagree with pretty much everything you write here, but especially this:
My Perl example uses “mainstream language” syntax. Apparently that doesn’t count because it’s Perl (scary! mental overhead! write only!), so here’s exactly the same thing in JavaScript:
function hypot(x, y) { return Math.sqrt(x ** 2 + y ** 2);}… or
const hypot = function (x, y) { return Math.sqrt(x ** 2 + y ** 2);};… or
const hypot = (x, y) => Math.sqrt(x ** 2 + y ** 2);Note how none of these involve four layers of nested parentheses.
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.