[davvid]

> This post misses the IMO best indentation scheme for lisp [...]

Likewise, a lispier(?) and more compact compromise?:

    (define (match:element variable restrictions)
        (define (ok? datum)
            (every 
                (lambda (restriction)
                    (restriction datum))
                restrictions))
        (define (element-match data dictionary succeed)
            (and 
                (ok? data)
                (let ((vcell (match:lookup variable dictionary)))
                    (if vcell
                        (and 
                            (equal? (match:value vcell) data)
                            (succeed dictionary))
                        (succeed (match:bind variable data dictionary))))))
        element-match)

[nine_k]

It becomes much harder to notice if you have closed all the right matching parens, and hence where a token after the closing paren belongs. When the closing paren is exactly below the opening paren, on the same column, it becomes much easier to see the structure. It's a very good thing for students who just learn Lisp.

[ludston]

But all the cool kids are using paredit or parinfer which means you don't actually ever write the closing parens yourself.

Counting parens is silly when the editor can do it for you.

[davvid]

Likewise, it's better to optimize for experienced readers than it is to optimize for students.

[harperlee]

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.

[kazinator]

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.

[harperlee]

Well from what I see on the emacs corners of the internet, not so much discussion.

Also I recently read on an HN thread I started: it was taken out of Calva due to bugs no one fixed.

[NikkiA]

More specifically, everyone is using some variant of rainbow-parens

[wink]

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...).

[mtlmtlmtlmtl]

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).

[ludston]

You need to clarify your example, because it appears that you are inserting `+` and `3` between existing parens rather than shifting them.

But regardless, I think the answer you are looking for is:

Some of the coolest kids of all use rainbow delimiters so that they can easily identify the matching closing paren with their eyes!

[wink]

I tried, I'd need to crank the font size up to 14+ to discern the difference ;)

[nine_k]

Writing code is usually easier than reading!

[_nalply]

In Rust I came to the opposite conclusion.

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.

[ludston]

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?

[nine_k]

No, I mean, in general, including languages which I work with for 20-25 years. Reading code is still harder than writing.

[ludston]

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.

[johnisgood]

Exactly.