6 ms·

All Lisp indentation schemes are ugly

117 points by birdculture 2y ago

phoe-krk 2y ago
> Common Lisp in particular is extremely unfriendly to threading macros. Arrows imply a consistent thread-first or thread-last functions. But CL's standard lib is too inconsistent for that to work. So we're left with picking an indentation style we don't necessarily like. Diamond arrows exist, you know. (-<> foo bar (baz) (quux 1 2 3) (fred 4 5 6 <>) (frob 7 <> 8 <> 9)) All in all, this post reads like a rant, and I realized that upon reading "now what I'm about to suggest is likely not to your taste". That style of indentation is something I use often when writing calls to long-named functions like COMPUTE-APPLICABLE-METHODS and I haven't ever thought of it being not to my taste, or even of it being ugly as the author suggests.
- aartaka 2y ago
  Well, it's all based on my experience. In two Lisp companies I worked in, colleagues complained or even were trying to fix how I indent things. So it's not just some anxiety whatever, it's experience that needs explanation and justification. I'm aware of arrow-macros/diamond wands, and am using them myself. But I often have to write dependency-less libraries for moderately complicated algos, and that's where indentation style is the only thing I can rely on.
stevebmark 2y ago
Lisp is an objectively goofy language,* I appreciate someone pointing out the pain points around trying to cobble together readability via indentation. * Not a bad language - well, maybe bad by today's standards, but undeniably a very important language - just goofy
- deleted 2y ago
  [deleted]
- bcrosby95 2y ago
  What languages do you use are readable without indentation? I guess other than Python, where indentation actually contributes towards correctness rather than it just being optional.
  - cb321 2y ago
    Well, there is also https://nim-lang.org https://nim-lang.org as well as a pretty big list at https://en.wikipedia.org/wiki/Off-side_rule https://en.wikipedia.org/wiki/Off-side_rule . Just expanding, not trying to invalidate your valid question!
  - shawn_w 2y ago
    APL? (For certain values of readable)
    - aartaka 2y ago
      But well, it's actually the most readable and meaningful language... to APL programmers.
behnamoh 2y ago
> (tree-transform-if predicate > transformer > (second tree) > depth) > A problematic function indentation > Nineteen! Nineteen spaces of indentation! It's getting unruly. Such an indent, when used in deeply nested code, makes it too wide and unreadable. If you add the strict one-per-line alignment of arguments, it's also painfully long line-wise. I think this is more a problem with languages that encourage (or don't discourage) deeply nested function calls. I face the same issue in Python, although Python kinda discourages me to do: foo( bar( baz( far( faz(...))))) Instead, Python and Pythonic idioms encourage a "step by step" approach: a = faz(...) b = far(a) ... I don't know which is "better"—the first approach requires thinking ahead about the chain of functions we're about to call while the second one is more like a gradual development of the solution, albeit being more verbose than the former.
- phoe-krk 2y ago
  You can have the same step-by-step in Lisp via LET*. The problem outlined by the author happens when you have a function call where 1) the operator has a long name, 2) there are many arguments. The TREE-TRANSFORM-IF is such a case and you can't solve it by just "going step by step".
  - behnamoh 2y ago
    Yes, I think for whatever reason, Lisp languages tend to use long names for funcs and vars whereas Haskell and other FP languages prefer symbols like >>=, <$>, etc. Personally, I prefer somewhere in the middle. > The TREE-TRANSFORM-IF is such a case and you can't solve it by just "going step by step". Yes, this is a good point.
  - skydhash 2y ago
    Why not just locally bind it to something shorter with let? Lisp is flexible enough that this is a non issue.
    - phoe-krk 2y ago
swayvil 2y ago
Surely one could do it with different background colors instead. Any examples of that?
- el_memorioso 2y ago
  For matching parentheses, Emacs users can use a package called rainbow-delimiters that colors matching delimiters. Different levels of enclosure use different colors. I've found this to be too much visual noise -- I am usually just interested on the delimiters for the current s-expressions. In this vein, having multiple different colored backgrounds would be garish and distracting for me.
- tmtvl 2y ago
  I have seen it done with foreground colours: https://github.com/alphapapa/prism.el https://github.com/alphapapa/prism.el I think I once saw a project turning Scheme into a visual block-based representation, but I can't find it again.
