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

Re: John Carmack on inlined code (2014)

#31

Post by JauntyHatAngle » Wed, Oct 09, 2024, 7:44 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)...

I know it's overused, but I do find myself saying YAGNI to my junior devs more and more often, as I find they go off on a quest for the perfect abstraction and spend days yak shaving as a result.

Re: John Carmack on inlined code (2014)

#32

Post by jeltz » Wed, Oct 09, 2024, 7:52 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.

Which is usually a positive. Testing tiny subunits usually just makes refactoring and adding new features hard while not improving test quality.

Re: John Carmack on inlined code (2014)

#33

Post by ninetyninenine » Wed, Oct 09, 2024, 7:52 AM UTC

His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him during IO or state changes which he does as minimally as possible and segregates this from his core logic.

Pure functional programming is the bigger insight here that most programmers will just never understand why there's a benefit there. In fact most programmers don't even completely understand what FP is. To most people FP is just a bunch of functional patterns like map, reduce, filter, etc. They never grasp the true nature of "purity" in functional programming.

You see this lack of insight in this thread. Most responders literally ignore the fact that Carmack called his email completely outdated and that he mostly does pure FP now.

Re: John Carmack on inlined code (2014)

#34

Post by nicolaslegland » Wed, Oct 09, 2024, 7:53 AM UTC

physicles wrote: post #27

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.

Link at the top of the page broken, found an archived version at https://web.archive.org/web/20120501221535/http://gamasutra....

Re: John Carmack on inlined code (2014)

#35

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

lloeki wrote: post #8

gdiamos wrote: post #5

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

None. > The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out…

Thing is, a lot of developers see long code and think "this is a Bad Thing" because of dogma, but in practice, a lot of developers never actually wrote anything nontrivial like that.

Re: John Carmack on inlined code (2014)

#36

Post by [deleted] » Wed, Oct 09, 2024, 7:59 AM UTC

ninetyninenine wrote: post #33

His overall solution highlighted in the intro is that he's moved on from inlining and now does pure functional programming. Inlining is only relevant for him during IO or state changes which he does as minimally as possible and segregates this from his core logic. Pure functional programming is the bigger insight here that most programmers will just never understand why there's a benefit there. In fact most programme…

[deleted]

Re: John Carmack on inlined code (2014)

#37

Post by randomtoast » Wed, Oct 09, 2024, 7:59 AM UTC

My browser says "The connection to number-none.com is not secure". Guess it is only a matter of time until HTTPS becomes mandatory.

Re: John Carmack on inlined code (2014)

#38

Post by whstl » Wed, Oct 09, 2024, 8:00 AM UTC

orwin wrote: post #28

rob74 wrote: post #13

Earlier quoted context omitted.

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

I really dislike how this principle ends up being used in practice.

A good abstraction that makes actual sense is perfectly good even when it's used only once.

On the other hand, the idea of deduplicating code by creating an indirection is often not worth it for long-term maintenance, and is precisely the kind of thing that will cause maintenance headaches and anti-patterns.

For example: don't mix file system or low-level database access with your business code, just create a proper abstraction. But deduplicating very small fragments of same-abstraction-level can have detrimental effects in the long run.

Re: John Carmack on inlined code (2014)

#39

Post by whstl » Wed, Oct 09, 2024, 8:02 AM UTC

kolinko wrote: post #18

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.

I bumped into that issue, and it caused a lot of friction between me and 3 young developers I had to manage. Ideas on how to overcome that?

Teaching.

I had this problem with an overzealous junior developer and the solution was showing some different perspectives. For example John Ousterhout's A Philosophy of Software Design.

Re: John Carmack on inlined code (2014)

#40

Post by xxs » Wed, Oct 09, 2024, 8:02 AM UTC

Cthulhu_ wrote: post #26

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…

> the one was application initialisation

...and then you want to parallelize as much as possible to allow for fast boot times which helps the development process immensely.

One of the things I've learned is that optimizing for developer quality of life is one of the best approaches when it comes to correctness and performance. Then, the developers would be able to run multiple iterations of the real thing.