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

211–220 of 402 posts

Re: John Carmack on inlined code (2014)

#211

Post by tetha »

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…

I had exactly this discussion today in an architectural discussion about an infrastructure extension today. As our newest team member noted, we planned to follow the reference architecture of a system in some places, and chose not to follow the reference architecture in other places.

And this led to a really good discussion pulling the reference architecture of this system apart and understanding what it optimizes for (resilience and fault tolerance), what it sacrifices (cost, number of systems to maintain) and what we need. And yes, following the reference architecture in one place and breaking it in another place makes sense.

And I think that understanding the different options, as well as the optimization goals setting them apart, allows you to make a more informed decision and allows you to make a stronger argument why this is a good decision. In fact, understanding the optimization criteria someone cares about allows you to avoid losing them in topics they neither understand nor care about.

For example, our CEO will not understand the technical details why the reference architecture is resilient, or why other choices are less resilient. And he would be annoyed about his time being wasted if you tried. But he is currently very aware of customer impacts due to outages. And like this, we can offer a very good argument to invest money in one place for resilience, and why we can save money in other places without risking a customer impact.

We sometimes follow rules, and in other situations, we might not.

Re: John Carmack on inlined code (2014)

#212

Post by pragma_x »

VyseofArcadia wrote: post #156

> That was a cold-sweat moment for me: after all of my harping about latency and responsiveness, I almost shipped a title with a completely unnecessary frame of latency. In this era of 3-5 frame latency being the norm (at least on e.g. the Nintendo Switch), I really appreciate a game developer having anxiety over a single frame.

To be fair, back in 2014 that was one frame at 60Hz or slower for some titles. At 80-120Hz, 3-5 frames is comparatively similar time.

Re: John Carmack on inlined code (2014)

#214

Post by randomdata »

mgsouth wrote: post #76
xboxnolifes wrote: post #30

Earlier quoted context omitted.

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

What do you use unit tests for, other than verifying implementation details? Perhaps we have a difference in definition. To me, a unit test for a function such as "parse_news_email" would explore variations in parameters and states. Because of combinatorial explosion, that often means at least some white-box testing. I'm not going to generate random subjects and senders, and received-froms, I'm going to target based…

Unit tests are for documenting the API contract for the user. You are going to target based on what you are willing to forevermore commit to for those who will use what you have created. Indeed, what happens when two messages come in with the same message ID is something the user needs to be aware of and how it functions needs to remain stable no matter what you do behind the scenes in the future, so you would absolutely want to document that behaviour. How it is implemented is irrelevant, though. The only thing that matters is that, from the public API perspective, it is handled appropriately.

There is a time and place for other types of tests, of course. You are right that unit tests are not the be all and end all. A good testing framework will allow you to mark for future developers which tests are "set in stone" and which are deemed throwaway.

Re: John Carmack on inlined code (2014)

#215

Post by badmintonbaseba »

Ono-Sendai wrote: post #201
badmintonbaseba wrote: post #198

Earlier quoted context omitted.

It absolutely is, if it makes compile times unreasonable for reasonable code. Compilers have to make trade-offs like this all the time, they can't use overly excessive optimizations.

I dunno. O(n^2) is for sure a bug. But O(nlogn) I think is reasonable.

O(nlogn) is probably reasonable. Why break up a long function then if you are experiencing O(nlogn) scaling of compile time on function size?

Re: John Carmack on inlined code (2014)

#216

Post by knodi123 »

badmintonbaseba wrote: post #203
norir wrote: post #193

Earlier quoted context omitted.

This is why I think it's a mistake that many popular languages, including standard c/c++, do not support nested function definitions. This for me is the happy medium where code can be broken into clear chunks, but cannot be called outside of the intended scope. A good compiler can also detect if the nested function is only called once and inline it.

C++ has lambdas and local classes. Local classes have some annoying arbitrary limitations, but they are otherwise useful.

After spending a lot of time writing idiomatic React components in es6, I've found my love of locally declared lambdas to really grow. If I give the lambdas really good names, I find that the main body of my component is very, very readable, even more so than if I'd used a more traditional style liberally sprinkled with comments.

Re: John Carmack on inlined code (2014)

#217

Post by Ono-Sendai »

badmintonbaseba wrote: post #215
Ono-Sendai wrote: post #201

Earlier quoted context omitted.

I dunno. O(n^2) is for sure a bug. But O(nlogn) I think is reasonable.

O(nlogn) is probably reasonable. Why break up a long function then if you are experiencing O(nlogn) scaling of compile time on function size?

Because it can still result in compile times I find excessive. For example breaking up a function that takes 5 seconds to compile into a bunch of functions that take 1 to 2 seconds in total.

Re: John Carmack on inlined code (2014)

#218

Post by lifeisstillgood »

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…

I often Bang on about “software is a new form of literacy”. And this I feel is a classic example - software is a form of literacy that not only can be executed by a CPU but also at the same time is a way to transmit concepts from one humans head to another (just like writing)

And so asking “will AI generated code help” is like asking “will AI generated blog spam help”?

No - companies with GitHub copilot are basically asking how do I self-spam my codebase

It’s great to get from zero to something in some new JS framework but for your core competancy - it’s like outsourcing your thinking - always comes a cropper

(Book still being written)

Re: John Carmack on inlined code (2014)

#219

Post by jayd16 »

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.

Ideally, you've just moved the unit boundary to where it logically should be instead of many small implementation details that should not be exposed.

Re: John Carmack on inlined code (2014)

#220

Post by coob »

ninetyninenine wrote: post #194
wmanley wrote: post #79

Earlier quoted context omitted.

Here's the link where he discusses functional programming style: https://web.archive.org/web/20170116040923/http://gamasutra.... He does not say that that his email is completely outdated - he just says that calling pure functions is exempt from the inlining rule. He's not off writing pure FP now. His approach is still deeply pragmatic. In the link above he discusses degrees of function purity. "Pure FP" has a whole…

He literally said he’s bullish on pure fp. Which means he is off writing pure fp. His own article about it never explicitly or implicitly implies a “pragmatic approach”. I never said he said his email was completely outdated. He for sure implies it’s outdated and updates us on his views of inlining which I also mentioned.

> I never said he said his email was completely outdated.

From your prior message:

> Carmack called his email completely outdated

Post reply on HN