Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

John Carmack on inlined code (2014)

number-none.com

Post reply on HN
Print view View original

81–90 of 402 posts

Re: John Carmack on inlined code (2014)

#81

Post by peepee1982 »

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's exactly what I try to do. I think it's an unpopular opinion though, because there are no strict rules that can be applied, unlike with pure ideologies. You have to go by feel and make continuous adjustments, and there's no way to know if you did the right thing or not, because not only do different human minds have different limits, but different challenges don't tax every human mind to the same proportional extent.

I get the impressions that programmers don't like ambiguity in general, let alone in things they have to confront in real life.

Re: John Carmack on inlined code (2014)

#82

Post by otikik »

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…

I have worked with many developers and I have seen them follow two distinct paths when encountering complex code.

There's one camp that wants to use abstractions and names, and there's another (in my experience, smaller) camp which prefers to have as few abstractions as possible, and "every gritty detail visible".

I think both strategies have advantages and disadvantages. The group that likes abstractions can "ignore parts of the code" quickly, which potentially makes them "search" faster. If there's a bug that needs fixing, or a new feature that needs to be added, they will reach the part of the code that will need modifications faster.

The detail-oriented people can take a bit longer to identify the code that needs modification, but they also tend to be able to make those modifications faster. They also tend to be be great "spelunkers". They seem to have a "bigger cache", so to speak. But it is not infinite. They will eventually not be able to hold all the complexity in their heads, just like the first group. It will just take a bit longer.

I am firmly on the first group and that is how I write my code. I have been fortunate enough to encounter enough people from the other group to know not to diss their code immediately, and to appreciate it for its merits. When working in a team with both kinds of personalities one has to make compromises ("please remove all of these 1-line functions, Jonathan will hate them", and "could you split this 3k lines function into 2 or 3 smaller ones, for easier review?").

Re: John Carmack on inlined code (2014)

#83

Post by a_t48 »

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…

You can do this in C++, too, but the syntax is a little uglier.

Re: John Carmack on inlined code (2014)

#84

Post by newswasboring »

stahorn wrote: post #20
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)...

When you thought you made "smart" solutions and many years later you have to go in and fix bugs in it, is usually when you learn this.

There is a human side to this which I am going through right now. The first full framework I made is proving to be developer unfriendly in the long run, I put more emphasis on performance than readability (performance was the KPI we were trying to improve at the time). Now I am working with people who are new to the codebase, and I observed they were hesitant to criticize it in front of me. I had to actively start saying "lets remove , its outdated and bad". Eventually I found it liberating, it also helped me detach my self worth from my work, something I struggle with day to day.

Re: John Carmack on inlined code (2014)

#85

Post by foldr »

ninetyninenine wrote: post #44
jeltz wrote: post #32

Earlier quoted context omitted.

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

Not according to jon carmack. He stated he switched to pure functional programming in the intro which is basically stating all his logic is in the form of unit testable pure functions.

Nothing about pure functional programming requires unit testing all of your functions. You can decide to unit test larger or smaller units of code, just as you can in any other paradigm.

Re: John Carmack on inlined code (2014)

#86

Post by a_t48 »

high_na_euv wrote: post #52
Cthulhu_ wrote: post #29

Earlier quoted context omitted.

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…

>Compare this with enterprise software, which is orders of magnitude more complex than video games in terms of business logic I dont buy it in games like gta, cyberpunk or witcher 3

In both design space and programming complexity, you're right.

Re: John Carmack on inlined code (2014)

#87

Post by tomohawk »

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…

What makes an apprentice successful is learning the rules of thumb and following them.

What makes a journeyman successful is sticking to the rules of thumb, unless directed by a master.

What makes a master successful is knowing why the rules of thumb exist, what their limits are, when to not follow them, and being able to make up new rules.

Re: John Carmack on inlined code (2014)

#88

Post by Ono-Sendai »

badmintonbaseba wrote: post #60
Ono-Sendai wrote: post #59

There is actually a major problem with long functions - they take a long time to compile, due to superlinear complexity in computation time as a function of function length. In other words breaking up a large function into smaller function can greatly reduce compile times.

That honestly feels like a minor problem, and not something to optimize for. Also an aggressively inlining compiler will experience exactly the same problem. AFAIK at least clang always inlines a static (as in internal linkage) function if it's used only once in the translation unit, no matter how large it is.

Visual studio doesn't do that inlining. And it is a significant problem, I have had to refactor my code into multiple functions because of it.

Re: John Carmack on inlined code (2014)

#89

Post by Hendrikto »

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…

> he's moved on from inlining and now does pure functional programming

Neither of those are true. He does more FP ”where reasonable“, and that decreases the need for inlining. He does not do pure FP, and he still inlines.

Re: John Carmack on inlined code (2014)

#90

Post by tomohawk »

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

"Better a little copying than a little dependency" - Russ Cox
Post reply on HN