Destroy All Ifs – A Perspective from Functional Programming

Post by smallnamespace » Sun, Jul 17, 2016, 3:22 AM UTC

chenglou wrote: post #89

jake-low wrote: post #85

Earlier quoted context omitted.

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.

Post by smilekzs » Sun, Jul 17, 2016, 3:46 AM UTC

kmiroslav wrote: post #78

MichaelGG wrote: post #70

Earlier quoted context omitted.

The annoying part there is the repeated "|x| x.". Rust should have syntax to reference a method of an object, instead of having to write a wrapper. So it'd look like .map_err(???.to_string()).

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 }

Post by Rusky » Sun, Jul 17, 2016, 3:55 AM UTC

MichaelGG wrote: post #70

Animats wrote: post #6

The idea that each type has its own control flow primitives is bothersome. It's taken over Rust: argv.nth(1) .ok_or("Please give at least one argument".to_owned()) .and_then(|arg| arg.parse:: ().map_err(|err| err.to_string())) .map(|n| 2 * n) I'm waiting for date.if_weekday(|arg| ...) Reading this kind of thing is hard. All those subexpressions are nameless, and usually comment-less. This isn't pure functional progra…

The annoying part there is the repeated "|x| x.". Rust should have syntax to reference a method of an object, instead of having to write a wrapper. So it'd look like .map_err(???.to_string()).

Post by l_dopa » Sun, Jul 17, 2016, 4:19 AM UTC

CamperBob2 wrote: post #47

dahart wrote: post #14

I 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…

Post by mshenfield » Sun, Jul 17, 2016, 4:48 AM UTC

buffyoda wrote: post #44

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…

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…

  match caseInsensitive contains