agumonkey 2y ago
never had any real issue using emacs indentation engine (not even sure lisp modes use smie..)
lihaoyi 2y ago
This post misses the IMO best indentation scheme for lisp, which I used for my college class where we had to use MIT scheme: (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 ) It may not be densest or most compact indentation scheme, but damn is it readable for someone without a lisp/scheme background!
- rayiner 2y ago
  That is blasphemy.
  - DonHopkins 2y ago
    Nicely indented easy to read blasphemy is the most dangerous kind!
  - shawn_w 2y ago
    The uncuddled closing parens are a sure sign of a sick mind; probably corrupted by C or the like.
    - andriamanitra 2y ago
      They make line-by-line diffs nicer. And it's quite nice to be able to swap/move lines without messing up the closing paren, especially when not using a structural editor.
    - varjag 2y ago
      To be fair in C they don't put semicolon on its own line either.
fn-mote 2y ago
I love a Lisp-themed article, but this is such a yawn in 2025. It seems pretty clear that a threading macro which allows the user to place the "hole" being filled wherever they want is the answer. Example: cl-arrows https://github.com/nightfly19/cl-arrows?tab=readme-ov-file https://github.com/nightfly19/cl-arrows?tab=readme-ov-file
lincpa 2y ago
[dead]
kazinator 2y ago
I just skipped to the bottom of this crap to find the real gem: it's produced with the help of ed. Yeah, someone working with ed its not going to like 19 repeated leading spaces across lines for vertical alignment. They will like that less than even somebody working with Notepad.
- juped 2y ago
  ...the author is using ed scripts as a static site generator, in a way completely unrelated to the post content. People are allowed to do oddball things.
  - kazinator 2y ago
    Oddball things lead to oddball opinions. Like: you have to go to the monstrous effort of repeating nineteen spaces into the next line again and again to achieve this aligned appearance, therefore it looks ugly.
    - aartaka 2y ago
      That's one way to think of it.
RedNifre 2y ago
Are there any formatters that detect related things and put them in the same column? Here's a Pie example: (claim Tuple3 (-> U U U U)) (define Tuple3 (lambda ( a b c ) (Pair a (Pair b c) ))) (claim tuple3Of (Pi ( (A U) (B U) (C U)) (-> A B C (Tuple3 A B C )))) (define tuple3Of (lambda ( A B C ) (lambda ( a b c ) (the (Tuple3 A B C ) (cons a (cons b c)) )))) (claim Tuple5 (-> U U U U U U)) (define Tuple5 (lambda ( a b c d e ) (Pair a (Pair b (Pair c (Pair d e)))))) (claim tuple5Of (Pi ((A U) (B U) (C U) (D U) (E U)) (-> A B C D E (Tuple5 A B C D E )))) (define tuple5Of (lambda ( A B C D E ) (lambda ( a b c d e ) (the (Tuple5 A B C D E ) (cons a (cons b (cons c (cons d e))))))))
wegfawefgawefg 2y ago
idk i always just put a newline before every single open parens and that worked for me
kleiba 2y ago
(tree-transform-if predicate transformer (second tree) depth) > A problematic function indentation > Nineteen! Nineteen spaces of indentation! It's getting unruly. Why, is there a shortage of whitespace these days?? > Such an indent, when used in deeply nested code, makes it too wide and unreadable. Ah, I see! Well, I would argue the problem is not the indentation style. What makes your code unreadable is that it's too deply nested, and I would bet that no indentation style can help with that.
- aartaka 2y ago
  That's a point too!
lgrapenthin 2y ago
> Once you get used to Lisp, you stop noticing the parentheses and rely on indentation instead. Who does that? LISP has a datastructured syntax, textformat has no meaning in it.
- aartaka 2y ago
  Humans read code. I'd like to become a machine someday, but alas, I still am human and I need to read mine/others' code. Lisp code too.
kazinator 2y ago
It's clear that the blogger is a wide-eyed newbie, who is enamored of Lisp and trying to attract any kind of attention and clicks to it. Obviously, it worked; he got on the front page of HN. I predict that in another five years, he will write an article disparaging Lisp and purge it from his CV, and that will be that.
- aartaka 2y ago
  I literally program in Lisp for five years now, and I ain't going anywhere.

