Live data from Hacker News

The Anti-If Campaign

antiifcampaign.com

11–20 of 27 posts

Re: The Anti-If Campaign

#11
post #2

Oddly named campaign to promote better use of inheritance. "The Anti-Type Fields Campaign" would be more appropriate and less confusing.

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.

Re: The Anti-If Campaign

#13
post #11
post #2

Oddly named campaign to promote better use of inheritance. "The Anti-Type Fields Campaign" would be more appropriate and less confusing.

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.

Re: The Anti-If Campaign

#14
post #10

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.

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.

Re: The Anti-If Campaign

#15
after vanquishing all if statements, we're going to go after function calls.

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.

Re: The Anti-If Campaign

#16
post #10

Earlier quoted context omitted.

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

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.

Re: The Anti-If Campaign

#17
post #13
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.

I agree with you: it's the messaging that's batsh*t crazy, not the idea.

The idea is just bad.

Re: The Anti-If Campaign

#18
post #10

Earlier quoted context omitted.

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

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!"

Re: The Anti-If Campaign

#19

after vanquishing all if statements, we're going to go after function calls. 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.

First they came for the function definitions, and I said nothing, for I used lambdas.

Re: The Anti-If Campaign

#20
post #18

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.

"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.
Post reply on HN