It’s no wonder that conditionals (and with them, booleans) are so widely despised!
Destroy All Ifs – A Perspective from Functional Programming
81–90 of 226 posts
Re: Destroy All Ifs – A Perspective from Functional Programming
#82I'm surprised that the article and none of the comments so far mentioned the "Expression Problem": http://c2.com/cgi/wiki?ExpressionProblem
Basically, if you structure the control flow in object oriented style (or church encoding...) then its easy to extend your program with new "classes" but if you want to add a new methods then you must go back and rewrite all your classes. On the other hand, if you use if-statements (or switch or pattern matching ...) then its hard to add new "classes" but its very easy to add new "methods".
I'm a bit disappointed that this isn't totally common knowledge by now. I think its because until recently pattern matching and algebraic data types (a more robust alternative to switch statements) were a niche functional programming feature and because "expression problem" is not a very catchy name.
Re: Destroy All Ifs – A Perspective from Functional Programming
#83I read everything I could find on the Anti-IF site and didn't understand what the mission is exactly. They qualify and mention they want to remove the bad and dangerous IFs, but I couldn't find examples that differentiate between bad ones and good ones -- are there good ones according to this campaign? I like using functional as much as anyone, and removing branching often does make the code clearer and remove the po…
I read everything I could find on the Anti-IF site and didn't understand what the mission is exactly. I have a similar problem, in that every time I try to understand the perspective of functional-programming advocates, I find that the authors always seem to illustrate their points with examples like this: match :: String -> Boolean -> Boolean -> String -> Bool match pattern ignoreCase globalMatch target = ... If I'm…
bool match(char *pattern, bool ignoreCase, bool globalMatch, char *target) { ...Re: Destroy All Ifs – A Perspective from Functional Programming
#84Define 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…
A church encoded boolean is precisely isomorphic to every language's standard booleans (modulo strictness, perhaps) and doesn't offer any benefits; you're still forking the program based on the information content of a single bit. Let's take the following function invocation, which can be expressed with Boolean literals or Church encoded booleans, I don't care: match true false If you want to determine the significan…
since I'm not a fp expert what about a function like
ctx.arc(10, 20, 30, 0, 6.28, false);
Re: Destroy All Ifs – A Perspective from Functional Programming
#85I'm surprised that the article and none of the comments so far mentioned the "Expression Problem": http://c2.com/cgi/wiki?ExpressionProblem Basically, if you structure the control flow in object oriented style (or church encoding...) then its easy to extend your program with new "classes" but if you want to add a new methods then you must go back and rewrite all your classes. On the other hand, if you use if-statemen…
I was familiar with the problem but didn't have a name for it; thanks for providing me with one.
What kind of work has there been on creating programming paradigms that make it easy to both add new types and new methods? Is it a CAP-theorem-type problem where every solution is a trade-off, or is there a way to have your cake and eat it too?
Re: Destroy All Ifs – A Perspective from Functional Programming
#86Earlier quoted context omitted.
A church encoded boolean is precisely isomorphic to every language's standard booleans (modulo strictness, perhaps) and doesn't offer any benefits; you're still forking the program based on the information content of a single bit. Let's take the following function invocation, which can be expressed with Boolean literals or Church encoded booleans, I don't care: match true false If you want to determine the significan…
since I'm not a fp expert what about a function like ctx.arc(10, 20, 30, 0, 6.28, false); There's nothing special about boolean. How do you encode all of those above into types in fp so that it's impossible to get them wrong and so they're self documenting? I hope you're not suggesting there be a horizontalFloat type and a verticalFloat type or are you?
How about keyword parameters...
ctx.arc(center=Point(10,20), radius=30, beginAngle=0, endAngle=6.28, Clockwise);
https://stackoverflow.com/questions/107243/are-units-of-meas...
ctx.arc(center=Point(10cm,20cm), radius=30mm, beginAngle=0rad, endAngle=6.28rad, Clockwise);Re: Destroy All Ifs – A Perspective from Functional Programming
#87Isn't this exactly the Smalltalk way? In ST what looks like if-statements actually are messages passed to instances of Boolean, with lambdas (in Smalltalk: BlockClosures) as argument. The boolean then makes the decision whether it will evaluate the lambda or not.
Re: Destroy All Ifs – A Perspective from Functional Programming
#88The author seems to ignore the fact that passing lambdas like this merely changes where the IF or SWITCH statement is made. I can agree that passing functions instead of booleans is better and more general. But pretending that IF/SWITCH are thus avoided, is delusional. For instance, at some point there will be a decision made whether the string matching must be case sensitive or not. If the program can do both at run…
Indeed, that's the whole point of inversion of control, is pulling the control out of the caller and into the callee. That's the primary reasoning benefit of functional programming.
I see no benefit to that. It makes more work for the caller. I want that function to do something for me and I want the leadt amount of unnecessary work on my side. Just like a good boss who delegates.
Re: Destroy All Ifs – A Perspective from Functional Programming
#89I'm surprised that the article and none of the comments so far mentioned the "Expression Problem": http://c2.com/cgi/wiki?ExpressionProblem Basically, if you structure the control flow in object oriented style (or church encoding...) then its easy to extend your program with new "classes" but if you want to add a new methods then you must go back and rewrite all your classes. On the other hand, if you use if-statemen…
I was familiar with the problem but didn't have a name for it; thanks for providing me with one. What kind of work has there been on creating programming paradigms that make it easy to both add new types and new methods? Is it a CAP-theorem-type problem where every solution is a trade-off, or is there a way to have your cake and eat it too?
There are languages (libraries) that solve it. For reference, check Clojure's multimethods and OCaml's polymorphic variants.
Re: Destroy All Ifs – A Perspective from Functional Programming
#90I'm surprised that the article and none of the comments so far mentioned the "Expression Problem": http://c2.com/cgi/wiki?ExpressionProblem Basically, if you structure the control flow in object oriented style (or church encoding...) then its easy to extend your program with new "classes" but if you want to add a new methods then you must go back and rewrite all your classes. On the other hand, if you use if-statemen…
I was familiar with the problem but didn't have a name for it; thanks for providing me with one. What kind of work has there been on creating programming paradigms that make it easy to both add new types and new methods? Is it a CAP-theorem-type problem where every solution is a trade-off, or is there a way to have your cake and eat it too?
There is plenty of research out there about trying to solve the expression problem and the wikipedia article has links to some of them: https://en.wikipedia.org/wiki/Expression_problem
That said, there is a complexity and readability trade-off (that is hard to quantify) because these more flexible programming patterns that can solve the expression problem are more complicated than plain method dispatching or switch statements.