4 ms·

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

by 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.
- cjfd 6y ago
  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.

by cjfd 6y ago

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.

cjfd 6y ago
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.