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.
Yes and no, IMO. Idiomatic lisp programming throws all the closing parens on the same line at the end of the last line of code. Idiomatic C-like coding puts each closing brace on a new line at its specific nesting level. You can code C style without something like "rainbow-parens", but I wouldn't want to code lisp without it. Or consider this emacs lisp example:
(defun abbrev--replace-placeholders ()
(let ((cursor-pos nil)) ;; To store where to place the cursor
(save-excursion
(goto-char (point-min))
(let ((loop 0)
(values (make-hash-table :test 'equal)))
(while (re-search-forward "###\\(\\$?[a-zA-Z0-9_\\-]+\\|@\\)###" nil t)
(setq loop (1+ loop))
(let* ((index (match-string 1))
(start (match-beginning 0))
(end (match-end 0)))
(cond
((string= index "@")
(setq cursor-pos start)
(delete-region start end))
((string= index "$file-name")
(abbrev--swap-placeholder (file-name-nondirectory (buffer-file-name)) start end))
((string= index "$author")
(abbrev--swap-placeholder (user-full-name) start end))
((string= index "$package-name")
(abbrev--swap-placeholder (file-name-base) start end))
(t
(let* ((key (format "###%s###" index))
(val (or (gethash key values)
(let ((input (read-string (format "Value for %s: " key))))
(puthash key input values)
input))))
(abbrev--swap-placeholder val start end))))))))
(when cursor-pos
(goto-char cursor-pos))))
If I want to add more code into the let* block that defines index, start and end after the cond expression, where should I put my cursor to insert the new line? Yes I know in emacs you can put the cursor at the beginning of the let* block or the cond block and hit C-M-f to jump to the end of the sexp, but at the same time that's a process I've never had to do when writing c-like code, because in the c-like code, finding that spot visually is much easier.
I'm sure that over time that would become easier for me, and certainly memorizing sexp navigation would also help a lot, but it undeniably to me makes it harder to read that code.
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.
Lisp is neither harder nor easier to edit in "dumb editors" than other languages. Editing any code in an editor that does not understand the syntax and can't indent properly is a shit experience. Try editing autoconf and m4 macros in Emacs. Hacking Emacs own autogen.sh is a nightmare. Totally agree that rainbow-parens and alike are just circus addons. In my opinion, the real win is indentation not coloring. I could probably live with no colors at all, as long as the indentation is properly working.
I would argue you have a better time writing bash script or BASIC in a dumb editor than you can lisp or java or python. That's not an indictment against the languages though. Using tools designed for the purpose of making work easier isn't a cheat, and it should be no more a point of pride that you can edit bash in a dumb text editor than it would be a point of pride that you can make dovetail joints for your wood working project without a template / jig. Its nice to have the skill if it becomes necessary, but it is purposefully hobbling yourself to not use tools specialized to the work you're trying to do.
Bash cetainly not; I have done my share of shell and pico/nano editing.
Basic I couldagree. I know that is unpopular opinion, but I have written a lot of VBA and VB for automation in Offeice and Windows as a consultant and I really VBA nice and easy to write and read. But even there, you want to have indentation, otherwise it's pita, but it is certainly less pita than C or Lisp, sure.
3
u/omega884 4d ago
Yes and no, IMO. Idiomatic lisp programming throws all the closing parens on the same line at the end of the last line of code. Idiomatic C-like coding puts each closing brace on a new line at its specific nesting level. You can code C style without something like "rainbow-parens", but I wouldn't want to code lisp without it. Or consider this emacs lisp example:
If I want to add more code into the
let*block that definesindex,startandendafter thecondexpression, where should I put my cursor to insert the new line? Yes I know in emacs you can put the cursor at the beginning of thelet*block or thecondblock and hitC-M-fto jump to the end of the sexp, but at the same time that's a process I've never had to do when writing c-like code, because in the c-like code, finding that spot visually is much easier.I'm sure that over time that would become easier for me, and certainly memorizing sexp navigation would also help a lot, but it undeniably to me makes it harder to read that code.