117 points by birdculture 2y ago

> Common Lisp in particular is extremely unfriendly to threading macros. Arrows imply a consistent thread-first or thread-last functions. But CL's standard lib is too inconsistent for that to work. So we're left with picking an indentation style we don't necessarily like. Diamond arrows exist, you know. (-<> foo bar (baz) (quux 1 2 3) (fred 4 5 6 <>) (frob 7 <> 8 <> 9)) All in all, this post reads like a rant, and I realized that upon reading "now what I'm about to suggest is likely not to your taste". That style of indentation is something I use often when writing calls to long-named functions like COMPUTE-APPLICABLE-METHODS and I haven't ever thought of it being not to my taste, or even of it being ugly as the author suggests.

aartaka 2y ago
Well, it's all based on my experience. In two Lisp companies I worked in, colleagues complained or even were trying to fix how I indent things. So it's not just some anxiety whatever, it's experience that needs explanation and justification. I'm aware of arrow-macros/diamond wands, and am using them myself. But I often have to write dependency-less libraries for moderately complicated algos, and that's where indentation style is the only thing I can rely on.

stevebmark 2y ago

Lisp is an objectively goofy language,* I appreciate someone pointing out the pain points around trying to cobble together readability via indentation. * Not a bad language - well, maybe bad by today's standards, but undeniably a very important language - just goofy

deleted 2y ago
[deleted]
bcrosby95 2y ago
What languages do you use are readable without indentation? I guess other than Python, where indentation actually contributes towards correctness rather than it just being optional.
- cb321 2y ago
  Well, there is also https://nim-lang.org https://nim-lang.org as well as a pretty big list at https://en.wikipedia.org/wiki/Off-side_rule https://en.wikipedia.org/wiki/Off-side_rule . Just expanding, not trying to invalidate your valid question!
- shawn_w 2y ago
  APL? (For certain values of readable)
  - aartaka 2y ago
    But well, it's actually the most readable and meaningful language... to APL programmers.

behnamoh 2y ago

> (tree-transform-if predicate > transformer > (second tree) > depth) > A problematic function indentation > Nineteen! Nineteen spaces of indentation! It's getting unruly. Such an indent, when used in deeply nested code, makes it too wide and unreadable. If you add the strict one-per-line alignment of arguments, it's also painfully long line-wise. I think this is more a problem with languages that encourage (or don't discourage) deeply nested function calls. I face the same issue in Python, although Python kinda discourages me to do: foo( bar( baz( far( faz(...))))) Instead, Python and Pythonic idioms encourage a "step by step" approach: a = faz(...) b = far(a) ... I don't know which is "better"—the first approach requires thinking ahead about the chain of functions we're about to call while the second one is more like a gradual development of the solution, albeit being more verbose than the former.

phoe-krk 2y ago
You can have the same step-by-step in Lisp via LET*. The problem outlined by the author happens when you have a function call where 1) the operator has a long name, 2) there are many arguments. The TREE-TRANSFORM-IF is such a case and you can't solve it by just "going step by step".
- behnamoh 2y ago
  Yes, I think for whatever reason, Lisp languages tend to use long names for funcs and vars whereas Haskell and other FP languages prefer symbols like >>=, <$>, etc. Personally, I prefer somewhere in the middle. > The TREE-TRANSFORM-IF is such a case and you can't solve it by just "going step by step". Yes, this is a good point.
- skydhash 2y ago
  Why not just locally bind it to something shorter with let? Lisp is flexible enough that this is a non issue.
  - phoe-krk 2y ago

swayvil 2y ago

Surely one could do it with different background colors instead. Any examples of that?

el_memorioso 2y ago
For matching parentheses, Emacs users can use a package called rainbow-delimiters that colors matching delimiters. Different levels of enclosure use different colors. I've found this to be too much visual noise -- I am usually just interested on the delimiters for the current s-expressions. In this vein, having multiple different colored backgrounds would be garish and distracting for me.
tmtvl 2y ago
I have seen it done with foreground colours: https://github.com/alphapapa/prism.el https://github.com/alphapapa/prism.el I think I once saw a project turning Scheme into a visual block-based representation, but I can't find it again.

