[lyudmil]

This is a stimulating argument to think about.

One possible counter-argument is that the resulting procedural code is more difficult to unit test. In the video Brian acknowledges that he doesn't think much about cyclomatic complexity, but I think if you were to try to test one of these long functions with a lot of branches, the setup required for each case you want to test would dominate the amount of code devoted to the actual test. The solution to this isn't necessarily OOP, but I would not want to maintain Brian's code as it stands without refactoring it.

The more fundamental problem to me is that Brian's code requires you to read it fully in order to understand it. No part of the code is difficult to understand, but it demands that I understand it in detail before I can have a summary of it in my head. I prefer for code to read more like a newspaper article, where the further down you read, the more detail you're given, but you can stop at any point and have a decent understanding of what's going on. To me this makes it easier to reason about the system as a collection of sub-systems, which is often the level at which the really important decisions are made. Again, OOP isn't the only "solution" for this, but I think it's a good tool. It does have the potential, as Brian points out in one of his earlier videos, of devolving into philosophical exercises, but I don't think that's necessarily a drawback if your goal is to make it easier for humans to comprehend your system. In designing your system this way, you're simply taking advantage of people's natural ability to think in abstractions.

[piokuc]

To me, the idea of inlining functions that are otherwise called only once is complete garbage. Yes, you reduce number of functions in your program but the program doesn't get easier to read, test, develop and maintain as the functions that you leave get longer... I stopped watching when I learned that that's presenter's idea of improving the original program. And it has _nothing_ to do with OOP and its flaws, you could as well "improve" this way well written functional programs... It's just wrong. Inlining functions is something your compiler is supposed to do for the programmer, a programmer is better off breaking his problem into small functions instead.

[marcus_holmes]

I thought it was interesting. I've carried a "no long functions" rule in my head for so long it was really challenging to have that questioned.

I get the logic behind why he likes long functions that have the meat of the program in them. I've hit code bases before that have broken out bits of logic into separate functions that are badly named and defined and I ended up hopping around the program trying to work out wtf is going on.

As long as we keep the subroutines nice and tight and well-named they're an aid to understanding the program: I can guess what `writeTextToFile(text,filename)` does, and I'd rather see that in the main logic routine than 50 lines of the code that writes text to files.

I will carry on writing short functions, but it's good to know that I'm doing that for a reason, having challenged it.

[yoklov]

Here's a fairly well reasoned argument to the contrary: http://number-none.com/blow/john_carmack_on_inlined_code.htm...

It boils down to the fact that it's very easy to have unexpected state dependencies/constraints in those smaller functions, that is non-obvious by just reading them. If they're called when those constraints are not met, it is a bug.

[piokuc]

That's why one should try to make functions pure as much as possible.

[derrickdirge]

I couldn't agree more. When I read your enormous procedures full of inlined functions, I still have to break it down into discrete, logical chunks in my brain. This is work, and there's a real chance I'll get it wrong. If you do it for me, I'm much more likely to understand your program in the way you intended.

[lyudmil]

I agree with you completely and I think this cannot be controversial. If we cannot agree that sort(my_list) is better than its inlined function, our profession truly is at square one.

The interesting part of this is that although you kind of know that positions with as little nuance as Brian's have to be wrong (because the world isn't simple), it's still important to think about why you hold your own positions instead of dismissing any challenge to them outright. I think it's good to think about why we use objects and whether we need to do it as much.

What we especially lack in programming is any evidence for our practices. The best we currently have is opinion and experience. That means a lot, but not as much as empirical evidence, and I think we tend to forget that too often.