Hacker News Reader

Comment by lultimouomo | Hacker News Reader

Pretty much the opposite advice than http://number-none.com/blow/john_carmack_on_inlined_code.htm...

Blog post author here.

I'm certainly not qualified to disagree with John Carmack! I can speak for my own experience, however.

I understand the argument that moving small sections of code into methods/functions hides the details. However, I probably spend more time reading code than writing it. When I'm in 'reading mode', I really just want to understand the control flow; I want the details to be hidden from me.

If I'm debugging code, or looking for performance improvements, then I do need to see that complexity. More function/method calls will make this slightly harder for me, but it's a trade-off I'm willing to make for the more common case, I think.

I too spend more time reading code than writing, if you have to click through X layers of abstractions to understand something you’re doomed. Clarity must stem from the code, and comments are here to support it.

I think the main argument is the same as other comments pointed out: by factoring out code to separate functions, either they're functionally pure (and this is often hard to do, so much that none of your example functions were) or they're mutating state, which is something you want to have very clearly under your eyes, especially when you're in 'reading mode'.

Well, John Carmack is in game programming. That is quite a different field where performance is of supreme importance. I might imagine that things are different there, although I cannot claim to know because I do not work in game programming. For 'normal' programming where performance is not the thing one should primarily be worrying about the OP is correct. He is also not the first one to make this observation. E.g., many years ago I read https://blogs.agilefaqs.com/2009/08/19/are-comments-evil/ . What is written in the OP really should be common knowledge with the provision that perhaps it might not apply in game programming.

From the linked article:

>In no way, shape, or form am I making a case that avoiding function calls alone directly helps performance.

Carmack argues that inlining (small) functions can reduce bugs in handling state by making the logic easier to follow and eliminating any possibility of others calling intermediary functions.

He even argues for taking minor performance hints if it reduces variations in execution paths.

Carmack isn't saying you should do it for performance reasons, he's saying you should inline code and eschew abstractions because it makes code better. I tend to agree.

I personally think that almost all the abstractions we use are totally unnecessary and we should instead just code the solution top to bottom. This works especially well in array languages, when the name of a user defined function might very well be 2 times longer than the function itself. For example, no need to ever define a function called "flatten" to flatten a list if I can instead just write ",/".

Moreover, function definitions are bad because they wipe your working memory. It's better if everything is packed together, ideally as densely as possible.

If we did things differently, it would entirely be possible for an entire 5 man team's code output for the year be 1-10 pages of code. And it would do 10000x what the blub languages we use today do.

1 - 10 pages? In what font size? Are powers of 10 in the point size of a font a thing?

Seriously, though, I have seen these 'just code the solution top to bottom' go horribly awry. Like when it produces a multi-thousands of lines function where indentation is about 7 levels deep with lots of nested switch/case and so on. These things can become completely unreadable and unmaintainable. The danger of code duplication always was and still is that at some point something needs to be changed and it needs to be changed in 100 places. And then the various places where the duplication occurs start to diverge and things become truly unmaintainable.

I’m curious if anyone has tried some sort of editor plugin that, instead of doing something like “go to function” when you encounter a call, instead temporarily inlines the code into what you’re reading so you’re not jumping around. Seems like this might be the best of both worlds, with abstractions hidden but instantly available to scrutinize when necessary?

Visual Studio Code has a "peek" operation that does something like this. It is indeed quite handy.

https://code.visualstudio.com/docs/editor/editingevolved#_pe...

Available in the full blown Visual Studio as well.

VSCode effectively has this feature.

I would like to see this in a debugger especially. One continuous scroll of code with no separation of stack frames.

I would also like to see unit tests unrolled like this for code reviews so others can actually follow the code. This would fight the tendency to accept highly abstract code just because nobody understands it.

I believe that John Carmack's argument considers both the semantics of code and reality of programming languages (here, C/C++), while the OP only considers the former. Ideally naming things without any additional problem (for example, as others noted, extracting a block of code into the global scope violates referential transparency) should be easy, but many languages don't. Carmack is using a comment as a means to give a name without introducing unwanted abstractions.

Reply on news.ycombinator.com