agumonkey 2y ago

never had any real issue using emacs indentation engine (not even sure lisp modes use smie..)

lihaoyi 2y ago

This post misses the IMO best indentation scheme for lisp, which I used for my college class where we had to use MIT scheme: (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 ) It may not be densest or most compact indentation scheme, but damn is it readable for someone without a lisp/scheme background!

rayiner 2y ago
That is blasphemy.
- DonHopkins 2y ago
  Nicely indented easy to read blasphemy is the most dangerous kind!
- shawn_w 2y ago
  The uncuddled closing parens are a sure sign of a sick mind; probably corrupted by C or the like.
  - andriamanitra 2y ago
    They make line-by-line diffs nicer. And it's quite nice to be able to swap/move lines without messing up the closing paren, especially when not using a structural editor.
  - varjag 2y ago
    To be fair in C they don't put semicolon on its own line either.

fn-mote 2y ago

I love a Lisp-themed article, but this is such a yawn in 2025. It seems pretty clear that a threading macro which allows the user to place the "hole" being filled wherever they want is the answer. Example: cl-arrows https://github.com/nightfly19/cl-arrows?tab=readme-ov-file https://github.com/nightfly19/cl-arrows?tab=readme-ov-file

lincpa 2y ago

[dead]

kazinator 2y ago

I just skipped to the bottom of this crap to find the real gem: it's produced with the help of ed. Yeah, someone working with ed its not going to like 19 repeated leading spaces across lines for vertical alignment. They will like that less than even somebody working with Notepad.

juped 2y ago
...the author is using ed scripts as a static site generator, in a way completely unrelated to the post content. People are allowed to do oddball things.
- kazinator 2y ago
  Oddball things lead to oddball opinions. Like: you have to go to the monstrous effort of repeating nineteen spaces into the next line again and again to achieve this aligned appearance, therefore it looks ugly.
  - aartaka 2y ago
    That's one way to think of it.

RedNifre 2y ago

Are there any formatters that detect related things and put them in the same column? Here's a Pie example: (claim Tuple3 (-> U U U U)) (define Tuple3 (lambda ( a b c ) (Pair a (Pair b c) ))) (claim tuple3Of (Pi ( (A U) (B U) (C U)) (-> A B C (Tuple3 A B C )))) (define tuple3Of (lambda ( A B C ) (lambda ( a b c ) (the (Tuple3 A B C ) (cons a (cons b c)) )))) (claim Tuple5 (-> U U U U U U)) (define Tuple5 (lambda ( a b c d e ) (Pair a (Pair b (Pair c (Pair d e)))))) (claim tuple5Of (Pi ((A U) (B U) (C U) (D U) (E U)) (-> A B C D E (Tuple5 A B C D E )))) (define tuple5Of (lambda ( A B C D E ) (lambda ( a b c d e ) (the (Tuple5 A B C D E ) (cons a (cons b (cons c (cons d e))))))))

wegfawefgawefg 2y ago

idk i always just put a newline before every single open parens and that worked for me

kleiba 2y ago

(tree-transform-if predicate transformer (second tree) depth) > A problematic function indentation > Nineteen! Nineteen spaces of indentation! It's getting unruly. Why, is there a shortage of whitespace these days?? > Such an indent, when used in deeply nested code, makes it too wide and unreadable. Ah, I see! Well, I would argue the problem is not the indentation style. What makes your code unreadable is that it's too deply nested, and I would bet that no indentation style can help with that.

aartaka 2y ago
That's a point too!

lgrapenthin 2y ago

> Once you get used to Lisp, you stop noticing the parentheses and rely on indentation instead. Who does that? LISP has a datastructured syntax, textformat has no meaning in it.

aartaka 2y ago
Humans read code. I'd like to become a machine someday, but alas, I still am human and I need to read mine/others' code. Lisp code too.

kazinator 2y ago

It's clear that the blogger is a wide-eyed newbie, who is enamored of Lisp and trying to attract any kind of attention and clicks to it. Obviously, it worked; he got on the front page of HN. I predict that in another five years, he will write an article disparaging Lisp and purge it from his CV, and that will be that.

aartaka 2y ago
I literally program in Lisp for five years now, and I ain't going anywhere.