3 ms·

I am tired of seeing this programmer's meme constantly being repeated. Superfluous parens: Do not assume that the parentheses are superfluous, they are an exce

I am tired of seeing this programmer's meme constantly being repeated. Superfluous parens: Do not assume that the parentheses are superfluous, they are an excellent way to write down and communicate a tree-like structures. Code happens to be such a structure. With regard to the readability, this probably reveals an initial training in an Algol-syntax language. It is really not self-evident that s-expr are harder to read, and find it hard to believe that is true. Most likely, if it is the case for you, it more likely means it is not leveraging years of brain-training on Algol/C style notation. Do not mistake this for anything intrinsic about s-expr. To grab to personal experience: I have thought both Lispy and Alogly languages to complete programming virgins and have anecdotally seen less syntax-related mistakes in the former. The benefit of pre-learned infix semantics from mathematics courses is vanishingly small compared to the complexity of learning how to program. Unless your domain is actual mathematics (R, Matlab, ...), only a very small set of expressions in any program actually leverage that familiarity. The benefit in teaching/learning S-expr syntax is that is comparably uniform: whitespace breaks with paren ends. Infix languages introduce a set of context-dependent symbols. For example, a good portion of the errors I saw first timers make in class is mixing commas versus semicolon breaks. Even Python does this in the form of complex line breaking rules mixed with symbol-breaks (semicolon expression seperators, colon in conditionals, etc). It isn't hard when you are already familiar, but you definitely notice the complexity when holding the hand of a first-timer. In short, the 'not seeing parens' is akin to not 'seeing commas, semicolons, colons, braces, parens, backspaces, ...' in Algol-syntax languages. But honestly, things that are different should look different. Leveraging familiarity is a vital tool when designing a consumer-facing interface, but avoiding faulty preconceptions and ambiguities is more important for the professional tool that is a serious programming language. I personally think in C when handling low-level memory, Lisp when doing metaprogramming, Prolog when doing logic programming and something APL-like when doing linear algebra.

dwheeler 8y ago
> Superfluous parens: Do not assume that the parentheses are superfluous, they are an excellent way to write down and communicate a tree-like structures. Code happens to be such a structure. Actually, the people saying "you won't see the parentheses after a while" are a significant subset of advocates of Lisp, who know the language well! Here's a quote from the old Common Lisp FAQ: "After you've written and read enough Lisp, you stop seeing the parentheses. (Reports vary from a few days to a few weeks.) They don't disappear in some magical way, but you start to see the structure of the code rather than just "lots of fingernail clippings". We all agree that it's important to be able to see the structure of code. But if your goal is to not see the only marker with important information, then there's a problem. > Infix languages introduce a set of context-dependent symbols. That is not required at all. That conflates infix with precedence. What developers want is infix, not necessarily precedence. In practice many developers avoid using precedence, in fact, a large percentage don't understand the precedence rules of the language they're using all. In Algol-like languages, they just use parens to force all evaluation orders even when they are not necessary. If your infix system doesn't support a built-in precedence, there are no context-dependent symbols. For example, in curly-infix, {2 + 3 + 4} => (+ 2 3 4), but there is nothing special about "+". The expression {2 qwe 3 qwe 4} => (qwe 2 3 4). If you want precedence, you use another pair of curly braces to directly express it, just like you would in an Algol-like language: {2 + {3 * 4}} => (+ 2 (* 3 4)), while {{2 + 3} * 4} => (* (+ 2 3) 4). As a result, there's no dependence on context-dependent symbols, and you DO get infix. SRFI-105, at <https://srfi.schemers.org/srfi-105/srfi-105.html> https://srfi.schemers.org/srfi-105/srfi-105.html>, quotes research about precedence use in "Developer beliefs about binary operator precedence" by Derek M. Jones <http://www.knosof.co.uk/cbook/accu06.html> http://www.knosof.co.uk/cbook/accu06.html>. Some key points: "They first measured the visible source code of a number of large C programs... only 1.9% of all expressions had at least two binary operators (where precedence would make a difference)... In those cases where precedence could have been used (the 1.9% of all expressions), 67% (102,822/154,575) of the operator pairs were explicitly parenthesized (making any precedence rule moot)." "The authors then described a survey of developers at the 2006 ACCU conference to determine if they correctly applied the precedence and associativity of the binary operators common to C, C++, C#, Java, Perl, and PHP. In this experiment only 66.7% of the answers were correct (standard deviation 8.8, poorest performer 45.2% correct, best performer 80.5% correct); this was not much better than random chance (50%). Even many widely-used operator pairs had relatively poor results... (only) 69% when they combined / and +. These were far short of the 100% one might expect. These developers ranged from 5 to 25 years of professional experience, and the more-experienced developers did not do better (!). ... these results clearly suggest that precedence rules may harm, instead of help, the process of developing correct code."

dwheeler 8y ago

> Superfluous parens: Do not assume that the parentheses are superfluous, they are an excellent way to write down and communicate a tree-like structures. Code happens to be such a structure. Actually, the people saying "you won't see the parentheses after a while" are a significant subset of advocates of Lisp, who know the language well! Here's a quote from the old Common Lisp FAQ: "After you've written and read enough Lisp, you stop seeing the parentheses. (Reports vary from a few days to a few weeks.) They don't disappear in some magical way, but you start to see the structure of the code rather than just "lots of fingernail clippings". We all agree that it's important to be able to see the structure of code. But if your goal is to not see the only marker with important information, then there's a problem. > Infix languages introduce a set of context-dependent symbols. That is not required at all. That conflates infix with precedence. What developers want is infix, not necessarily precedence. In practice many developers avoid using precedence, in fact, a large percentage don't understand the precedence rules of the language they're using all. In Algol-like languages, they just use parens to force all evaluation orders even when they are not necessary. If your infix system doesn't support a built-in precedence, there are no context-dependent symbols. For example, in curly-infix, {2 + 3 + 4} => (+ 2 3 4), but there is nothing special about "+". The expression {2 qwe 3 qwe 4} => (qwe 2 3 4). If you want precedence, you use another pair of curly braces to directly express it, just like you would in an Algol-like language: {2 + {3 * 4}} => (+ 2 (* 3 4)), while {{2 + 3} * 4} => (* (+ 2 3) 4). As a result, there's no dependence on context-dependent symbols, and you DO get infix. SRFI-105, at <https://srfi.schemers.org/srfi-105/srfi-105.html> https://srfi.schemers.org/srfi-105/srfi-105.html>, quotes research about precedence use in "Developer beliefs about binary operator precedence" by Derek M. Jones <http://www.knosof.co.uk/cbook/accu06.html> http://www.knosof.co.uk/cbook/accu06.html>. Some key points: "They first measured the visible source code of a number of large C programs... only 1.9% of all expressions had at least two binary operators (where precedence would make a difference)... In those cases where precedence could have been used (the 1.9% of all expressions), 67% (102,822/154,575) of the operator pairs were explicitly parenthesized (making any precedence rule moot)." "The authors then described a survey of developers at the 2006 ACCU conference to determine if they correctly applied the precedence and associativity of the binary operators common to C, C++, C#, Java, Perl, and PHP. In this experiment only 66.7% of the answers were correct (standard deviation 8.8, poorest performer 45.2% correct, best performer 80.5% correct); this was not much better than random chance (50%). Even many widely-used operator pairs had relatively poor results... (only) 69% when they combined / and +. These were far short of the 100% one might expect. These developers ranged from 5 to 25 years of professional experience, and the more-experienced developers did not do better (!). ... these results clearly suggest that precedence rules may harm, instead of help, the process of developing correct code."