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

171–180 of 402 posts

Re: John Carmack on inlined code (2014)

#171

Post by knodi »

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/…

> I feel like our programming tools are pretty good for programming in the small, but I suspect we're still waiting for a breakthrough for being able to actually make complex software reliably. (And, no, I don't just mean yet another "framework" or another language that's just C with a fancier type system or novel memory management)

Readability is for human optimization for self or for other people's posterity and code comprehension to the readers mind. We need a new way to visualize/comprehension code that doesn't involve heavy reading and the read's personal capabilities of syntax parsing/comprehension.

This is something we will likely never be able to get right with our current man machine interfaces; keyboard, mouse/touch, video and audio.

Just a thought. As always I reserve the right to be wrong.

Re: John Carmack on inlined code (2014)

#172

Post by wodenokoto »

donatj wrote: post #161

I have a coworker that LOVES to make these one or two line single use functions that absolutely drives me nuts. Just from a sheer readability perspective being able to read a routine from top to bottom and understand what everything is doing is invaluable. I have thought about it many times, I wish there was an IDE where you could expand function calls inline.

It’s called “self documenting code” and the way you self document code it is by taking all your comments and make them into functions, named after your would-be comment.

I’m not a fan either.

Re: John Carmack on inlined code (2014)

#174

Post by james_marks »

twh270 wrote: post #144
ragnese wrote: post #128

Earlier quoted context omitted.

> 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/…

I think the only way this gets better is with software development tools that make it impossible to create invalid states. In the physical world, when we build something complex like a car engine, a microprocessor, or bookcase, the laws of physics guide us and help prevent invalid states. Not all of them -- an upside down bookcase still works -- but a lot of them. Of course, part of the problem is that when we build…

To determine what states should be possible is the act of writing software.

Re: John Carmack on inlined code (2014)

#175

Post by SJC_Hacker »

wheybags wrote: post #125
IshKebab wrote: post #75

I think the major problem with this is scope. Now a variable declared at the top of your function is in scope for the entire function. Limiting scope is one of the best tools we have to prevent bugs. It's one reason why we don't just use globals for everything.

You can artificially create scope. I often write code like: Foo f = null; { ... stuff with variables f = barbaz; }

Is the point that any var declared in between the braces automatically goes out of scope, to minimize potential duplication of var names and unintended behavior ?

The worst I've seen is old school C programmers who insisted on reusing loop variables in other loops. Even worse, those loop variables were declared inside the loop declaration, which old C standards allowed to visible outside of it.

So they would have stuff like this

  for(int i=0; i
Later versions of C++ disallowed this, which led to some interesting compile failures, which led to insistence of the old stubborn programmers that new compilers simply not be used

Re: John Carmack on inlined code (2014)

#176

Post by AnimalMuppet »

thelastparadise wrote: post #106
whstl wrote: post #39

Earlier quoted context omitted.

Teaching. I had this problem with an overzealous junior developer and the solution was showing some different perspectives. For example John Ousterhout's A Philosophy of Software Design.

I tried this but they just come back with retorts like "OK boomer" which tends to make the situation even worse. How do you respond to that?

Or, perhaps better, just let that hang for a moment - long enough to become uncomfortable - and then say "Try again."

As others have said, if they can't or won't get that that's unacceptable behavior, fire them. (jerf is more patient than I am...)

Re: John Carmack on inlined code (2014)

#177

Post by james_marks »

JauntyHatAngle wrote: post #31
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)...

I know it's overused, but I do find myself saying YAGNI to my junior devs more and more often, as I find they go off on a quest for the perfect abstraction and spend days yak shaving as a result.

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.

Re: John Carmack on inlined code (2014)

#178

Post by shortrounddev2 »

AlotOfReading wrote: post #165
shortrounddev2 wrote: post #146

Can someone explain what inlined means here? It was my assumption that the compiler will automatically inline functions and you don't need to do it explicitly. Unless it means something else in this context

It means not using explicit functions, just writing the same code as little inline blocks inside the main function because it allows you to see all the things that would be hidden if all the code wasn't immediately visible. To the other point though, the quality of compiler inlining heuristics is a bit of a white lie. The compiler doesn't make optimal choices, but very few people care enough to notice the difference.…

Well there's also compiler directives other than `inline`, like msvc's `__inline` and `__forceinline` (which probably also have an equivalent in gcc or clang), so personally I don't think you need to make the tradeoff between readability and reusability while avoiding function calls. Not to mention C++ constevals and C-style macros, though consteval didn't exist in 2007

Re: John Carmack on inlined code (2014)

#179

Post by james_marks »

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,…

> Most of all is seeing my value not as wielding techno armageddon, but solving problems for users and customers

Also later in my career, I now know: change begets change.

That big piece of new code that “fixes everything” will have bugs that will only be discovered by users, and stability is achieved over time through small, targeted fixes.

Post reply on HN