There's a maximum amount of stuff a single function/code unit can do before becoming unreadable. When writing code, there's a tension between the semantic size

There's a maximum amount of stuff a single function/code unit can do before becoming unreadable. When writing code, there's a tension between the semantic size of the implementation, and the semantic size of the constituent parts of the problem: very few problems are broken down into clean chunks of code. Quite often, when trying to subjugate the problem to the language, you end up with lots of 'features' of the modular parts: lots of parameters, parameters being complex non-data objects, and so forth. Breaking stuff down costs, as well - you have to make it clear how something is going to be used. You might write a helper function for one bit in particular, and then rely on additional levels of abstraction to make it clear how this function should be used. Instead, if you can allow your functions to become semantically larger, you don't need to explain and protect your modularisation. Helper functions with one use are inlined (it's very common that these things have names longer than their definition). Instead of a large tower of abstraction, you just have two levels: the level of the data, and the level of the problem. Your entire program is written as functions, each of which does something in the problem domain, and for each, each definition is immediately clear about what it is doing with the data. There was an article here, a while ago, called 'smaller code, better code', and with accompanying comments, that explain this better than I can.