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

Re: John Carmack on inlined code (2014)

#301

Post by fluoridation » Wed, Oct 09, 2024, 8:33 PM UTC

tcoville wrote: post #288

lencastre wrote: post #286

I’m not even pretending I understood Carmack’s email/mailing list post but if more intelligent/experienced programmers than me care to help me out, what exactly is meant by this he wrote in 2007: _If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that._ Thanks,

This is a heavily simplified version of what I'm suspecting he's trying to portray, key this wouldn't be useful for utility functions like string manipulation but more business logic being used across similar functions: def processOrder(): # Some common processing logic print("Processing the order...") def placeOnlineOrder(): processOrder() print("Sending confirmation email...") def placeInStoreOrder(): processOrder(…

That... looks decidedly worse. Now you have fewer functions that need to be concerned with multiple unrelated things for no reason.

Re: John Carmack on inlined code (2014)

#302

Post by BenoitEssiambre » Wed, Oct 09, 2024, 8:34 PM UTC

zelphirkalt wrote: post #265

BenoitEssiambre wrote: post #160

Here are some information theoretic arguments why inlining code is often beneficial: https://benoitessiambre.com/entropy.html In short, it reduces scope of logic. The more logic you have broken out to wider scopes, the more things will try to reuse it before it is designed and hardened for broader use cases. When this logic later needs to be updated or refactored, more things will be tied to it and the effects will b…

Of course all this needs to be weighed against maintainability and readability of the code. If the code base is not mainly about something very performance critical and this kind of thing shows to be a bottleneck, then changing things away from more readable towards performance optimized implementation would require a very good justification. I doubt, that this kind of optimization is justified in most cases. For tha…

What I'm advocating here is only coincidentally a performance optimization. Readability and maintainability (and improved abstraction) are the primary concern and benefit of (sometimes) keeping things inline or more specifically of reducing entropy.

Re: John Carmack on inlined code (2014)

#303

Post by TheHegemon » Wed, Oct 09, 2024, 9:09 PM UTC

tomjakubowski wrote: post #258

ragnese wrote: post #166

Earlier quoted context omitted.

There are multiple reasons that contributing to various projects may be difficult. But, I was replying to a specific comment about writing code in a way that is easy to understand, and the comment author's acknowledgement that this idea/practice is hard to scale to a large number of developers (presumably because everyone's skills are different and because we each have different ideas about what is "clear", etc). So,…

> Yet, even a very competent C++ dev is going to have a ton of trouble figuring out the Chromium code base. I don't think this is true, or at least it wasn't circa 2018 when I was writing C++ professionally and semi-competently. I sometimes had to read, understand and change parts of the Chromium code base since I was working on a component which integrated CEF. Over time I began to think of Chromium as a good refere…

Also agree that the example code base is not the best example to use.

The Chromium code base is a joy to read and I would routinely spend hours just reading it to understand deeper topics relating to the JS runtime.

Compared to my company's much smaller code base that would take hours just to understand the most simplest things because it was written so terribly.

Re: John Carmack on inlined code (2014)

#304

Post by atq2119 » Wed, Oct 09, 2024, 9:20 PM UTC

wruza wrote: post #55

I wish languages had the following: let x = block { … return 5 } // x == 5 And the way to mark copypaste, e.g. common foo { asdf(qwerty(i+j)); printf(“%p”, write)); bar(); } …(repeats verbatim 20 times)… … common foo { asdf(qwerty(i+k)); printf(“%d”, (int)write); // cast to int bar(); } … And then you could `mycc diff-common foo` and see: : : common : : common … : : @@…@@ -asdf(qwerty(i+j)); +asdf(qwerty(i+k)); @@…@@…

Regarding compound statements returning values: There are a number of languages which have that, including Rust. Ironically, it made me wish for a reversed form of the construct, i.e. something like

    { ...; expr } --> x;
    // x is a new variable initialized to expr

I feel like this would help readability when the compound statement is very large.

Re: John Carmack on inlined code (2014)

#305

Post by spc476 » Wed, Oct 09, 2024, 9:32 PM UTC

recursive wrote: post #184

james_marks wrote: post #177

Earlier quoted context omitted.

Agreed. I’ve been trying to dial in a rule of thumb: If you aren’t using the abstraction on 3 cases when you build it, it’s too early. Even two turns into a higher bar than I expected.

It's more case by case for me. A magic number should get a named constant on its first use. That's an abstraction.

C++ programmers decided against NULL, and for well over a decade, recommended using a plain 0. It was only recently that they came up with a new name: nullptr. Sigh.

Re: John Carmack on inlined code (2014)

#306

