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

231–240 of 402 posts

Re: John Carmack on inlined code (2014)

#231

Post by VyseofArcadia »

01HNNWZ0MV43FF wrote: post #223
pragma_x wrote: post #212

Earlier quoted context omitted.

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.

I don't think high frame rates are common outside of PC gaming yet. Wikipedia indicates the Switch maxes out at 1080p60, and the newest Zelda only at 900p30 even when docked https://en.m.wikipedia.org/wiki/Nintendo_Switch

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.

Re: John Carmack on inlined code (2014)

#232

Post by j7ake »

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…

To make an advance in a field, you must simultaneously believe in what’s currently known as well as distrust that the paradigm is all true.

This gives you the right mindset to focus on advancing the field in a significant way.

Believing in the paradigm too much will lead to only incremental results, and not believing enough will not provide enough footholds for you to work on a problem productively.

Re: John Carmack on inlined code (2014)

#233

Post by [deleted] »

sgu999 wrote: post #124
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)...

good devs*, not all senior devs have learned that, sadly. As a junior dev I've worked under the rule of senior devs who were over-applying arbitrary principles, and that wasn't fun. Some absolute nerds have a hard time understanding where their narrow expertise is meant to fit, and they usually don't get better with age.

[deleted]

Re: John Carmack on inlined code (2014)

#234

Post by [deleted] »

ninetyninenine wrote: post #224
coob wrote: post #220

Earlier quoted context omitted.

> I never said he said his email was completely outdated. From your prior message: > Carmack called his email completely outdated

Ok my bad but I did mention what he’s doing with inlining. So I contradicted myself in the original message which you didn’t identify. He still does inlining.

[deleted]

Re: John Carmack on inlined code (2014)

#235

Post by solomonb »

wmanley wrote: post #79
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…

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…

The original article literally starts with this:

> In the years since I wrote this, I have gotten much more bullish about pure functional programming, even in C/C++ where reasonable: (link) > >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.

He explicitly says that functional programming solves the same issue as inlining but more directly and completely.

Re: John Carmack on inlined code (2014)

#236

Post by solomonb »

Hendrikto wrote: post #89
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.

"pure FP" does not mean only writing in a functional style. Purity refers to referential transparency, ie., functions do not depend on or modify some global state.

Re: John Carmack on inlined code (2014)

#237

Post by pragma_x »

wmanley wrote: post #79
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…

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…

Thank you for this. I appreciate that this (classic) article lays bare the essence of FP without the usual pomp and "use Lisp/Scheme/Haskell already" rhetoric. My takeaway is that FP is mostly about using functions w/o side effects (pure), which can be achieved in any programming language provided you're diligent about it.

Re: John Carmack on inlined code (2014)

#238

Post by silvestrov »

marginalia_nu wrote: post #122
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 find the inlined style can actually improve clarity. A lot of code written toward the "uncle bob" style where you maximize the number of functions has fantastic local clarity, you can see exactly what the code you are looking at is doing; but atrocious global clarity, where it's nearly impossible to figure out what the system does on a larger scale. Inlining can help with that, local clarity deteriorates a bit, but…

> atrocious global clarity

much like microservices.

Re: John Carmack on inlined code (2014)

#239

Post by hnuser123456 »

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…

On a positive note, most AI-gen code will follow a style that is very "average" of everything it's seen. It will have its own preferred way of laying out the code that happens to look like how most people using that language (and sharing the code online publicly), use it.

Re: John Carmack on inlined code (2014)

#240

Post by Spivak »

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…

> What do you use unit tests for, other than verifying implementation details?

1. Determining when the observable behavior of the program changes.

2. Codifying only the specific behaviors that are known to be relied on by callers.

3. Preventing regressions after bugs are fixed.

Failing tests are alarm bells, when do you want them to grab your attention?

Post reply on HN