Some time ago parinfer (https://news.ycombinator.com/item?id=42766205) took some attention as a more pythonesque approach to matching presentation and meaning. I liked it, but it seems that it didn’t catch on, alas.
How do you know it didn't catch on? It depends on Lisp! The fraction of programmers using parinfer is bounded by the fraction of Lisp programmers. (I think I might have seen some fledgling experiment with parinfer for other languages, though.)
I'm highly resistant to novelty in this area, yet even I am using parinfer. A crappy implementation in Vim, at that, which only works in One direction: indent -> parens, and can get into an infinite loop fighting with Vim's undo.
Not your fault, but I think it's such a silly argument.
About 90% of my problems arise when I shift the parens, e.g. going from `(+ (1 2))` to `(+ (+ 1 2) 3)` or the other way round - and if there is now ) or )) at the very end (but more likely at 4+, not 1 or 2.
How would any plugin know what I mean here? (I know + is a bad example as its commutative...).
Paredit has lots of great ways to do that sort of thing, though, while keeping things balanced. In emacs with paredit, providing a prefix argument to open paren lets you surround n sexps in the new parens. There's also slurp and barf to move sexps in and out of parens.
Editing for lisp mirrors the language as a whole in that there's a learning curve, but once you've climbed it, it's a joy to work with. Because the syntax is so uniform, all you need is a handful of extensions/commands for full blown structural editing.
I get by splendidly in emacs with nothing but paredit and convenient keybindings(not a huge fan of paredit defaults).
One webserver framework, Axum, has the trait IntoResponse which is returned by something that implements Handler. A lot of things implement IntoResponse and/or Handler. In plain English you have handlers, these are parts of code that get selectively invoked for a request. The handlers return data that can be made into responses. It's powerful, but if something doesn't fit exactly, the Rust compiler throws gibberish errors at you. It's finnicky as hell.
But once you have written something that works, it is beautiful to read.
So it's difficult to write such code, and if it's easy for you then it's because you mastered the art.
If you're not used to the language, the conceptual models of the codebase you are working on, or you're working with obfuscated code. Otherwise it should be much faster to read and understand the code somebody else wrote than to write it from scratch?
I can certainly think of examples where reading code is harder than writing it, but given that much of my professional role has been dissecting the horrible code written by other people in order to figure out not only what it does, but also what it was supposed to do, I simply disagree. Reading code is just more boring than writing it.