Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Destroy All Ifs – A Perspective from Functional Programming

degoes.net

Post reply on HN
Print view View original

51–60 of 226 posts

Re: Destroy All Ifs – A Perspective from Functional Programming

#51

Post by swift »

astazangasta wrote: post #39

Why don't we just treat this like writing? Good writing has one clear imperative: communicate meaningfully the intent of the author to the reader. Good code is no different; it is merely expressive writing in a different language, with, perhaps, greater constraint on its intent. Some people make up rules like "don't use adverbs", or "don't split infinitives", in an effort to write better. But this doesn't necessarily…

I get what you're saying, but that's definitely not what good writing means in the context of, say, poetry, or literary fiction. Programming is best compared to technical writing or cookbooks, I think.

I realize this is one of those irritating "actually," replies, but what can I say, I'm sensitive about this topic. =)

Re: Destroy All Ifs – A Perspective from Functional Programming

#52

Post by nilved »

white-flame wrote: post #19

This whole campaigned is misguided. "Bad IFs" are a code smell, and they're being scapegoated when the real problems are management demanding that simple hackish prototypes & tests be deployed into production, management that doesn't allow time for refactoring, and poor programmers who think that "bad IFs" are good code. But the main site also doesn't do any reasonable job of defining what a "Bad IF" even is. The cru…

If statements are code smells in languages that are not strictly imperative. Is an if statement literally the only option? If not, that's a "Bad If."

Re: Destroy All Ifs – A Perspective from Functional Programming

#53

Post by userbinator »

barrkel wrote: post #5

Define true as a lambda taking two lazy values that returns the first, and false as one that returns the second, and you can turn all booleans into lambdas with no increase in code clarity. The straw man in the post - talking about a case-sensitive matcher that selectively called one of two different functions based on a boolean - is indeed trivially converted into calling a single function passed as an argument, but…

That's one of the downsides of over-abstraction and over-generalization: instead of a tool, a library gives you a box of kit components and you have to assemble the tool yourself.

...and a framework is likely to give you a box of components to build a tool-making factory factory factory...

http://discuss.joelonsoftware.com/?joel.3.219431.12

Re: Destroy All Ifs – A Perspective from Functional Programming

#55

Post by userbinator »

runeks wrote: post #43
lilbobbytables wrote: post #9

Often times when I read about "ideal" ways of programming, I'm curious if it's ever implemented in a production code base built by a team.

Me too. Particularly because every programmer has their own idea of what a "right"/ideal style of programming is. Here, apparently, we must not use conditionals. The more I write code the more I realize that the entire purpose of the code is to have some effect on reality, and the more reliably it can do this, the better the code. I find I code a lot better without design principles, because trying to remember which…

The more I write code the more I realize that the entire purpose of the code is to have some effect on reality, and the more reliably it can do this, the better the code.

Very nicely put. The only "principles" I keep in mind when I write code are simplicity, correctness, and efficiency, and those tend to all be correlated.

Re: Destroy All Ifs – A Perspective from Functional Programming

#56

Post by bunderbunder »

unsignedqword wrote: post #32
rrradical wrote: post #28

Earlier quoted context omitted.

Someone else addressed the details of your counter argument, but I'd like to respond to it generally. It seems like every time someone writes an article on how to write better code, there are responses about how it doesn't make sense when taken to some logical extreme, or some special case, as if that invalidates the argument. (FP techniques in particular seem to provoke this.) But code design is like other design di…

The thing is that the tone of the article seems to suggest taking such an extreme: I mean, an "anti-if " campaign? There's like, only one sentence of concession near the end towards those unconvinced by the argument.

FWIW, I'm pretty unimpressed by the anti-if campaign's website. They've clearly put style over substance. It's a beautiful website, but I spent some time poking through it and I can still only guess at what exactly they're on about. It seems to be something about if-statements being bad, but beyond that it's rather a muddle.

I'm trying to be charitable, though, so let's assume that the core of their idea is something coherent. I'm guessing it's really about something I do think is an important point: How inversion of control is a design pattern that lets you create code that's much easier to manage, because it greatly limits the extent to which certain kinds of decisions need to be federated throughout the codebase.

If that's the case, then real sin (and the article author's) is mistaking if statements for the problem. Conditional branching is not a problem; I think most of us can agree it's an essential operation. The real problem they should be after is poor encapsulation. Where if statements come into it is that, if you've got badly architected code with poor encapsulation, one of the symptoms you'll see is that there will be a proliferation of if-statements that crop up all throughout the code. Every single frobinator will need to stop and check whether the widget it's operating on is a whosit or a whatsit before it can take any sort of action whatsoever. Lord help us if we ever try to introduce wheresits into the system; we'll have to go modify 50 different files so we can replace all those if-statements with switch statements.

It's probably nowhere near as fun to write an article that advocates a high level design methodology as it is to write an article that makes a bold contrarian claim like "If statements bad", though.

Re: Destroy All Ifs – A Perspective from Functional Programming

#57

Post by chongli »

AstroJetson wrote: post #23
dwrensha wrote: post #18

I recommend Bob Harper's essay on "boolean blindness": https://existentialtype.wordpress.com/2011/03/15/boolean-bli... An excerpt: > The problem is computing the bit in the first place. Having done so, you have blinded yourself by reducing the information you have at hand to a bit, and then trying to recover that information later by remembering the provenance of that bit.

Thats why you use Lua, it lets you have multiple return values. So you can get a boolean back to let you know if the strings were the same, an int to know where they ceased matching and a boolean to let you know if they are case different. It's then up to the programmer to decide how much enlightenment they want. The destroy all IF reminds me of GOTO considered harmful of the 70's. There are other ways to fix the pro…

That still has the problem of boolean blindness. The boolean you get back doesn't tell you what it means, you have to go looking for that information.

Re: Destroy All Ifs – A Perspective from Functional Programming

#60

Post by kazinator »

Problem is, a decision has to be made somewhere about which function to pass into that "if-free" block of code. The if-like decision has just moved elsewhere. That is a win if it reduces duplication: if a lambda can be decided upon and then used in several places, that's better than making the same Boolean decision in those several places.

Programs that are full of function indirection aren't necessarily easier to understand than ones which are full of boolean conditions and if.

The call graph is harder to trace. What does this call? Oh, it calls something passed in as an argument. Now you have to know what calls here if you want to know what is called from here.

A few days ago, there was this HN submission: https://news.ycombinator.com/item?id=12092107 "The Power of Ten – Rules for Developing Safety Critical Code"

One of the rules is: no function pointers. Rationale: Function pointers, similarly, can seriously restrict the types of checks that can be performed by static analyzers and should only be used if there is a strong justification for their use, and ideally alternate means are provided to assist tool-based checkers determine flow of control and function call hierarchies. For instance, if function pointers are used, it can become impossible for a tool to prove absence of recursion, so alternate guarantees would have to be provided to make up for this loss in analytical capabilities.

Post reply on HN