Remix.run Logo
▲ Push ifs up and fors down: The idiom, its algebra, and its limits(debasishg.github.io)
53 points by speckx 3 hours ago | 15 comments
▲socializer 2 hours ago | parent | next [-]

I am continually impressed by the ability of LLMs to take trivial ideas and turn them into lengthy and obtuse blog posts with unnecessary analogies.

▲swiftcoder an hour ago | parent | next [-]

Honestly, this just looks like one of those lingo-heavy-but-surface-level blog posts that used to make functional programming spaces so insufferable to everyone on the outside

▲mahboi an hour ago | parent [-]

These things are so divorced from the reality of programming, even when they involve actual code instead of fancy lingo. Like in Scala, not a pure functional language, tutorials used to find the most convoluted higher-order functional way to do simple things.

▲bioneuralnet 2 hours ago | parent | prev [-]

Yet another encroachment on traditionally human activity.

▲moritzwarhier 2 hours ago | parent [-]

I am the

  Option<Walrus>
▲ninalanyon an hour ago | parent | prev | next [-]

I've done this for years. Not every time of course but where it makes the code easier to understand and maintain.

Speed was almost never the reason.

▲alterom 38 minutes ago | parent [-]

I take it you never rewrote a Matlab for loop as a vector/matrix op for insane speedups then :)

▲wallstop an hour ago | parent | prev | next [-]

What is missing here is any benchmarks backing up this argument for code structure.

Of note, as of C#9 (and maybe prior), the dotnet runtime does this automatically whenever it is deemed safe. https://devblogs.microsoft.com/dotnet/performance-improvemen...

The same technique is applied as an optimization, when deemed safe, in all current gen c compilers (gcc, llvm, etc).

I'm very confused why neither measurements nor references to when this is done automatically in most modern languages is included in the article.

▲cogman10 an hour ago | parent [-]

At least in JVM land, it's pretty easy to thwart that optimization. Particularly if the condition is on a mutable yet unchanged in the loop value.

For example:

    var map = new HashMap<String, String>();
    map.put("foo", "bar");
    for (var i : items) {
      if ("bar".equals(map.get("foo")) {
        doStuff(i);
      }
    }
Even though `map` isn't mutated, it's hard enough for the JVM to detect and the underlying `get` functions are complex enough that it'll run the `get("foo")` every time, which can be quiet expensive.
▲dieselgate 19 minutes ago | parent | prev | next [-]

Didn’t see it mentioned in the article but isn’t leading with if-statement called a “guard clause”. I like that pattern but it’s just general best practice I thought.

▲woadwarrior01 15 minutes ago | parent [-]

Swift explicitly has a guard statement for this. Rust's let .. else { ... } is also very similar.

https://docs.swift.org/latest/documentation/the-swift-progra...

▲aappleby an hour ago | parent | prev | next [-]

I have always phrased this as "Never do one of something".

▲OutOfHere 37 minutes ago | parent | prev | next [-]

I like it, but to do fizzbuzz in this way, you'd have to separate what's inside the loop into a reused function.

▲pdpi 18 minutes ago | parent [-]

I think it's sort of obvious that the limit to this general rule is when data dependencies between fors and ifs forbid you from pushing things further up/down.

▲alterom 38 minutes ago | parent | prev [-]

TL;DR in one sentence:

"the loop runs without a branch, and is a candidate for vectorization".

That's it, that's the article. This matters a lot in huge-scale / scientific computing / HPF, where if you can express something as an operation on vectors on matrices, you win big (those ops parallelize well, can be run on GPUs, clusters, what have you).