The Anti-If Campaign • Hacker News Board

Re: The Anti-If Campaign

#21

Post by stcredzero » Thu, Jun 25, 2009, 4:14 PM UTC

Confusion wrote: post #16

stcredzero wrote: post #14

Earlier quoted context omitted.

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.

Do not attribute to malice what can be equally well explained by stupidity.

Malice has a better chance of sustained profitability.

EDIT: This is a clue to bad intent. "Follow the money!"

Re: The Anti-If Campaign

#22

Post by stavrianos » Thu, Jun 25, 2009, 4:28 PM UTC

stcredzero wrote: post #21

Confusion wrote: post #16

Earlier quoted context omitted.

Do not attribute to malice what can be equally well explained by stupidity.

Malice has a better chance of sustained profitability. EDIT: This is a clue to bad intent. "Follow the money!"

and yet, the world over, people are still both basically decent and basically stupid.

Edit: correlation?

Re: The Anti-If Campaign

#23

Post by calambrac » Thu, Jun 25, 2009, 4:34 PM UTC

tptacek wrote: post #10

calambrac wrote: post #3

Don't solve with conditionals that which can be solved by your language's dispatch mechanism.

Don't solve with 15 minutes that which you can bill your client 80 hours for.

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.

Re: The Anti-If Campaign

#24

Post by jrandom » Thu, Jun 25, 2009, 4:50 PM UTC

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

Re: The Anti-If Campaign

#25

Post by wglb » Thu, Jun 25, 2009, 4:57 PM UTC

These days, I tend to use COND rather than IF.

Ah, but the page implies use bunches of teeny classes. Was that what Alan Kay had in mind when he coined "Object Oriented Programming"?

Re: The Anti-If Campaign

#26

Post by gabeybaby » Thu, Jun 25, 2009, 5:33 PM UTC

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.

Re: The Anti-If Campaign

#27

Post by davidw » Thu, Jun 25, 2009, 7:48 PM UTC

scott_s wrote: post #13

tptacek wrote: post #11

Earlier quoted context omitted.

It's not about type fields and tag-and-switch. It's about the "if" statement. Let's be clear about how batsh*t crazy this messaging is.

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.