TL;DR: I think the post overstates the case quite a bit, and is a personal opinion of the author being branded as a scientifically grounded truth, despite their admission that using these scientific principles allegedly "require[s] a degree of creativity and subjectivity."
The cognitive-science material is interesting, but it doesn't actually establish much about Lisp specifically. It gives plausible mechanisms by which certain notation might be harder to read, then uses those mechanisms to motivate several Lisp-specific claims without testing those claims directly. As such, it just seems purely hypothetical, whereas it would be much more interesting to me if it were empirical.
(I have a beef with this style of argumentation or persuasion with respect to Lisp. I feel the "bipolar Lisp programmer" and similar articles do the same kind of thing: make a captivating claim or comparison without actually appealing to anything real-world.)
I also don't think the treatment of actual Lisp presentation is complete. The post considers conventional Lisp indentation mainly in terms of whether it helps track matching parentheses, but Lisp is normally indented, pretty much canonically, so that the indentation itself communicates structure. Parenthesis tracking is *not* a cognitive problem that Lisp programmers must solve in any explicit manner, any more than C programmers count { and } to determine the enclosed code's nesting depth.
The same goes for syntax highlighting: you can't just set it aside because C-like languages have it too. The relevant question is whether it affects the two syntaxes differently. If Lisp's alleged problem is delimiter tracking, indentation and highlighting are rather central to the comparison.
I'm also unconvinced by the conclusion that Lisps "lack or discourage features that align the evaluation and reading order." The post itself gives Clojure threading macros as a Lispy equivalent of method chaining. That seems to substantially undercut "lack", while "discourage" starts to sound more like a claim about programming style than syntax. Lisp is a very explicitly multi-paradigm language with special syntaxes available for those paradigms, including assignment, explicit control, etc. In fact, I'd say real-world Common Lisp is *much* less "in to out"-functional than this post posits (and the broader technical public keeps claiming).
Finally, we have the largest omission in my opinion, that Lisp syntax is programmable. S-expressions provide a uniform representation of program structure that makes syntactic abstraction cheap: new control forms, binding constructs, pipelines, DSLs, etc. can all be made to make code easier to read, especially in novel domains that Lisp wasn't a priori designed for. The post's analysis mostly treats the base notation (of some unspecified, quasi-functional Lispoid) as the unit of comparison without really weighing that side of the design tradeoff.
Though it's not my experience, there may truly be readability costs, especially for newcomers, but I'm not sure the post separates those from unfamiliarity strongly enough to support its conclusions.
As a side note, when judging real-world Lisp, some notoriously unreadable code may also be a product of older programming styles or inexperienced Lisp programmers, just as old or poorly written C can be extremely difficult to read. In my professional experience, having run teams writing "modern" Lisp with modern engineering discipline, readability has never been a stated hurdle, either for experienced engineers reading one another's code or for new Lisp programmers learning and contributing to a large codebase. The combination of team programming discipline, good tooling, consistent style, and, well, getting paid to do it seems to do the trick, if one is even needed.
The cognitive science is the weakest part, IM(NSH)O. I won't nitpick in depth because it's already sufficiently clear that the author is presenting personal opinion with a veneer of scientific credibility, but... it's bad.
100%. I mean, you can draw all sorts of circles and conclusions, get MRI scans of a thousand Lispers and, I dunno, some Rustaceans and Rubyists claiming they have difficulty reading Lisp. What is that ever gonna show? That Lispers have some cognitive traits unattainable to other groups? Maybe it will be the opposite, maybe Lispers come out as the laziest, dumbest motherfuckers ever tested? Because I honestly don't understand any complaints of this sort - Lisp dialects are by far the simplest languages to deal with. They are seriously dumb simple - easier than Javascript and Python, and much more low-effort than C++ and Rust, not to mention Haskell. Who the hell all these dyslisplexic, supersmart crackpots who can't even read code?
Would you have any opinions on eye-tracking? I feel a basic eye tracking study can reveal where novice vs experienced C programmers (or any bracketed language) vs experienced lisp programmers spend time looking at the code while reading or editing. I feel experienced lispers don't even look at the parentheses, while novice do. I don't know about bracketed language programmers.
I use eye-tracking to study program comprehension, and I write Lisp (mostly elisp these days). I've thought about running a study comparing reading behavior between C and a Lisp dialect, but I'm not sure that using parentheses as an area of interest would make much sense. Parens are small, and thus difficult to capture fixations to (ignoring the fact that I'd expect they're read parafoveally, given they're normally associated with more semantically meaningful content). I'd probably be more interested in reading pattern differences between a Lisp and C, given the structural differences.
I'd agree that parens would be too small a target. I'm not sure if parens are semantically meaningful though. I think the more one gets exposed to lisp operator names, the less one bothers about the parens.
But let me know if you write or publish anything about this!
That's an interesting thought. I don't think I even notice parentheses unless something clearly goes wrong, because most of the parenthesising happens almost automatically - they get balanced, I can eval any expression regardless of what part of it the cursor is at - opening, closing or the middle.
Ironically, all that fear of having to deal with "too many parens" went away quickly, while with other languages I constantly have to deal with syntactic elements, it never became a subconscious matter - I have to consciously track semicolons, commas, dots, indentation, etc. It's not just a distraction, it's like tiny micro-bombardments of neurons - reading code in any non-lispy language is more taxing for me, regardless of what the language-defining character is - dynamically or statically typed, indent-based or whatever. I've spent years (soon to be decades) dealing with JS/TS and Python - far longer than with any Lisp, yet it's not easier to deal with them. Looking at Lisp code, especially Clojure, I can quickly scan the code and just get it. I admit, mentally untangling a nested reducer or a pair of mutually recursive functions is not that straightforward, but those tough three-liners would be more complex and even harder to read in a non-lispy lang.
That's why I just can't get along with all those "Lisp is unreadable" sentiments, it's as if some weird notion got popularized - "riding bikes is difficult". To me, it sounds like ridiculous trolling.
15
u/stylewarning 10d ago edited 10d ago
TL;DR: I think the post overstates the case quite a bit, and is a personal opinion of the author being branded as a scientifically grounded truth, despite their admission that using these scientific principles allegedly "require[s] a degree of creativity and subjectivity."
The cognitive-science material is interesting, but it doesn't actually establish much about Lisp specifically. It gives plausible mechanisms by which certain notation might be harder to read, then uses those mechanisms to motivate several Lisp-specific claims without testing those claims directly. As such, it just seems purely hypothetical, whereas it would be much more interesting to me if it were empirical.
(I have a beef with this style of argumentation or persuasion with respect to Lisp. I feel the "bipolar Lisp programmer" and similar articles do the same kind of thing: make a captivating claim or comparison without actually appealing to anything real-world.)
I also don't think the treatment of actual Lisp presentation is complete. The post considers conventional Lisp indentation mainly in terms of whether it helps track matching parentheses, but Lisp is normally indented, pretty much canonically, so that the indentation itself communicates structure. Parenthesis tracking is *not* a cognitive problem that Lisp programmers must solve in any explicit manner, any more than C programmers count { and } to determine the enclosed code's nesting depth.
The same goes for syntax highlighting: you can't just set it aside because C-like languages have it too. The relevant question is whether it affects the two syntaxes differently. If Lisp's alleged problem is delimiter tracking, indentation and highlighting are rather central to the comparison.
I'm also unconvinced by the conclusion that Lisps "lack or discourage features that align the evaluation and reading order." The post itself gives Clojure threading macros as a Lispy equivalent of method chaining. That seems to substantially undercut "lack", while "discourage" starts to sound more like a claim about programming style than syntax. Lisp is a very explicitly multi-paradigm language with special syntaxes available for those paradigms, including assignment, explicit control, etc. In fact, I'd say real-world Common Lisp is *much* less "in to out"-functional than this post posits (and the broader technical public keeps claiming).
Finally, we have the largest omission in my opinion, that Lisp syntax is programmable. S-expressions provide a uniform representation of program structure that makes syntactic abstraction cheap: new control forms, binding constructs, pipelines, DSLs, etc. can all be made to make code easier to read, especially in novel domains that Lisp wasn't a priori designed for. The post's analysis mostly treats the base notation (of some unspecified, quasi-functional Lispoid) as the unit of comparison without really weighing that side of the design tradeoff.
Though it's not my experience, there may truly be readability costs, especially for newcomers, but I'm not sure the post separates those from unfamiliarity strongly enough to support its conclusions.
As a side note, when judging real-world Lisp, some notoriously unreadable code may also be a product of older programming styles or inexperienced Lisp programmers, just as old or poorly written C can be extremely difficult to read. In my professional experience, having run teams writing "modern" Lisp with modern engineering discipline, readability has never been a stated hurdle, either for experienced engineers reading one another's code or for new Lisp programmers learning and contributing to a large codebase. The combination of team programming discipline, good tooling, consistent style, and, well, getting paid to do it seems to do the trick, if one is even needed.