I indeed searched for the longest chain. Something that happens in 4.5k lines twice is hardly rare. And even if you take away a brace it occurs even more frequently.
And yes your example is better, but still terrible. The point is not the formatting. The point is that there is that 10 deep nested code is just not easy to understand. I would also say a line of c/python that does 10 nested function calls as unreadable. But they do not encourage this, whereas with lisp its modus operandi to write such incantation.
> Something that happens in 4.5k lines twice is hardly rare.
Provided you don't consider the context, sure. One of them is software with buggy tests, the other is one that provides a custom test suite that basically has to be reimplemented in the package definition. How often do you think either of those things happen?
Looking at a lot of nix package expression: Quite a bit. Besides, just taking a way a single brace gives 7 hits. Still a ridiculous level of nesting. So I don't go with your reasoning that these are some kind of super special cases. If something happens so often in 4500 lines of code you cease the right to claim it is special.
It happens 1/2290 (0.04%) of the time. You are significantly more likely to guess a stranger's birthday totally at random (0.27%) twice in a row (0.07%). If you don't consider that exceedingly rare, then you and I need to hit up Vegas immediately.
You are projecting a programming style onto Lisps that's quite alien to them. Lisps tend towards small, discrete functions that are composed together. It is the ordinary languages that tend towards deep branching and nesting; Lisps generally favour recursion and function composition instead.
There are 101 `(package` definitions and 58 out of them have more than 6 nest level, which I would consider more than excessive. That's an incidence of over 50%.
Beside I don't think I'm alien to the functional way of writing things. I write mostly Haskell professionally. But Haskell doesn't casually suffer from making insane expression nesting the default.
You may not be a stranger to the functional style, but you do seem a stranger to the Lisp style, which is closely allied. A lot of FP originated in Schemes and Lisps - Haskell is greatly influenced by the ML family, which is itself greatly influenced by Lisp. Modern FP is a style that would be recognisable to a Lisp programmer fifty years ago, when everyone else was writing imperative soup.
I don't think there's much anyone can say that's going to change your mind. You're strongly coming off as though you've formed a view, based on little experience, and will now Ctrl-F cherry-picked examples to sustain it rather than listen to any contrary information. I respectfully suggest greater open-mindedness and a willingness to reserve conclusions in the absence of data.
I personally don't use Lisp too much, so I'm not particularly invested in this exchange, but I know from experience it's not even remotely what you're describing it as. Everything about Lisps tends towards minimal nesting, from the use of paredit to edit expressions through REPL-based workflows.
The only thing this exchange has done, as someone who programs in FP exclusively, is make me reminisce about and yearn for Lisp. It's a wonderful language for FP.
And yes your example is better, but still terrible. The point is not the formatting. The point is that there is that 10 deep nested code is just not easy to understand. I would also say a line of c/python that does 10 nested function calls as unreadable. But they do not encourage this, whereas with lisp its modus operandi to write such incantation.