every time I get to use lisp syntax I feel a sense of relaxation, as if the background stress of thinking about precedence and the meaning of all these magic sigils and control flow constructs just melts away and I can finally see clearly what's going on. my first professional programming language was lisp, and almost every single project in the 35 years afterwards was C style. but it still feels like home.

Difficulty is, by definition, relative to one's skill

It's a factor and not the sole factor. Saying it's "by definition" is incorrect.

The author does a poor job of justifying why these pop-cognitive-psych theories should have more weight than prior exposure.

There's no reason to believe either way, except one path has decades of evidence. Human behavior is not overcome by programmatic "elegance". The dismissive "pop" prefix is signaling bias.

no magic keywords and syntax to memorize

ie no syntactic sugar. Pointless repetition is counter productive.

a there's no [logical] way to fall through >b [no way to] forget an else, >c expressions instead of statements >d no early returns

b. The interpreter catches it. d. Pointless execution is counter productive.

literally everything about the Lisp example is more readable to me

That's a single data point. Statistically it's worse, but you're practiced and apparently still physically able to quickly discern the nested count (or use an IDE). Yet another example of a position that is counter to existing studies. Heavy nesting is error prone, even when a program compiles (eg Monden et al., “Evaluating the Applicability of Reliability Prediction Models between Different Software,” ISSRE 2001)

Well, you see a lot of patterns. In OO there is the classic

   subject.verb(object)

In a case like

   add(left,right)

isn’t the return value the subject and left and right both objects? That way

   a = add(b,c)

Is really SVO.

That said, you can build data structures in Java with functions like

   Expression<Number> add(Expression<Number> left,Expression<Number> right)

and build something like S-expressions (not so nameless tuples) when you functions like the above, nested inside each other. You then can then write code to eval those expressions or write out Java code during a code generation phase —- it is fun on some level but if somebody else thought it combined the worst of Common Lisp and Java I woulsn’t blame them. Build a system like that and you will realize Expression<Expression<Number>> is a thing, you have to introduce a quote() operator, etc.

And that quoting is also part of the Lisp problem. You have to not only decode your code relative to distant parenthesis but you also need to know the quoting state of the code you’re looking at which could agin involved involuntary nesting. Burns up precious working memory, just as multi-line if requires cognitive effort because your eye is not guided by if/then/else. It’s another one of those languages like C++ that seduces smart people into burning up their IQ on trivia and you can’t get them to listen about it because they think they are smart.

One reason why our tools suck is that we are stuck representing programs as trees when they are really graphs.

For syntax highlighting try using a different colour for each level of indentation or parenthesis. I use prism-mode in emacs.

The latter. Maybe it's different in Lisp, but whenever I read code, I rarely care about the exact order of operations, just which ones are actually being executed. In that regard, the improved version allowed me to comprehend the gist of what was happening much faster than the regular version did. For a few seconds, before even attempting to start comprehending the actual operations being executed, my eyes were stuck trying to comprehend the parentheses.

Lisp is why I started using emacs and its parens matching features.

We can agree to disagree

I mean ask OP, I don't know what's what in the Scheme rXrs or Common Lisp standard libraries.

Although my general stance remains, most lisp code bases I've seen are remarkably verbose which leads to a glazing over far more than the lack of distinct symbols or prefix notation

Exactly. Assembler looks like Gobbledegook. But if you have worked with it for a year it looks like a perfect and delicious dish.

There's so much crap here, I don't even want to waste my time to unpack.

Lexical binding was added to Common Lisp almost as an afterthought

Common Lisp was lexically scoped from day one. You're arguing about CL using Elisp's history.

And your "cumbersome and stupid" snippet is that, because, well you wrote it that way.

     (local
       (def user (find-user user-id))
       (require-admin user)
       (def report (build-report user))
       (write-audit-log user report)
       (def receipt (send-report report))
       (record-delivery receipt))
       

In modern Lisp dialect like Clojure it would look even more cleaner.

Lisp is the language where you do whatever syntax is suitable for the task, yourself, in an afternoon. In Python you wait for a PEP.

And the reason that LISP code tends to be reluctant to split things out into multiple forms with variable assignment IMO is because it introduces a new level of nesting. It's too much friction to go from

    (defn foo [] 
       (+ 1 2))

to

    (defn foo []
      (let [x 2]
         (+ 1 x)))

I wish that there were some kind of macro available in Clojure that would provide a local "def" kind of functionality that doesn't pollute the namespace and just creates a binding in the parent scope. So that you could do something like:

    (defn foo []
       (let! x 2) 
       (+ 1 x))

When it comes to math, that's what people are familiar with so that is a factor. But function application is prefix as well for the majority of mainstream languages.

There's nothing "natural" about reading. We've not evolved as a species to have natural reading abilities. Of just about anything - be that cuneiform, hieroglyphs, katakana, math formulas or Sanskrit. Every person has to be taught how to read. A Mandarin-speaking person may argue that their writing system is "more natural" simply because it's one of the oldest and most widely used in history. Would you buy that argument?

