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

181–190 of 402 posts

Re: John Carmack on inlined code (2014)

#181

Post by ziml77 »

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?

You mean they literally say "ok boomer"? If so they are not mature enough for the job. That phrase is equivalent to "fuck off" with some ageism slapped on top and is totally unacceptable for a workplace.

Re: John Carmack on inlined code (2014)

#182

Post by crabbone »

wavemode wrote: post #157
crabbone wrote: post #143

Earlier quoted context omitted.

Maybe "indoctrination" was a poor choice of word here. The problem with this maxim is that it welcomes moral relativism. This can be bad on the assumption that whoever is exposed to the maxim is not a proponent of "virtue ethics" (I use this as a catch-all term for various religious ethics doctrines, the underlying idea is that moral truths are given to people by a divine authority rather than discovered by studying…

> maxim suggests that no matter what your moral framework looks like, you should accept that under some circumstances it's OK to have child marriages You seem to have either misread the maxim, or misunderstood it. The maxim is not that an intelligent person -must- hold two contradictory thoughts in their head at once - rather, that they should be able to. Being "able to" do something, does not mean one does it in all…

In this context, it doesn't matter if they "must" or "should be able to". No, I didn't misunderstand the maxim. No, I didn't mean that it has to happen in all cases. You are reading something into what I wrote that I didn't.

The maxim is not used by religious people to its intended effect. Please read again, if you didn't see it the first time. The maxim is used as a challenge that can be rephrased as: "if you are as intelligent as you claim, then you should be able to accept both what you believe to be true and whatever nonsense I want you to believe to be true."

Re: John Carmack on inlined code (2014)

#183

Post by randomdata »

rickreynoldssf wrote: post #132

The clean code people are losing their collective minds reading that. lol

Why's that? Uncle Bob seems pretty clear that most of your code should be free of side effects, and that necessary state mutation should be isolated to one place. Carmack is saying the same thing.

Re: John Carmack on inlined code (2014)

#184

Post by recursive »

james_marks wrote: post #177
JauntyHatAngle wrote: post #31

Earlier quoted context omitted.

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.

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

Re: John Carmack on inlined code (2014)

#185

Post by Ono-Sendai »

badmintonbaseba wrote: post #120
Ono-Sendai wrote: post #88

Earlier quoted context omitted.

Visual studio doesn't do that inlining. And it is a significant problem, I have had to refactor my code into multiple functions because of it.

It might be a significant problem, but not in the code, but the compiler. Fair enough, you are working around a compiler issue.

If you consider any superlinear complexity a 'compiler issue' I guess.

Re: John Carmack on inlined code (2014)

#186

Post by Ono-Sendai »

tightbookkeeper wrote: post #119
Ono-Sendai wrote: post #59

There is actually a major problem with long functions - they take a long time to compile, due to superlinear complexity in computation time as a function of function length. In other words breaking up a large function into smaller function can greatly reduce compile times.

If you are willing to make code worse to micro optimize compile times (not even sure this is true) then you should not use any modern language with complex type checking (rust, swift, C#, etc).

Writing a medium to large program in C++, you really need to fight long compile times or they can get out of hand. That affects the way you write code quite a lot, or it should at least. I've heard Rust and Swift also suffer from long compile times.

Re: John Carmack on inlined code (2014)

#187

Post by AlotOfReading »

shortrounddev2 wrote: post #178
AlotOfReading wrote: post #165

Earlier quoted context omitted.

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

__forceinline is purely a suggestion to the compiler, not a requirement. Carmack's point isn't about optimizing the costs of function calls though. It's about the benefits to code quality by having everything locally visible to the developer.

Re: John Carmack on inlined code (2014)

#188

Post by ninetyninenine »

nuancebydefault wrote: post #137
ninetyninenine wrote: post #44

Earlier quoted context omitted.

Not according to jon carmack. He stated he switched to pure functional programming in the intro which is basically stating all his logic is in the form of unit testable pure functions.

I found this [] article of Carmack. While reading, I understood there is a large set of gray shades to pureness of "pure functional" code. He calls being functional a useful abstraction, a function() is never purely functional. [] https://web.archive.org/web/20120501221535/http://gamasutra....

When people say pure functional programming they never mean the entire program is like this.

Because if it were your program would have no changing state and no output.

What they mean is that your code is purely functional as much as possible. And there is high segregation between functional code and non functional code in the sense that state and IO is segregated as much as possible away into very small very general functionality.

Re: John Carmack on inlined code (2014)

#189

Post by MetaWhirledPeas »

wodenokoto wrote: post #172
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.

Everything must be done to taste. I think code can be made "self-documenting" without going overboard and doing silly things.

Re: John Carmack on inlined code (2014)

#190

Post by ninetyninenine »

foldr wrote: post #85
ninetyninenine wrote: post #44

Earlier quoted context omitted.

Not according to jon carmack. He stated he switched to pure functional programming in the intro which is basically stating all his logic is in the form of unit testable pure functions.

Nothing about pure functional programming requires unit testing all of your functions. You can decide to unit test larger or smaller units of code, just as you can in any other paradigm.

In pure functional programming a pure function is unit testable by definition of what a pure function is. I never said it requires functions to be tested. Just that it requires functions to be testable.

In other paradigms do not do this. As soon as a module touches IO or state it becomes entangled with that and NOT unit testable.

Is it still testable? Possibly. But not as a unit.

Post reply on HN