While I agree deeply nested calls are bad, I've also had the pleasure of inheriting a an application with several, muti-thousand line functions and those are not fun either.
Couldn't agree with you more. I get the impression that a lot of people in this thread have never worked on behemoth, million-line enterprise code bases. Cognitively speaking, 4 nested thousand-line function calls is equally as bad as 15 nested 10-line function calls.
> In code as in life, all in moderation.
Beautifully said. Both methods (procedural vs. object oriented) give you different ways to shoot yourself in the foot. Instead of picking one or the other, it's more important to manage the scope at which your project grows. You have to avoid falling into the traps of each style.
The worst example of this I ever saw was an old macOS helpdesk application (@1995) that had a 14,000 line main event loop and the entire application was a single 29,000 line C file. Just typing at the bottom of the file was agonizing. We tore the whole thing apart and put it back together as a real app with include files and everything.
Sometimes that is just inherent in the problem. If a a few thousand lines are actually needed to solve the problem, it will be somewhat hard to deal with whether they are all in one big function or broken up into many functions. One option may be marginally less annoying than the other, depending on what you are doing, or preference perhaps.
But sometimes it is just a "Such is life" situation.
I think it depends on whether the problem lends itself to abstraction or not. If I have a problem that requires 1000 lines to solve several large system of linear equations, I'm absolutely going to be separating that out. On the other hand, if I have 1000 lines of "if in country A, apply this tax rate", then I'm not going to separate it, because there is no underlying abstraction to use.
That's actually one of the more reasonable uses for OO; have an interface that defines 'apply_tax_rate', and a bunch of implementations for each, so you only have a single line in your function (instance).apply_tax_rate. Of course, that leads to your actual implementing code being scattered in different classes, and that can be a pain, too.
If a functional language, I'd prefer each being its own function, with the case matching in a single, standalone file that returns the appropriate function based on whatever. That way you still get just apply_tax_rate(type, amount) in your main calculation function.
You are saying something I highly doubt you want to be saying.
My "problem" is an online store. It is about 75,000 lines of code. It needs all 75,000 to solve the problem. What you are saying is that it would be "somewhat" hard to deal with whether it is all in one big function or many functions.
But in reality, one big function would be incomprehensible. It is vastly easier to deal with broken out into many functions.
A problem that genuinely takes a few thousand lines to solve doesn't sound "hard to deal with". It sounds just the right size for a module or tool that solves a problem big enough to be non-trivial, but small enough to be solved well.
However you end up solving it, it is way to big for a single function. On the other hand, a moderate bunch of functions can do it nicely -- and at that scale you don't need big complicated object-oriented abstractions other than the external interface itself.
In code as in life, all in moderation.