You should really follow the HN commenting guidelines, specifically #1, 7 and 11.

Exactly, it's just unfamiliar to most people.

I find Clojure (a Lisp) more readable than many other languages. It's the style I like for pseudocode. Because I used it a lot. It's familiar.

"Easy" is relative and doesn't mean anything without a subject. Easy for whom?

(The(.

People say we can ignore them but I find the difficult to ignore.

But this is not the only problem with lisp syntax. I found that reading Ruby or Python is simply, on average, so much more efficient.

I found scheme somewhat readable - see haxima game world, https://sourceforge.net/projects/nazghul/ it contains scheme files - but I would not want to write any game logic in it.

Unfamiliarity.

There is so much conjecture in this article -- take the difference between 'lisp formatting' and 'javascript formatting'. I use so-called 'javascript formatting' (a decided and embarrassing misnomer) routinely when I develop Clojure. This article exudes inexperience with Lisp.

Similar to syntactically meaningful indentation, as with Python.

It's weird for a half hour, then it's second nature.

I love lisp and think it’s amazing. One of the things that commonly throws me off when I haven’t been writing it very much day to day is sometimes it’s unclear what’s going to be returned by a function.

An explicit return 0 is a lot more obvious than just having a 0.

Also, I’ll agree that a ‘ or a , in the wrong place is very easy to visually miss, then you can read a totally different meaning out of the code.

I'll repeat what other people here have been saying: I don't think Lisp is actually "hard" to read, in any objective sense.

It's "difficult" to read because it's different that other languages, but I think some of those differences actually improve readability once you understand the language. The forced use of parentheses everywhere guarantees that precedence is never ambiguous, for example.

Hot take: it's the recursive referential grammar, which does not have an analog in human natural language.

Human languages have hard limits on the reference tracking they support, regardless of syntax (marking, positional grammar, etc.). Humans have to reason to unpack LISP (or deeply nested functions or delegation in other languages).

Most languages use either subject-object-verb or subject-verb-object word orders, which together account for ~90% of world languages; verb-first word order languages only account for ~10% of world languages.

I don't think it's ONLY the parenthesis, it's also the lost opportunity to do meaningful things with indent that bothers me. For example: a missing end paren is often obvious where it should end to a human reader because the next definition starts at some set indent level (0 being the most obvious one). But we talk a different language to the compiler and to the human so the error message is far from where it would be useful.

Significant whitespace is actually a good thing™, even if you only use it to narrow compiler error messages. You can still have your parens but also get way better error messages if you just use the indent!

I have a suspicion that 99.999% of people who say that Lisp syntax is difficult to read haven't really tried to use it (outside of a random homework assignment in CS101).

The syntax is incredibly trivial, and needs very little initial instruction (except to tell newbs to stop trying to put the close-paren on a line by itself, like they are fresh out of a JavaScript boot camp and have no frame to conceive anything else, and that, really, the automatic indentation and the shapes should be at least as readable once you try to use it in real-world examples, and see how that works in practice).

Since Lisp puts the function name after the opening parenthesis, there is more distance between the parentheses. This makes it less likely that the parentheses are close enough to be scanned as a single shape.

Or we can navel-gaze differently, and claim it's more a shape, because then it's a nicely rounded shape that contains the whole function application/call:

    (foo x y z)

    foo(x, y, z);

There is a small chance that you're doing the following in a Lisp or C, but you'd be doing something fancy that most people do not (like writing the internals for a pluggable framework or object system):

    (((f a) b ) c)    Pseudo-Lisp

    f(a)(b)(c)        Pseudo-C

If you were doing this, and you thought the particular code was hard to read, you could throw in a variable or two, for the intermediate function (or function pointer) values. Or use a combinator...

When you don't have this fancy function-that-produces-function-that-produces-function pattern, your list head will typically have the name of a function there, and then the syntax simple shape and indentation visually disambiguates.

In skimming the article, I did see something the article could've followed through on, for a good syntax criticism of many Lisps:

    f[a][b][c]    Pseudo-C, array access notation

Array-intensive Lisp code could use syntax/dialect extension for square brackets for this, if the Lisp doesn't already have comparable syntax:

    [m a b c]

In both references and setters; see my most recent mention of it: https://mastodon.online/@neilvandyke/117067069023420085

I think the biggest problem is that expressions are lists, but we build lists with quoting, AND unquoting (or quasiquoting). It takes some effort to look at an expression and be certain of what will be run. Are we displaying the instructions to erase the hard drive, or the output of erasing the hard drive.

Compare this with Prolog. I like to say "a term is just a term until it's a goal". Assuming we have an erase_hard_drive/1 predicate, I know it's safe to do

    write_term(erase_hard_drive([force,silent,noprompt]), [])

or

    EraseCommand = erase_hard_drive([force,silent,noprompt]).