Post by JadeNB » Wed, Oct 09, 2024, 9:39 PM UTC

ragnese wrote: post #128

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…

> My goal in most cases now is to optimize code for the limits of the human mind (my own in low-effort mode) and like to be able to treat rules as guidelines. The trouble is how can you scale this to millions of developers, and what are those limits of the human mind when more and more AI-generated code will be used? I think the truth is that we just CAN'T scale that way with the current programming languages/models/…

> macOS is produced by the richest company on Earth and a few years ago the CALCULATOR app had a bug that made it give the wrong answers...

This is stated as if surprising, presumably because we think of a calculator app as a simple thing, but it probably shouldn't be that surprising--surely the calculator app isn't used that often, and so doesn't get much in-the-field testing. Maybe you've occasionally used the calculator in Spotlight, but have you ever opened the app? I don't think I have in 20 years.

Re: John Carmack on inlined code (2014)

#307

Post by kazinator » Wed, Oct 09, 2024, 9:40 PM UTC

In my opinion, there is value in functions that have only one caller: it's called functional decomposition. The right granularity of functional decomposition can make the logic easier to understand.

To prevent unintended uses of a helper function in C, you can make it static. Then at least nothing from outside of that translation unit can call it.

Re: John Carmack on inlined code (2014)

#308

Post by atulvi » Wed, Oct 09, 2024, 9:41 PM UTC

who read this in John Carmack's voice?

Re: John Carmack on inlined code (2014)

#309

Post by Narishma » Wed, Oct 09, 2024, 9:50 PM UTC

philistine wrote: post #247

VyseofArcadia wrote: post #231

Earlier quoted context omitted.

I believe both the PS5 and whatever nonsense string of Xs, numbers, and descriptors MS named this gen's console can do 144Hz output. I don't know how many games take advantage of that or whether that refresh rate is common on TVs.

60 FPS isn't even promised on PS5 Pro. Most graphically demanding titles still aim for 30 FPS on consoles, with any game able to support 60 FPS consistently worth noting.

What they said is true. There are some games with 120 FPS modes on PS5 and Series X, maybe even series S. That doesn't mean every game (or even most) are like that, just that the hardware supports it. At the end of the day you can't stop developers targeting whatever framerate they want.

Re: John Carmack on inlined code (2014)

#310

Post by mgsouth » Wed, Oct 09, 2024, 9:56 PM UTC

randomdata wrote: post #296

mgsouth wrote: post #292

Earlier quoted context omitted.

We're in general agreement about the purpose of unit tests. I disagree on a couple of points. Tests do not document the API. No test is complete, and for that reason alone can't completely document anything. For example, a good API might specify that "the sender must be non-null, and must be valid per RFC blah." There's no way to test that inclusively, to check all possible inputs. You can't use the test cases to ded…

> There's no way to test that inclusively, to check all possible inputs. Which means the RFC claim is false and should not be asserted in the first place. The API may incidentally accept valid RFC input, but there is no way to know that it does for sure for all inputs. You might suspect it conforms to the RFC, but to claim that it does with certainty is incorrect. Only what is documented in the tests is known to be t…

OK, one more round. An API spec is a contract, not a guarentee of correctness. You, as the client, are free to pass me any data that fits the spec. If my parsing library does the wrong thing, then I've got a bug and need to fix it. My tests are also defective and need to be adjusted.

If you passed 3.974737373 to cos(x), and got back 200.0, would you be mollified if the developers told you "that value clearly isn't in the unit test cases, so you're in undefined behavior"? Of course not. The spec might be "x is a single-float by value, 0.0 The same for a mail parser. If my library croaks with a valid (per RFC) address then I've got a problem. If I try to provide some long, custom, set of cases I will or won't support, then my customer developers are going to be rightfully annoyed. What are they supposed to do when they get a valid but unsupported address? Note we're not talking about carving out broad exceptions reasonable in context ("RFC 5322 except we don't support raw IP addresses foo@[1.2.3.4]", "we treat all usernames as case-insensitive"). And we're not talking about "Our spec (intent) is foo, but we've only tested blah blah blah."

Early in my career I would get pretty frustrated by users who were not concerned with arranging their data and procedures the right way, clueless about what they really were doing. OK, so I still get frustrated by stupid :) But it's gradually seeped into my head that what matters is the user's intentions. Specs are an imperfect simplificaton of those very complex things, APIs are imperfect simplifcations of the specs, and our beautiful code and distributed clusters and redundant networks are extremely limited and imperfect implementations of the APIs. Some especially harmful potential flaws get extra attention during arch, implementation, and testing. When things get too far out we fix them.