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

331–340 of 402 posts

Re: John Carmack on inlined code (2014)

#331

Post by int_19h »

IshKebab wrote: post #197
wheybags wrote: post #125

Earlier quoted context omitted.

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

Now you have to make `f` nullable and you run the risk of not initialising it and getting a null pointer. You can't do it in C, but in functional style languages you can do this: let f = { let bar = ...; let baz = ...; let barbaz = ...; barbaz }; Which is a lot nicer. But if you ask me it's just a function by another name except it still doesn't limit scope quite as precisely as a function.

In C++ you can do:

   auto f = [&] {
      ...
      return barbaz;
   }();
with the side benefit that you can also make the use of state explicit inside of [] instead of using wildcard capture.

Given that it's neither reused nor parametrized, I'm not sure why you see this kind of pattern as a "function by another name", though. Semantically it's more of a namespace if anything.

Re: John Carmack on inlined code (2014)

#332

Post by xboxnolifes »

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?

You don't need to verify the return of `parse_subject()` directly, since it will be part of the return of `parse_email()`. Verify it there.

Re: John Carmack on inlined code (2014)

#334

Post by ninetyninenine »

int_19h wrote: post #322
ninetyninenine wrote: post #291

Earlier quoted context omitted.

No functional programming is about programming as if your code is a math equation. In math people never use procedures. They write definitions in math in terms of formulas and expressions. If you can get everything to fit on one line in your programming. Then you are doing functional programming. The lack of side effects, lack of mutation and high modularity are the beneficial outcome of fp, it is not the core of wha…

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

All programs are desugared into assembly instructions. Assembly instructions are procedural by nature... they are not functional so your point is moot as everything is desugared into loop based jumps.

map/filter/reduce Are not loops. They are fundamentally different. It doesn't matter if it's "recognizeable" as a loop, it is NOT a loop. There is an isomorphism between imperative and functional programming, So the definition of Loop vs. no loops refers to the superficial differences between the two EVEN when the underlying things are the same.

>In general, so long as mutation can be encapsulated in modules that only expose pure functional interfaces, I think it should still count as FP for practical purposes.

It actually can't... for loops rely on mutation to work.

a for loop looks like this:

     
     for i in range(10):
By nature the for loop needs to influence outer scope otherwise your for loop is utterly useless. So how would you influence outer scope from inner scope?

     
     for i in range(10):
That's the only way man.

This is the fundamental nature of for loops. They are imperative constructs. Sure it can look very similar to map or reduce or even filter, but THEY are not the same.

Re: John Carmack on inlined code (2014)

#335

Post by rcv »

> The fly-by-wire flight software for the Saab Gripen (a lightweight fighter) went a step further...

I would love to hear some war stories about the development of flight software. A lot of it is surely classified, but I'm fascinated by how those systems are put together.

Re: John Carmack on inlined code (2014)

#336

Post by dahart »

reshlo wrote: post #48
silisili wrote: post #45

Earlier quoted context omitted.

Yes! I work with many folks objectively way younger and smarter than me. The two bad habits I try to break them of are abstractions and what ifs. They spend so much time chasing perfection that it negatively affects their output. Multiple times a day I find myself saying 'is that a realistic problem for our use case?' I don't blame them, it's admirable. But I feel like we need to teach YAGNI. Anymore I feel like a sa…

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-engineering waste millions of dollars and years of time, on more than one occasion, by people advocating for the ‘right way’, I think tallying the time wasted upgrading an under-engineered solution is highly error prone, and that we need to assume that some percentage of time we’ll need to redo things the right way, and that it’s not actually a waste of time, but a cost that needs to be paid in search of whether the “right way” solution is actually called for, since it’s often not. The waste might be the lesser waste compared to something much worse, and it’s not generally possible to do the exact right amount of engineering from the start.

Someone here on HN clued me into the counter acronym to DRY, which is WET: write everything twice (or thrice) so the 2nd or 3rd time will be “right”. The first time isn’t waste, it’s necessary learning. This was also famously advocated by Fred Brooks: “Play to Throw One Away” https://course.ccs.neu.edu/cs5500f14/Notes/Prototyping1/plan...

Re: John Carmack on inlined code (2014)

#337

Post by JamesBarney »

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 go to heuristic for how to break up code is white board or draw up in lucidchart your solution to explain it to another dev. If your methods don't match the whiteboard refactor.

Re: John Carmack on inlined code (2014)

#338

Post by munificent »

kragen wrote: post #295
munificent wrote: post #290

Earlier quoted context omitted.

> You've seen games running at 120Hz and at 60Hz. The difference is obvious, isn't it? Honestly, I have not. I'm not much of a gamer, even though I used to be a game developer. Certainly the difference between 30Hz and 60Hz is noticeable. Maybe this is just because I'm old school but if it were me, I would absolutely prioritize low latency over high frame rate. When you played an early console game, the controls felt…

Oh! I assumed that because you were a famous game developer you would hang out with gamers who would proudly show off their 120Hz monitor setups. I agree that low latency is more important than high frame rate, and I agree about the snappiness. But low jitter is even more important for that than low latency, and a sufficiently low frame rate imposes a minimum of jitter. Music is even less tolerant of latency, and PCM…

Haha, alas the reality of my celebrity is not as much as you might hope. :)

Re: John Carmack on inlined code (2014)

#339

Post by wrsh07 »

davidw wrote: post #321
rileymat2 wrote: post #298

Earlier quoted context omitted.

I get your point, but often the binary code instructions between those is vastly different.

The fact that we work with the high level languages rather than the binary code, despite all their inefficiencies, speaks to the human aspect being pretty important in the equation.

This entire conversation is about tradeoffs, but I would note that some of my favorite engineers that I've had the pleasure of knowing are: 1) very fast and 2) know exactly what the binary code of the thing they are trying to do looks like

There's a (3) where they'll quickly confirm their hypothesis using godbolt (or similar) if in doubt or they want to actually think in binary.

Fortunately for the programming community, many of us are able to create useful or interesting things without that kind of depth

Re: John Carmack on inlined code (2014)

#340

Post by wrsh07 »

ninetyninenine wrote: post #291
pragma_x wrote: post #237

Earlier quoted context omitted.

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.

No functional programming is about programming as if your code is a math equation. In math people never use procedures. They write definitions in math in terms of formulas and expressions. If you can get everything to fit on one line in your programming. Then you are doing functional programming. The lack of side effects, lack of mutation and high modularity are the beneficial outcome of fp, it is not the core of wha…

As someone who likes math (math major, applied math grad) and who picked up functional programming relatively early in my career, I don't find this model (fp is just math) to improve my understanding or make it easier to understand why I would want to program like this

Talking about state and error handling is helpful because it helps explain why to use the tool, not how the tool was forged (or originally conceived)

Post reply on HN