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

351–360 of 402 posts

Re: John Carmack on inlined code (2014)

#351

Post by devjab »

int_19h wrote: post #320
devjab wrote: post #170

Earlier quoted context omitted.

I find that it’s typically the other way around as things like DRY, SOLID and most things “clean code” are hopeless anti-patterns peddled by people like Uncle Bob who haven’t actually worked in software development since Fortran was the most popular language. Not that a lot of these things are bad as a principle. They come with a lot of “okish” ideas, but if you follow them religiously you’re going to write really ba…

The problem with repeating code in multiple places is that when you find a bug in said code, it won't actually be fixed in all the places where it needs to be fixed. For larger projects especially, it is usually a worthwhile tradeoff versus having to peel off some extra abstraction layers when reading the code. The problems usually start when people take this as an opportunity to go nuts on generalizing the abstracti…

We agree, but we’ve come to different conclusions. Probably based on our experiences. Which is why I wanted to convey that I think you should do these things in moderation. I almost never do classes, and much rarer inheritance, as an example. That doesn’t mean I wouldn’t make a “base class” containing things like “owned by, updated by, some time stamp” or whatever you would want added to every data object in some traditional system and then inherit that. I would, I might even make multiple “base classes” if it made sense.

What I won’t do, however, is abstract code until I have to. More than that as soon as that shared code stops being shared, I’ll stop doing DRY. Not because DRY is necessarily bad, but because of the way people write software which all too often leads to a dog which will tell you dogs can’t fly if you cal fly() on it. Yes, I know that is ridiculous, but I’ve never seen an “clean” system that didn’t eventually end up like that. People like Uncle Bob will tell you that is because people misunderstood the principles, and they’d be correct. Maybe the principles are simply bad if so many people misunderstand them though?

Re: John Carmack on inlined code (2014)

#352

Post by grougnax »

doctorpangloss wrote: post #264
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.

> In this era of 3-5 frame latency being the norm (at least on e.g. the Nintendo Switch) Which titles is this true for? Have you or anyone else measured?

Almost every title. This is common knowledge.

Re: John Carmack on inlined code (2014)

#353

Post by silisili »

spinningslate wrote: post #63
reshlo wrote: post #48

Earlier quoted context omitted.

I’ve had the opposite experience before. As a young developer, there were a number of times where I advocated for doing something “the right way” instead of “the good enough way”, was overruled by seniors, and then later I had to fix a bug by doing it “the right way” like I’d wanted to in the first place. Doing it the right way from the start would have saved so much time.

This thread is a great illustration of the reality that there are no hard rules, judgement matters, and we don't always get things right. I'm pretty long-in-the-tooth and feel like I've gone through 3 stages in my career: 1. Junior dev where everything was new, and did "the simplest thing that could possibly work" because I wasn't capable of anything else (I was barely capable of the simple thing). 2. Mid-experience,…

> The focus on really understanding the problem tends to create more stable abstractions which do get reused. But that's emergent, not speculative ahead-of-time.

Thank you for putting so eloquently my own fumbling thoughts. Perfect explanation.

Re: John Carmack on inlined code (2014)

#354

Post by Hendrikto »

solomonb wrote: post #236
Hendrikto wrote: post #89

Earlier quoted context omitted.

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

I know what purity is. It is a core principle of functional programing. So ”functional“ already implies purity, and ”pure functional“ implies exclusively functional (e.g. Haskell).

Re: John Carmack on inlined code (2014)

#355

Post by Hendrikto »

ninetyninenine wrote: post #195
Hendrikto wrote: post #89

Earlier quoted context omitted.

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

He literally says he’s more bullish on pure fp. Read it. And I also wrote about where he still inlines.

Exactly. More bullish means he uses and advocates for functional more than before. It by no means implies having ”moved on“ from inlining.

Re: John Carmack on inlined code (2014)

#356

Post by freilanzer »

oglop wrote: post #221

Oh good, a FP post. I love watching people argue over nothing. Here’s the actual rule, do what works and ships. Don’t posture. Don’t lament. Don’t idealize. Just solve the fucking problem with the tool and method that fits and move on. And do not try to use this comment threat to understand FP. Too many cooks, and most of the are condescending douchebags. Go look at Wikipedia or talk with an AI about it. Don’t ask th…

