calambrac gets it right: 'dispatch'. I though the article was going to be about pattern matching, actually. I guess polymorphism is a sort of pattern matching, but the real thing goes farther.
If you read their content (what little there is), it's type fields that they actually object against. I don't think they're actually saying "remove all ifs from code." If they are, then, yes, that would be batshit crazy. Instead of being crazy, though, I think they're just ineffective at communicating their message.
With pattern matching, you actually end up being able to mostly do away with if and switch statements, so it's not completely as crazy as it sounds. OTOH, sometimes pattern matching involves a lot of "repeating yourself", where you have to retype the function name, and a bunch of arguments, and only one changes.
And don't forget, lots of those 15 minute intervals can add up to serious money. ("Stovepipe" systems.) You can also set up an opportunity to bill for coming later in and "fixing" a seemingly intractable big mess.
"Oh, I see the problem right here, Mr. Client. Your previous consultant used 'if' statements. Here, let me replace that function with 80 new class files. You'll be much more agile!"
I find that the opposite is true: replacing lots of runtime type identification with polymorphism results in placing repeated code in just one place. Don't Repeat Yourself is more agile. Even better: wait until at least the 3rd repetition before refactoring. (But don't wait too long.) This cuts down a lot of unnecessary coding, and leaves the programmer some leeway for good judgment.
In retrospect, my comment sounded like it was reaffirming the article's point, but that's really not how I meant it (snark fail on my part).
I agree with what you're getting at, and I think that the idea of popularizing "AntiIf" as a slogan is really stupid and dangerous. The first eager intern who suggests refactoring some code because "ifs are bad", I'm not a religious man, but God help them.
What I was trying to point out is that the single example they have up right now showing that 'if' is "bad" is dispatching on types, which a good number of languages support out of the box (in other words, it's a strawman). If you're already inspecting types, then they presumably already exist, so there's no additional overhead in using your language's features to get clearer code when you can.
This sort of debate annoys me - not so much because of the potentially fragile design on one side or the perhaps pedantic adherence to OOP principles on the other, but because I know that I could have things like pattern matching and a scarily expressive type system and, well, that'd make a lot of these problems disappear.
This is a joke, right? They're making fun of all the programs you see that have 20 different forests of tiny classes spreading the logic of one function across 45 files, right?
This strikes me as particularly funny as I'm working on a module of code where I had to use a type field and an 'if' statement to get around a dynamic cast that was killing performance.
(Virtual functions were not an option as this was taking place inside an STL '==' comparator.)
I think this "campaign" is aimed at a developer less capable than the crowd we see on HN. I used to work with a whole team of people where OOP is a strange concept. I think the Anti-IF rule can help people think in a more correct fashion if they're confused about Inheritance.
26 comments
[ 2.3 ms ] story [ 66.9 ms ] threadThe idea is just bad.
EDIT: This is a clue to bad intent. "Follow the money!"
Edit: correlation?
I agree with what you're getting at, and I think that the idea of popularizing "AntiIf" as a slogan is really stupid and dangerous. The first eager intern who suggests refactoring some code because "ifs are bad", I'm not a religious man, but God help them.
What I was trying to point out is that the single example they have up right now showing that 'if' is "bad" is dispatching on types, which a good number of languages support out of the box (in other words, it's a strawman). If you're already inspecting types, then they presumably already exist, so there's no additional overhead in using your language's features to get clearer code when you can.
Curse you, Haskell, for making me so bitter!
And after that, we will eliminate source code, because it's too complicated. Everything you need to do can be done with 5x7 index cards.
(Virtual functions were not an option as this was taking place inside an STL '==' comparator.)
Ah, but the page implies use bunches of teeny classes. Was that what Alan Kay had in mind when he coined "Object Oriented Programming"?