Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Push Ifs Up and Fors Down

matklad.github.io

Post reply on HN
Print view View original

171–180 of 209 posts

Re: Push Ifs Up and Fors Down

#171

Post by panstromek »

kazinator wrote: post #113

> If there’s an if condition inside a function, consider if it could be moved to the caller instead This idle conjecture is too rife with counterexamples. - If the function is called from 37 places, should they all repeat the if statement? - What if the function is getaddrinfo , or EnterCriticalSection ; do we push an if out to the users of the API? I think that we can only think about this transformation for interna…

The keyword here is `consider`. The article targets a somewhat specific design problem where this comes up, especially when you use tagged unions or something similar.

Re: Push Ifs Up and Fors Down

#172

Post by panstromek »

krick wrote: post #148

These are extremely opinionated, and shouldn't be treated as a rule of thumb. As somebody else said, there isn't a rule of thumb here at all, but if I was to make up one, I would probably tell you the opposite: - You have to push ifs down, because of DRY. - If performance allows, you should consider pushing fors up, because then you have the power of using filter/map/reduce and function compositions to choose what ac…

I feel like you either flipped the naming or the reasons you cite don't support the conclusion.

Pushing ifs down usually prevents vectorization and the cases article mentions are those non-dry where a similar branch has to be multiplied on a ton of functions down in the stack, often because the type is internally tagged.

Re: Push Ifs Up and Fors Down

#173

Post by deepsun »

throwaway17_17 wrote: post #163
deepsun wrote: post #154

In my field (server programming) readability trumps them all. Nested g() and h() can be much better if they are even just 1% easier to understand. No one cares about a few extra CPU cycles, because we don't write system or database code.

I will admit it is probably just some internal biasing from some unknown origin, but I always tend to think of server programming as a part of systems programming. To your mind, what keeps it out of the systems programming umbrella? I am not super certain about how programmers in your area break up the constituent parts of a server’s code, so maybe I’m thinking more along the lines of the ‘framework’/libraries your c…

Good question, for me it was always the focus, e.g. systems programming is an infrastructure to build applications, in contrast to applications themselves. In server applications we really don't care if something takes 100 bytes of RAM when it could take 1 byte. RAM is cheap, engineers are expensive. So something like Rust doesn't make sense to use.

Maybe I'm using the terminology wrong, and it's actually Applications Programming, but it's easy to confuse with mobile/desktop applications, where RAM does matter. In servers we pay for RAM/CPUs ourselves.

Re: Push Ifs Up and Fors Down

#174

Post by stuaxo »

Related:

Within a function, I'm a fan of early bail out.

While this goes against the usual advice of having the positive branch first, if the positive branch is sufficiently large you avoid having most of the function indented.

Re: Push Ifs Up and Fors Down

#175

Post by hinkley »

gameman144 wrote: post #124
turtleyacht wrote: post #112

Earlier quoted context omitted.

One possibility is a file.py that is called by your framework. The interface could be something like def doth_match(*args): return True # the predicate def doeth_thou(*args): # processing things return {} # status object for example The framework loops and checks the first function; if true, then execute the second function. And then break or continue for other rule files (or objects). There could be multiple files r…

I think the parent's argument is that wherever in your framework you're calling `doth_match` and then `doeth_thou`, you have a single function that's both deciding and acting. There has to be a function in your program that's responsible for doing both.

A function that asks a question with one function call and calls another based on the answer isn’t doing any work or asking any questions. It’s just glue code. And as long as it stays just glue code, that’s barely any of your code.

Asking for absolutes is something journeymen developers need to grow out of.

The principle of the excluded middle applies to Boolean logic and bits of set theory and belongs basically nowhere else in software development. But it’s a one trick pony that many like to ride into the ground.

Re: Push Ifs Up and Fors Down

#176

Post by tsurba »

philwelch wrote: post #164
KPGv2 wrote: post #161

Earlier quoted context omitted.

> Because then you are calling middleware_caching_auth_broker() from 37 places No you aren't. You aren't really calling it from anywhere. The framework you're using, which you aren't writing, is calling the registered middleware. The topic here is complexity for the code structure because it's called from 37 different places. A registered middleware doesn't run into that issue because it doesn't get called anywhere t…

That sounds like the programming equivalent to thinking that food just comes from the grocery store.

And going to a grocery store instead of 37 individual farmers…?

Re: Push Ifs Up and Fors Down

#177

Post by satyanash »

stuaxo wrote: post #174

Related: Within a function, I'm a fan of early bail out. While this goes against the usual advice of having the positive branch first, if the positive branch is sufficiently large you avoid having most of the function indented.

> having positive branching first

This is advice I've never seen or received. It's always been the latter, exit early, etc. Languages like Swift even encode this into a feature, a la if guards.

Re: Push Ifs Up and Fors Down

#178

Post by shiandow »

treyd wrote: post #69
dataflow wrote: post #57

Earlier quoted context omitted.

You can't shove every single assumption into the type system...

You can express a lot of concepts just through types in languages with richer type systems.

Even without a rich type system you can express a lot of things just through naming.

You just can't enforce those assumptions.

Re: Push Ifs Up and Fors Down

#179

Post by coolcase »

panstromek wrote: post #172
krick wrote: post #148

These are extremely opinionated, and shouldn't be treated as a rule of thumb. As somebody else said, there isn't a rule of thumb here at all, but if I was to make up one, I would probably tell you the opposite: - You have to push ifs down, because of DRY. - If performance allows, you should consider pushing fors up, because then you have the power of using filter/map/reduce and function compositions to choose what ac…

I feel like you either flipped the naming or the reasons you cite don't support the conclusion. Pushing ifs down usually prevents vectorization and the cases article mentions are those non-dry where a similar branch has to be multiplied on a ton of functions down in the stack, often because the type is internally tagged.

3rd opinion: don't care until you have a performance issue to profile. Or you are building a high frequency trading system.

Re: Push Ifs Up and Fors Down

#180

Post by jollygoodshow »

manmal wrote: post #75
ComputerGuru wrote: post #56

Earlier quoted context omitted.

Why? Does it interpret the code?

Kind of, it’s a declarative framework like React & co. Under the hood it maps to either UIKit components or GPU (Metal) rendering. And view identity is very important for change detection. AFAICT, putting a branch in a ForEach invalidates all elements in that ForEach whenever one branch changes, because its whole identity changes.

So say I have an set of elements to render (A,B,C) but they can can come in any order or number (C,B,A,B). If I want to render in the given order, how would I approach this for the best performance implementation?
Post reply on HN