Ironically, this comment adds nothing to the post and is needlessly belligerent and condescending.

Re: John Carmack on inlined code (2014)

#357

Post by reshlo »

whstl wrote: post #314
lcnPylGDnU4H9OF wrote: post #294

Earlier quoted context omitted.

Heh, I've read [2] before but another reading just now had this passage stand out: > Another common thing Architecture Astronauts like to do is invent some new architecture and claim it solves something. Java, XML, Soap, XmlRpc, Hailstorm, .NET, Jini, oh lord I can’t keep up. And that’s just in the last 12 months! > I’m not saying there’s anything wrong with these architectures… by no means. They are quite good archi…

Both React and Vue are older than 10 years old at this point. Both are older than jQuery was when they were released, and both have a better backward compatibility story. The only two real competitors not that far behind. It's about time for this crappy frontend meme to die. Even SOAP didn't really live that long before it started getting abandoned en masse for REST. As someone who was there in the "last 12 months" J…

> Some of this technology has a completely different level of complexity that to this day I am not able to grasp

Enterprise JavaBeans mentioned?

Re: John Carmack on inlined code (2014)

#358

Post by tmtvl »

ninetyninenine wrote: post #334
int_19h wrote: post #322

Earlier quoted context omitted.

For-loops do exist, they just need to not have side effects, which in practice means the likes of map/filter/reduce (ideally promoted to a first class language feature like sequence comprehensions). You could argue that those are still desugared to recursion, but I think at that point it's kinda moot - the construct is still readily recognizable as a loop, and it's most likely also implemented under the hood as an im…

>For-loops do exist, they just need to not have side effects, No they don't. For loops and loops in general are procedural actions. You are jumping from directive to directive, command to command. Loops are NOT functional at all. loops are an artifact of the computational machine, jumping to different instructions. Functional programs like functions in mathematics DO not contain for loops. > which in practice means t…

I dunno, I imagine that there's no appreciable difference between:

  (loop :for i :below 10 :collect i)
and:

  (let loop ((i 0))
    (if (= i 10)
        nil
        (cons i
              (loop (1+ i)))))

Re: John Carmack on inlined code (2014)

#359

Post by reshlo »

dahart wrote: post #336
reshlo wrote: post #48

Earlier quoted context omitted.

I’ve had the opposite experience before. As a young developer, there were a number of times where I advocated for doing something “the right way” instead of “the good enough way”, was overruled by seniors, and then later I had to fix a bug by doing it “the right way” like I’d wanted to in the first place. Doing it the right way from the start would have saved so much time.

Ah, but that’s assuming the ‘right way’ path went perfectly and didn’t over-engineer anything. In reality, the ‘right way’ path being advocated for, statistically will also waste a lot of time, and over-engineering waste can and does grow exponentially, while under-engineering frequently only wastes linear and/or small amounts of time, until the problem is better understood. Having witnessed first-hand over-engineeri…

> In reality, the ‘right way’ path being advocated for, statistically will also waste a lot of time, and over-engineering waste can and does grow exponentially, while under-engineering frequently only wastes linear and/or small amounts of time, until the problem is better understood.

The “right way” examples I’m thinking of weren’t over-engineering some abstraction that probably wasn’t needed. Picture replacing a long procedural implementation, filled with many separate deprecated methods, with a newer method that already existed and already had test coverage proving it met all of the requirements, rather than cramming another few lines into the middle of the old implementation that had no tests. After all, +5 -2 without any test coverage is obviously better than +1 -200 with full test coverage, because 3 is much smaller than 199.

Re: John Carmack on inlined code (2014)

#360

Post by reshlo »

sdeframond wrote: post #80
reshlo wrote: post #48

Earlier quoted context omitted.

I’ve had the opposite experience before. As a young developer, there were a number of times where I advocated for doing something “the right way” instead of “the good enough way”, was overruled by seniors, and then later I had to fix a bug by doing it “the right way” like I’d wanted to in the first place. Doing it the right way from the start would have saved so much time.

> then later I had to fix a bug How much later? Is it possible that by delivering sooner your team was able to gain insight and/or provide value sooner? That matters!

In many cases, we didn’t deliver sooner than we could have, because my solution had roughly equivalent implementation costs to the solution that was chosen instead. In some cases the bug was discovered before we’d even delivered the feature to the customers at all.
Post reply on HN