Anti-If Programming vs. Smelse
Vložit
- čas přidán 23. 03. 2024
- Grab your free Smelse Diploma here: markjivko.com/smelse/
"Trust me, I'm a Doctor" works for the Janitor in Scrubs. Really, such an awesome line!
Not really your best argument for polymorphism, though. - Zábava
I thought this was going to be something interesting like branchless programming, which is a legitimate use case for execution hot paths
but it turned out to be just another guy pushing his horrible courses lol
Me too!
I was soo excited to discuss these things with the author himself on LinkedIn directly - only to be met with a very harsh appeal to Authority Bias. That was disappointing, indeed.
yep that's also what i was expecting
oh god I'm so glad Rust allows to break from any named code block, so you can use the Smelse methodology blazingly fast 🚀 (and without fake loops)
I love Rust so much!
Thank you for the idea, maybe I'll do a video on that soon.
can't wait to hop on the smelse train like it's a new JS framework
Don't forget your diploma: markjivko.com/smelse/
Smelse like a scam to me honestly. I'll stick with Anti-If
I'm probably pro-if, for a lack of a better term.
Then again... I did a bunch of the Advent of Code 2023-challenges using "no if"-approach, on a dare. When I took a step back and went through the code it was really easy to understand everything. Any modification to the code went really fast. The code felt "clean", separated and isolated. Lots of common design patterns and data structures.
My conclusion is that a "no if"-approach forces the developer to not take short cuts to solve problems. It is possible to do anyway but it is so easy to pull out the "if"-keyword to solve the problem immediately instead of producing architecture that supports your code.
Side note:
As a developer who focuses on code that is easy to understand vs super performant code, I really dislike "Pattern matching" yet it is hailed as a savior. All I see with pattern matching are verbose lines of regular expressions. The amount of PRs I've rejected because developers feels like they can pattern match the project to oblivion is surprisingly high. Don't even get me started on ternary if-statements...!
Sorry for serious comments on a funny video. :)
I like your insights!
Indeed, the ternary operator is yucky. On the other hand, I don't mind it that much in the world of React components.
Regular expressions are useful too - sometimes. Other times, you're better off writing a tokenization algo yourself.
There's this thing called "creative limitation", where constraints seem to have the interesting effect of fostering creativity.
So if you're given a programming task but you're told not to use "if" statements (or avoid them), that constraint forces you to look for alternative patterns - such as polymorphism and higher order conditionals.
However - as always in SWE -, more creativity is not a desideratum. I would even go as far as saying a code that tries to be "very clever" should be rewritten from scratch.
Attempting to avoid "if" statements just for fun is an interesting thought experiment. Using that game in production code, on the other hand, is just plain wrong as it leads to "over-engineering".
This was surprisingly good for how few subs you have, I can definitely see your channel taking off
I appreciate that!
Genius. Just took my diploma, now gonna tell my university bros about Smelse thing. Thank you, please make more courses!
do-while-false is just goto in disguise :D
Don't say bad things about my precious! 😂
I'm kidding.
Do-while-false is just a flavor of the Guard Clause, but using block breaks instead of return statements.
I prefer it to the guard clause because it allows me to have only 1 return statement per function. So that way I can pretend that functions are SiSo - single input, single output.
It's a pattern I like personally, not one that everyone should use.
I dislike using too many ifs, but being anti-if like this guy seems like a bad idea.
Basically any problem can be solved if you throw an infinite amount of ifs at it, and I see many programmers write code this way and it irks me.
"There's a bug in the code? Just put an if to check for the bug condition!"
"Who needs a switch when I can if 20 times in a row??"
I like my ifs to be as meaningful as possible. I like them as an actual structural fork in the algorithm rather than a one size fits all solution to everything with ifs all over the place.
If either Kent Beck or Robert Martin has their name attached to something, you can safely assume its useless and move on.
Avoiding branching makes sense in shader programming due to a bunch of cores executing the same instruction in a batch and having to do it again for a different branch if there are any, slowing everything down. That's about it.
Nit surprising tbh, linkedin posts are generally pretty bad.
The original post was probably not about branchless programming optimizations. I doubt that the course author cared about performance but rather what looks "nice" (by his standards) in a codebase
Perhaps we could repackage plain old programming as the "DON'T GO TO" paradigm?
i like smelse, it seems it's a better version of an adage what I used to say, "the best kind of conditional is return".
Usually I would also add "and the best kind of comment is a function name".
At some point I would realize that most ugly if/else branches could be broken by moving whatever is causing the complexity into a function (which often doubles as a documentation strategy) and just returning/throwing on all unhappy conditions. This can sometimes have a nice effect that the very last line in the function is the happiest one, and also the most representative of what the function is about. If you do it consistently you can often understand the gist of the function by reading the signature and the last line.
Do while false is just a flavor of the Guard Clause. I prefer it because it allows me to have only 1 return statement per function, following your "happy function" definition of a final, easy to follow return.
I like siso functions. That is, single input, single output.
One set of arguments, and only one return statement.
Do while false is a great tool for that.
Hey nice vid, keep it up! I recently heard about Gleam, the language with no if. I thought I was about to get another video on this and was worried this is a trend. If/Else is such a huge thing to sacrifice for some higher purpose. Also well done on implementing another goto, just what php needs.
Thank you!
do {} while(false) is not as evil as go-to, but they are definitely cousins, that's for sure.
First time I hear of it, but branchless programming I do know and that is not an empty promise.
The thing is, the typical programmer never has to deal with it in any detail.
Just write for better predictable execution paths and memory-access.
As in the end, that is the source of gaining performance.
My takeaway is this: if you truly want to optimize performance, focus on O(n); logical lines of code and number of "if" statements are not important.
If you want to optimize loading times and memory performance, polymorphism is probably worse than simple if statements.
If you want to sell a course on SOLID principles and you need a catchy motto, say something weird. Our lizard brains have a tendency to identify and remember weird.
@@markjivko The large discrepancy in speed between memory and processors means everything that needs best performance, needs to take that into account.
This means favoring arrays, group data together that gets accessed together, high information density data-structures, avoid unpredictable branches in inner loops.
So less per-object thinking and more per-set/array thinking. Because in reality we hardly ever need to act on just one thing and nearly always need to do it for a large set of things.
This works because modern processors deal with the memory/CPU speed discrepancy using caches and various prediction/prefetching hardware.
It is easy to predict + fetch the memory for the next/previous element in an array. So linearly accessing the array is more efficient than some fancy structure that in theory requires less steps to do the same actions.
As for polymorphism, that is just one way things can become unpredictable for a CPU. If an array contains all objects of the same class (all dog/cats, whatever), it wont really hurt performance. Because the pattern is predictable. If an array however contains a random mixture of both, then performance will suffer or even tank.
The examples on the anti-if programming website are basically examples by people who never heard of guard clauses.
Also, I'm still wondering why they chose accordions to represent their single question FAQ.
Exactly. The "smelse" example is just the Guard Clause implemented within a while block.
That lonely FAQ question in an accordion just shows poor UI planning.
But if you want to take it one step further, it confirms that the author prefers complexity over simplicity. Polymorphism over simple if statements. Design patterns and expensive OOP over "simple" functional programming.
In my opinion simplicity is always a desideratum in Software Engineering. But hey, I didn't "pioneer TDD" or whatever.
switch case for the win
agreed but does anyone know why the syntax for switch is so god awful disgusting in seemingly every language? is there a language where a switch feels good to write?
I think that's by design, so you use it less 😂
@@forasagorust and zig have a decent syntax. The problem with switches in a language like c is that is uses label syntax to handle each case and you have to break out of the switch after every one of them. That syntax looks very out of place.
In languages like zig you can just:
switch (x) {
42 => {
// Your logic
},
// other cases...
else => {}
}
It really depends. If you have 2 condition it literally doesn't matter. They're both branching. No performance gains.
@@maksymiliank5135 pattern matching is not magic. It's just pushing the responsibility of deciding whether to use if-else or switches to the compiler.
Subscribed
❤️
What do you think about fp-ts
do { } while(false) thats good LOL
Now I am not a PHP guy, more low level, but I don't see why you do not replace the if while false with a function and the breaks with returns. In both cases they should compile down to jumps, but the latter is not going to clutter your stack frame with temporaries.
The "do while false" approach is just a flavor of Guard Clause.
I prefer it because it allows me to have only one return statement per function - respecting the "single input, single output" principle.
I know the "single return per function" preference is controversial, so I did not mention it in this one. Maybe I'll go over it in some future video.
Regarding the jumps in PHP - I have zero clue whether a break is more "optimal" than a return. I would bet that there's no significant difference between the two at any scale.
Remember that PHP is a scripting language - code is interpreted, not compiled.
@@markjivko
Thanks for the well thought out reply. Earned a sub.
I was under the impression most production deployments of php had JIT compilation these days, so it would apply to hotpath code at least.
I am absolutely interested in your single return statement per function preference. I've actually never heard that before, and I am not sure if its a matter of code style or maybe something PHP does that you are optimizing around?
Because the downside I see of what you did here, assuming the JIT is not smart enough to optimize it out, is introduce a pointless branching conditional at the end.
Is it not possible to break out of a block that is not a loop in PHP? I know in like C or zig or rust I can create a named block and break out of it.
can i use smelse in not smell programming language? or it's php only approach
The guard clause using do while(false) can be implemented in most programming languages, even the stinky ones.
Why the "do while false" when you can return early?
Great question!
Returning early is technically called "The Guard Clause".
The "do-while-false" structure is just a flavor of the guard clause with breaks instead of returns.
I prefer this approach because it allows me to have only 1 return statement per function.
This is a personal preference, of course, and not something that should be considered best practice.
I like to look at functions as SISO - single input, single output.
Functions (usually) have only 1 set of parameters, and that is the "input".
Having only 1 return statement at the end of the function just feels right to me.
Obviously, "impure" functions have more than 1 input: arguments, use() statement, globals and superglobals etc.
($input) => {
$output = 0;
do { /* change output */ } while (false);
return $output;
};
I just prefer the simplicity of SISO.
@@markjivko I like it.
do ... while(false) looks worse than a goto. I understand the idea behind it and I think it is nice but it can be solved in a much better way in most modern programming languages with if/switch/blocks which can be evaluated as expressions.
E.g. in zig:
const result1 = if (some condition) value1 else if (some other contition) value2 else value3;
// its like a ternary operator with better chaining syntax
const result2 = switch (some_enum) {
enum_variant1 => value1,
enum_variabt2 => value2,
else => default_value,
};
Breaking out of a labelled block scope with a value
const result3 = blk_lbl: {
// some common logic
if (some_condition) break :blk_lbl value1;
break :blk_lbl default_value;
};
I have mixed feelings about the ternary operator. Kind of makes sense in react components, not really easy on the eyes otherwise.
As always in SWE, "it depends".
@@markjivko Ternary is useful in Typescript for `ArkType` codebase :) It is simple and good until it is not :) Agreed on it is controversial! The `prettier` team spent lost of time to format it correctly when it breaks to a new line!
ok, i have the diploma. where do i send my $2200?
😂
great video! just subbed
Awesome thank you!