This is interesting. Something I long wondered about Lisp code, was how having glyphs that are angled (parenthesis) without much indentation in many cases might be difficult to read just because of the visual aspects of it.
Lisp code is an AST. Once that's internalized, the parenthesis fade in the background. Mentally, instead of editing code, you're just arranging the branches. So, when reading, you can usually ignore whole sections as they will evaluate to a single value (side effects are possible, but strongly discouraged)
Having 4 spaces as indentation helps people tease out where the branches even are in languages like C or Python or whatever, rather than the 1 or 2 that you see with a lot of Lisp. And those angled parents make lining things up vertically a teeny bit more difficult.
Two space indentation is fairly common in C code bases.
GNU projects use a kind of hybrid indentation where child statement are indented by two spaces, but if they are compound statements the indent their interior by another two spaces:
if (proprietary(program))
roll_on_floor_twitching(stallman);
else
{
calm_down(stallman);
make_indent_weirdly(stallman, everyone);
}
Google’s style guides for various "C likes" also recommend two space tabs.
If you've been staring at Linux kernel code for weeks, with its 8 space tabs, and the edit two-space-tab code, it will take getting used to at first. The indentation will seem small. Soon, it will expand in your mind's eye and look large.
The one issue with procedural is all the temporary variables and the fact that the variables themselves are intertwined with function calls. With Lisp, the whole branch is self-sufficient. It's a different reading method. Just like reading Prolog requires a different strategy.
This is simply a false generalization about a whole family that in its broadest interpretation includes completely different languages, most of them multi-paradigm.
This, and the prefix nature of operators. That's the primary reason every time I try to give Lisp a chance, I get turned off by the maze of parens that I have to unravel in my head, especially for long, nested calls.
For Lispers, good for them on knowing how to wire their brains to read this effortlessly. For the rest of us, there's a reason why Python's syntax is so easy to read for most people.
Yeah it helps if it is properly formatted and intended to be easy to read. Style takes effort. A lot of us let emacs handle the formatting - auto indent and something like paredit to move lists around. Once you get a feel for how the tools move things it is a bit easier to predict, but even then it takes someone putting in effort to make it maximally readable.
