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.
show comments
gorgoiler
Erm, no? You write f(w: Walrus) -> Walrus and then let the caller handle Walrus|None and Iterable[Walrus] however they wish!
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?
ninalanyon
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.
show comments
wallstop
What is missing here is any benchmarks backing up this argument for code structure.
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.
show comments
dieselgate
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.
show comments
throwawayffffas
Just the branch predictor gains are probably worth it.
aappleby
I have always phrased this as "Never do one of something".
OutOfHere
I like it, but to do fizzbuzz in this way, you'd have to separate what's inside the loop into a reused function.
show comments
alterom
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).
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.
Erm, no? You write f(w: Walrus) -> Walrus and then let the caller handle Walrus|None and Iterable[Walrus] however they wish!
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?
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.
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.
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.
Just the branch predictor gains are probably worth it.
I have always phrased this as "Never do one of something".
I like it, but to do fizzbuzz in this way, you'd have to separate what's inside the loop into a reused function.
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).