John Carmack on inlined code (2014) • Hacker News Board

Re: John Carmack on inlined code (2014)

#21

Post by toenail » Wed, Oct 09, 2024, 7:22 AM UTC

gorgoiler wrote: post #3

> Inlining functions also has the benefit of not making it possible to call the function from other places. I’ve really gone to town with this in Python. def parse_news_email(…): def parse_link(…): … def parse_subjet(…): … … If you are careful, you can rely on the outer function’s variables being available inside the inner functions as well. Something like a logger or a db connection can be passed in once and then us…

> Inlining functions also has the benefit of not making it possible to call the function from other places.

Congrats, you've got an untestable unit.

Re: John Carmack on inlined code (2014)

#22

Post by mihaic » Wed, Oct 09, 2024, 7:28 AM UTC

skummetmaelk wrote: post #15

mihaic wrote: post #2

When I first heard the maxim that an intelligent person should be able to hold two opposing thoughts at the same time, I was naive to think it meant weighing them for pros and cons. Over time I realized that it means balancing contradictory actions, and the main purpose of experience is knowing when to apply each. Concretely related to the topic, I've often found myself inlining short pieces of one-time code that mad…

That doesn't seem like holding two opposing thoughts. Why is balancing contradictory actions to optimize an outcome different to weighing pros and cons?

What I meant to say was that when people encounter contradictory statements like "always inline one-time functions" and "breakdown functions into easy to understand blocks", they try to only pick one single rule, even if they consider the pros and cons of each rule.

After a while they consider both rules as useful, and will move to a more granular case-by-base analysis. Some people get stuck at rule-based thinking though, and they'll even accuse you of being inconsistent if you try to do case-by-case analysis.

Re: John Carmack on inlined code (2014)

#23

Post by dehrmann » Wed, Oct 09, 2024, 7:28 AM UTC

Always read older stuff from Carmack remembering the context. He made a name for himself getting 3D games to run on slow hardware. The standard advice of write for clarity first, make sure algorithms have reasonable runtimes, and look at profiler data if it's slow is all you need 99% of the time.

Re: John Carmack on inlined code (2014)

#24

Post by Netch » Wed, Oct 09, 2024, 7:30 AM UTC

gdiamos wrote: post #5

How much of this is specific to control loops that execute at 60hz?

All the code which is not in hot path may conform to any rules, and typically is designed according to something like SOLID, to make understanding and maintenance as simple as possible (and suitable to any average coder).

All the code which performance, memory cost, etc. is critical, should be adjusted to fit into required confine even if it will violate all other tenets. This often results in combination of opposite approaches - anything that does well.

Finally, one just profiles the code and fixes all most spending paths. This is what now any average programmer can do. What it canʼt do - and what Carmack has been doing for decades - is to predict such places and fixes them proactively at architectural level; and to find tricky solutions that average joe-the-programmer hasnʼt heard ever.

Re: John Carmack on inlined code (2014)

#25

Post by scbrg » Wed, Oct 09, 2024, 7:35 AM UTC

gorgoiler wrote: post #3

> Inlining functions also has the benefit of not making it possible to call the function from other places. I’ve really gone to town with this in Python. def parse_news_email(…): def parse_link(…): … def parse_subjet(…): … … If you are careful, you can rely on the outer function’s variables being available inside the inner functions as well. Something like a logger or a db connection can be passed in once and then us…

Not sure I believe the benefit of this approach outweighs the added difficulty wrt testing, but I certainly agree that Python needs a yikes keyword :-)

Re: John Carmack on inlined code (2014)

#26

Post by Cthulhu_ » Wed, Oct 09, 2024, 7:36 AM UTC

I feel like this style is also encouraged in Go and / or the clean/onion architecture / DDD, to a point, where the core business logic can and should be a string of "do this, then do that, then do that" code. In my own experience I've only had a few opportunities to do so (most of my work is front-end which is a different thing entirely), the one was application initialisation (Create the logger, then connect to the database, then if needed initialize / migrate it, then if needed load test data. Then create the core domain services that uses the database connection. Then create the HTTP handlers that interface with the domain services. Then start the HTTP server. Then listen for an end process command and shut down gracefully), the other was pure business logic (read the database, transform, write to file, but "database" and "file" were abstract concepts that could be swapped out easily). You don't really get that in front-end programming though, it's all event driven etc.

Re: John Carmack on inlined code (2014)

#27

Post by physicles » Wed, Oct 09, 2024, 7:37 AM UTC

dehrmann wrote: post #23

Always read older stuff from Carmack remembering the context. He made a name for himself getting 3D games to run on slow hardware. The standard advice of write for clarity first, make sure algorithms have reasonable runtimes, and look at profiler data if it's slow is all you need 99% of the time.

I agree with this in general, but his essay on functional programming in C++ (linked at the top of the page) is phenomenal and is fantastic general advice when working in any non-functional language.

Re: John Carmack on inlined code (2014)

#28

Post by orwin » Wed, Oct 09, 2024, 7:38 AM UTC

rob74 wrote: post #13

codeflo wrote: post #9

Earlier quoted context omitted.

There’s also the effect that a certain code structure that’s clearer for a senior dev might be less clear for a junior dev and vice versa.

Or rather, senior devs have learned to care more for having clear code rather than (over-)applying principles like DRY, separation of concerns etc., while juniors haven't (yet)...

My 'principle' for DRY is : twice is fine, trice is worth an abstraction (if you think it has a small to moderate chance to happen again). I used to apply it no matter what, soi guess it's progress...

Re: John Carmack on inlined code (2014)

#29

Post by Cthulhu_ » Wed, Oct 09, 2024, 7:41 AM UTC

dehrmann wrote: post #23

Always read older stuff from Carmack remembering the context. He made a name for himself getting 3D games to run on slow hardware. The standard advice of write for clarity first, make sure algorithms have reasonable runtimes, and look at profiler data if it's slow is all you need 99% of the time.

And before that, 2D games (side-scrolling platformers were not a thing on PC hardware until Carmack did it, iirc). I think his main thing is balancing clarity - what happens when and in what order - with maintainability.

Compare this with enterprise software, which is orders of magnitude more complex than video games in terms of business logic (the complexity in video games is in performance optimization), but whose developers tend to add many layers of abstraction and indirection, so the core business process is obfuscated, or there's a billion non-functional side activities also being applied (logging, analytics, etc), again obfuscating the core functionality.

It's fun to go back to more elementary programming things, in e.g. Advent of Code challenges or indeed, game development.

Re: John Carmack on inlined code (2014)

#30

Post by xboxnolifes » Wed, Oct 09, 2024, 7:43 AM UTC

toenail wrote: post #21

gorgoiler wrote: post #3

> Inlining functions also has the benefit of not making it possible to call the function from other places. I’ve really gone to town with this in Python. def parse_news_email(…): def parse_link(…): … def parse_subjet(…): … … If you are careful, you can rely on the outer function’s variables being available inside the inner functions as well. Something like a logger or a db connection can be passed in once and then us…

> Inlining functions also has the benefit of not making it possible to call the function from other places. Congrats, you've got an untestable unit.

The unit here is the email, not the email's link or subjects. Those are implementation details.