Destroy All Ifs – A Perspective from Functional Programming • Hacker News Board

Re: Destroy All Ifs – A Perspective from Functional Programming

#161

Post by andrewaylett » Sun, Jul 17, 2016, 12:59 PM UTC

eru wrote: post #133

dwb wrote: post #37

Earlier quoted context omitted.

Absolutely, but I'd also add that what works in one language/environment may not work in another. I wouldn't be surprised if writing Haskell-style code in Python didn't work out that well, for example!

I have tried. Two things get in the way quickly, and that's even just expressing thing, not even looking at performance yet: * Python standard library functions, especially the ones on dicts, mutate and don't return the new dictionary. * Python's syntax for creating functions is awkward: lambdas are cumbersome, and so are the operator package and eg functools.partial; there's no really convenient way to compose funct…

Your first point is actually something I really like about Python's API design: in general, methods operating on collections either mutate the collection /or/ they return it. So it's clear at the point of use whether you're dealing with the same object or a new one.

This is something that bugs me about the fluent builder pattern in Java -- continuing to return `this` until suddenly you don't any more, and you can't re-use 'intermediate' values because they're actually all the same object.

Re: Destroy All Ifs – A Perspective from Functional Programming

#162

Post by ta0967 » Sun, Jul 17, 2016, 1:25 PM UTC

drauh wrote: post #118

oliv__ wrote: post #81

It’s no wonder that conditionals (and with them, booleans) are so widely despised! They are?

Granted, I'm a mostly self-taught programmer, but I would have thought that if something appears in formal logic,[0] it should have an analog in a programming language. Even standard algorithms like quicksort[1] use conditionals. And, while I can see how massive switch statements suck, normal conditionals are common in everyday life: "If they don't have a dark roast coffee, get me a medium roast." All of which is to…

> normal conditionals are common in everyday life: "If they don't have a dark roast coffee, get me a medium roast."

"They had dark roast so I got you nothing as requested."

IOW, this program is either incomplete or wrong. Cf. "Get me the darkest roast they have." - ifless, concise, robust.

Re: Destroy All Ifs – A Perspective from Functional Programming

#163

Post by qwertyuiop924 » Sun, Jul 17, 2016, 1:30 PM UTC

eru wrote: post #129

qwertyuiop924 wrote: post #36

This is, as many commenters have noted, just another overzealous programming doctrine. Just like 'GOTO considered harmful.' Here's the deal: if is a flow control primitive. Just like goto and while. If (heh) that primitive isn't high-level enough to handle the problem you are facing, it is incumbent upon you as a programmer to use another, higher level construct. That construct may be pattern matching, it may be poly…

Not all control-flow primitives are necessary. Eg Haskell and Scheme get by without 'while' and 'goto'. Haskell would do just fine without a built-in 'if': you can define 'if' as a function via pattern matching. Given that perspective, the article would be a call to use more expressive types than Booleans to match on---and in lots of cases not to match at all, but provide what would be the result of the match as an a…

Scheme and Haskell have other primitives that take the place of while and goto.

But yes, using more expressive match types or parameters is a good idea. As for providing the result as an argument, that can be a good pattern, but isn't always practical. Note what I said in my original comment about using your own discretion.

Re: Destroy All Ifs – A Perspective from Functional Programming

#164

Post by harveywi » Sun, Jul 17, 2016, 1:32 PM UTC

eru wrote: post #134

AstroJetson wrote: post #23

Earlier quoted context omitted.

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…

What's the difference between multiple return values and returning a tuple? (Apart from that languages with multiple return values tend to have some special syntax for binding only the first few members of the returned tuple?)

The difference, in terms of type theory, is that a tuple is a product type [1] but a type representing multiple possible return values (to represent different outcomes) would be encoded using a sum type [2].

[1] https://en.wikipedia.org/wiki/Product_type

[2] https://en.wikipedia.org/wiki/Tagged_union

Re: Destroy All Ifs – A Perspective from Functional Programming

#165

Post by sebastianconcpt » Sun, Jul 17, 2016, 1:53 PM UTC

Less if is better, I agree on that. Lamdas technique is interesting because they "encapsulete" a specific case. In OOP this is achieved by using polymorphism on the objects instantiated for the right case. Right?

Re: Destroy All Ifs – A Perspective from Functional Programming

#166

Post by biocomputation » Sun, Jul 17, 2016, 2:16 PM UTC

bunderbunder wrote: post #56

unsignedqword wrote: post #32

Earlier quoted context omitted.

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…

You are totally right.

As an example, long if/else chains that check state can mean that you need another object, or another virtual function, or some other niblet of orchestration.

Likewise, I'm not really impressed by the anti-if campaign. At some point, abstractions cause the exact same problem they were designed to solve, and produce code that is difficult to reason about or change.

Re: Destroy All Ifs – A Perspective from Functional Programming

#167

Post by kmiroslav » Sun, Jul 17, 2016, 2:21 PM UTC

SatvikBeri wrote: post #155

kmiroslav wrote: post #78

Earlier quoted context omitted.

Groovy and Kotlin use the implicit "it" parameter for lambdas that take just one parameter, which is very convenient: listOf(1, 2, 3, 4).filter { it % 2 == 0 }

Scala allows underscores, and sequential underscores refer to the next element, so you can do e.g. list(1, 2, 3, 4).reduce(_ + _) == 10

Doesn't that make the parameter anonymous, though? Can you println that _ and see the value of the current element?

Re: Destroy All Ifs – A Perspective from Functional Programming

#168

Post by jasode » Sun, Jul 17, 2016, 2:42 PM UTC

Hermel wrote: post #117

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 title says "destroy all ifs". The author already did take the idea to the extreme himself.

I can't read the author's mind and can't speak for him but I don't think each word (especially the word "all") is meant to be parsed literally.

Here's another website called "Destroy All Software" using a similar phrase: https://www.destroyallsoftware.com/blog

Gary Bernhardt obviously doesn't advocate removing all software from the face of the Earth. Also notice that it includes blog titles with more bombastic titles:

  "One Base Class to Rule Them All"
  "Burn Your Controllers"

Those are probably not meant to be interpreted literally. There really is no single universal class that can be used for all cases in every circumstance. Instead of parsing it literally, it may be a riff on LOTR "the one ring to rule them all."

Likewise, don't eliminate your controllers because he said it's universal advice. Maybe the title is a riff on Cortez "burn your ships" or some other cultural meme like women's liberation of "burn your bra."

Re: Destroy All Ifs – A Perspective from Functional Programming

#169

Post by douche » Sun, Jul 17, 2016, 2:44 PM UTC

tome wrote: post #151

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…

#destroyallifs #notallifs

#allifsmatter

Re: Destroy All Ifs – A Perspective from Functional Programming

#170

Post by bunderbunder » Sun, Jul 17, 2016, 3:23 PM UTC

thaumasiotes wrote: post #142

bunderbunder wrote: post #80

Earlier quoted context omitted.

All valid points. If you're going to do this sort of thing with much success, you really need to have a language with a fairly powerful type system. If function pointers are your only option for higher-order programming, I wouldn't even try. First class functions or interface polymorphism help, but I'd also want to have a language that makes it relatively easy to create (and enforce) types so that your extension poin…

What distinction are you drawing between "first-class functions" and "function pointers"?

About the same distinction as I'd draw between an integer and a pointer to an integer.