Well, I agree that naming is a problem, but let's put that aside for this discussion. However, I should have explained that I consider all identifiers to have the same length for the purpose of trying to make the representation of program "compact". So what matters is number of functions being called inside a function (in FP, even constants are considered a function).
OK, I get your point about coupling. But I am not sure why you consider high coupling to be a bad thing, especially in case where you have an automated refactoring system.
It seems to me that to "decrease coupling" you have to add nodes to dependency graph, and this increases overall complexity.
Perhaps you could provide some example where high coupling (calling different functions from a single function) is bad, and how would you like to have it resolved.
Update: Actually, with automated refactoring, you wouldn't have to modify any existing functions (except maybe to call your new functions). You would just write new functions that would incorporate the new functionality using perhaps the existing building blocks. Then the refactorer would sort out things in DRY manner, as needed. So you don't need to care if the code is easy to refactor, it just needs to be easy to read.
I can see why you intuitively think that's the case, but is it really?
I don't understand how you imagine you can "isolate code" while making it less DRY. If I need to do certain functionality from some function, I need either to call other function to do it (if you already have a function that can do it) or copy that functionality into the function itself. The first approach is DRY, the second isn't. But I don't think second approach is a good idea, like, at all. So if I assume you don't mean that, what do you mean?
I can understand you can make code easier to test if you make it less DRY. Let's put that aside, because it's not really a big deal in this discussion. But the other three - I would love to see some specific example where making code less DRY will increase ease to understand it, and also possibly replace it and re-use it (provided we don't care about elegance of the result, since it would be taken care of by subsequent refactoring, as I already explained, so we can for instance copy-paste the existing code for the purpose of change).
OK, I get your point about coupling. But I am not sure why you consider high coupling to be a bad thing, especially in case where you have an automated refactoring system.
It seems to me that to "decrease coupling" you have to add nodes to dependency graph, and this increases overall complexity.
Perhaps you could provide some example where high coupling (calling different functions from a single function) is bad, and how would you like to have it resolved.
Update: Actually, with automated refactoring, you wouldn't have to modify any existing functions (except maybe to call your new functions). You would just write new functions that would incorporate the new functionality using perhaps the existing building blocks. Then the refactorer would sort out things in DRY manner, as needed. So you don't need to care if the code is easy to refactor, it just needs to be easy to read.