[fireflies_]

Me too. I can't imagine trying to maintain a project written like this so I'd still consider you a member of the "clever programmer club" in good standing. Ideas like this make sense when the language gives you good support for them like Haskell does:

https://www.haskell.org/tutorial/functions.html

In languages like Go, you'll write much more "composable" software by sticking to what the language gives you instead of trying to force this in.

[karmakaze]

I remember working in a Go codebase and that was littered with functions that take functions returning funtions that take functions, etc. I couldn't imagine what compelled them to write this way. Now I can see that they just realized first-class functions, dependency injection, and maybe an article about currying. There was almost no way to follow the problem decomposition nor execution path as each aspect rather than being dealt with as encountered just got pushed into a more and more complicated function that eventually executed everything when given the input, an http request!

[weberc2]

You see this a lot with HTTP requests. People realize they're often writing the same code over and over and so they pull it out into a middleware of some kind. It's trading off a little readability in exchange for DRYness.

[cousin_it]

I think even in Haskell, function composition is a bit of second class citizen compared to function application, e.g. "foo (bar value)" has fewer tokens than "(foo . bar) value". There are languages based on composition (concatenative) but few people use them.