4 ms·

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

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

saagarjha 6y ago
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?
- lentil 6y ago
  Visual Studio Code has a "peek" operation that does something like this. It is indeed quite handy. https://code.visualstudio.com/docs/editor/editingevolved#_peek https://code.visualstudio.com/docs/editor/editingevolved#_pe...
  - LandR 6y ago
    Available in the full blown Visual Studio as well.
- Quenty 6y ago
  VSCode effectively has this feature.
- jl2718 6y ago
  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.
davethedevguy 6y ago
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.
- baby 6y ago
  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.
- lultimouomo 6y ago
  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'.
cjfd 6y ago
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/ 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.
- anonred 6y ago
  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.
  - johncolanduoni 6y ago
    He even argues for taking minor performance hints if it reduces variations in execution paths.
- smabie 6y ago
  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.
lifthrasiir 6y ago
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.

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

saagarjha 6y ago

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?

lentil 6y ago
Visual Studio Code has a "peek" operation that does something like this. It is indeed quite handy. https://code.visualstudio.com/docs/editor/editingevolved#_peek https://code.visualstudio.com/docs/editor/editingevolved#_pe...
- LandR 6y ago
  Available in the full blown Visual Studio as well.
Quenty 6y ago
VSCode effectively has this feature.
jl2718 6y ago
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.

davethedevguy 6y ago

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.

baby 6y ago
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.
lultimouomo 6y ago
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'.

cjfd 6y ago

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/ 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.

anonred 6y ago
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.
- johncolanduoni 6y ago
  He even argues for taking minor performance hints if it reduces variations in execution paths.
smabie 6y ago
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.

lifthrasiir 6y ago

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.