From an SE perspective, make a flatmap function that explicitly handles Collection<Optional<Walrus>>. The implementation doesn't matter. If your language/framework already has a compatible flatmap function, make a single frobnicate(Optional<Walrus>) function that returns whatever value is necessary for flatmap(frobnicate) to discard them.

From a CS perspective, doing a filter from Collection<Optional<Walrus>> to Collection<Walrus> is probably a bad idea. If your collection is small, nothing matters. If your collection is large, you probably don't want to spend time making a new copy of it. If your filter just returns a view rather than a hard copy, then there is no optimization benefit and you should just do whatever makes the most sense from an SE perspective. If frobnicate is cheap then you're paying the branch prediction failure tax anyway regardless of when you frobnicate, and if frobnicate is more expensive then your should probably parallelize and have each thread handle unpacking the Optional. Either way, you probably don't want to spend time making a copy.

These are all generalizations based on hypotheticals and there are certainly a lot of exceptions, but broadly speaking I don't see a strong argument here. If optimization matters then optimize based on your own profiling of your situation, and if optimization doesn't matter then design your functions based on what features and paradigms are available/common in your area.

But I suppose my greater philosophy for making code that avoids bugs is that you have a couple things that are done when dealing with data:

- distribution

- deciding

And you want to avoid distribution and deciding being mixed together in the same spot.

"Distribution" can be for loops but also breaking up some data based on some key into N bistinct buckets

"Deciding" is where you're looking at the data more closely to make some decision (like "is this a big customer or a small customer")

Distribution often involves decision making, but if you mix them all in one spot you can obfuscate your decision points. Splitting it up just makes things "obviously" right or "obviously" wrong. Perf stuff is another discussion of course, but in practice most things are not at a scale where it matters.

    by_category = defaultdict(list)
    for d in data:
      by_category[category(d)].append(d)

    for category, per_category_data in by_category.items():
       do_thing(category, per_category_data)

(I do like the advice of having a consistent vocabulary for working on collections as a principle though, I just find that top-level conditional use tends to quickly get you into "... why is this method not called" territory, which is a more annoying problem than "why is this slow")

You don't want to go "woof if you're a dog, meow if you're a cat", you want to go "make a sound, whoever you are". If you're a fish, you can no-op or not "accept" the call, depending on the language and convention. Obviously there is a lot of nuance, but the general idea is to push responsibilities and logic (which includes branching) down, to the level/entity/object that's best equipped to handle it.

If you apply this to the "a bunch of functions" example, you get low-level functions with branching, but you also get clean callers.

I feel like this isn't such a huge problem IRL, it's usually quite apparent where a decision should be made, but both of these "schools of thought" seem equally valid to me.

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.

Speed was almost never the reason.

And if someone decides the codebase needs an abstraction over (and therefore specific functions to handle) Iterable[Walrus|None] then you check the weather and suggest they take a break and go for a stroll. (You check the weather to see if you should lend them your brolly.)

What am I missing?

  def classify(:ok)
  def classify({:error, reason})
  def classify([first | rest])
  def classify(%{name: name, age: age}) when age >= 18
  def classify(%{name: name, age: age}) when age < 18

There's very high-leverage abstractions that completely constrain a space. An example is a good definition - you can't think of something outside to compare it to, it just is. These things survive for a long time since they define it.

But if you're trying to do that philosophy super deep into a program, you're probably violating a bunch of invariants subtly.

Of course, there is no good separation at the end of the day as we all know from spaghetti codebases :)

"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).