> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom.
I do the computation in my head each time I read it. If it is a function I can cache its behavior more easily compared to a well defined block of code. Even if it's never used anywhere else, it's read multiple time, by multiple people. Obviously, it has to make sense from a domain logic perspective, and not be done for the sake of reducing lines of code, but I have yet to see a function/module/file that is justified in being gigantic when approaching it with domain logic reasoning instead of code execution reasoning.
You've mentioned list comprehensions, map, and filter, so I suppose you mostly used these concepts with lists/arrays.
One question you could ask yourself is, how could you reproduce list comprehensions without special syntax ?
Another way to view monads is by following the types. With map, you can chain pure functions from one type to another to be applied on lists (hence the (in -> out) -> ([in] -> [out]) ) . How would you do that chaining with function from one type to another but wrapped in a list ( (in -> [out]) -> ([in] -> [out]) ) ?
Then you can think about how it could be applied to other types than lists, for example, nullable/option types, result types, async/promise types, and more hairy types that implement state, reading from an environment, etc...
Where the head of slides_left is the current slide. Pretty much any recursive data structure can be derived into a zipper.