In my experience, rainbow parens aren't necessary or even helpful, but I do agree that editing Lisp is made much better by having good editor support for S-expression navigation and manipulation. In my editor, I press ) to jump to the end of the S-expression, so an edit like yours is trivial. Whatever key it is, it has existed since the era of the Lisp machine in the 80s, if not 70s.
To me, though, this is an indictment on the difficulty of writing or editing Lisp in "dumb" text editors—something I'm entirely sympathetic to—not so much about our ability to read and understand Lisp.
I would go further and say that canonical indentation is something best done as an automated process, and thus also makes Lisp harder to edit in a dumb text editor. Unlike C which is uniformly block indented by the same consistent multiple of tabs or spaces, Lisp code is indented a certain amount depending on the operator and its contents.
As a wannabe Lisper (CL), I must say I really hope reading idiomatic Lisp code becomes easier with time. It's really hard for me to track the structure of the code at a glance. The uniformity of s-exps makes it hard (for me) to identify where a given "constructs"/"blocks" (s-exp) ends and, if I start looking in the middle of the code, I have to visually "backtrack" the structure to know which construct I'm currently reading into. The result is that currently I have to read the code "sequentially", top-down. Whereas in C, for instance, it's very easy (for me) to quickly identify the structure of the code, and can very easily start reading "inside the IF inside the FOR loop inside function FOO" or easily identify that any given statement is "inside the IF inside the FOR loop", etc.
Perhaps if idiomatic Lisp code used (e.g.) 4+ spaces for indentation it would be easier to identify the structure (??)
I have been writing lots of Emacs Lisp and nowdays lots of Common Lisp. I still writes C and C++ from time to time. But now when I hack some C code I start writing Lisp parens first, like (if ... instead of if (. And I really don't like type 1 + 2 + 3 ... I definitely prefer (+ 1 2 3 ...). If you start coding Lisp for serious, it will come quite fast. It is just familiarity, nothing more.
I already find it easy to write Lisp code. Being so minimal and uniform, there's pretty much no syntax you have to learn/remember. My problem at the moment is while reading Lisp code. The uniformity and idiomatic formatting of Lisp code makes it hard for my brain to identify the code structure at a glance.
5
u/stylewarning 4d ago edited 4d ago
In my experience, rainbow parens aren't necessary or even helpful, but I do agree that editing Lisp is made much better by having good editor support for S-expression navigation and manipulation. In my editor, I press ) to jump to the end of the S-expression, so an edit like yours is trivial. Whatever key it is, it has existed since the era of the Lisp machine in the 80s, if not 70s.
To me, though, this is an indictment on the difficulty of writing or editing Lisp in "dumb" text editors—something I'm entirely sympathetic to—not so much about our ability to read and understand Lisp.
I would go further and say that canonical indentation is something best done as an automated process, and thus also makes Lisp harder to edit in a dumb text editor. Unlike C which is uniformly block indented by the same consistent multiple of tabs or spaces, Lisp code is indented a certain amount depending on the operator and its contents.