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

111–120 of 226 posts

Re: Destroy All Ifs – A Perspective from Functional Programming

#111

Post by steveklabnik »

Animats wrote: post #11
koenigdavidmj wrote: post #7

Earlier quoted context omitted.

Most of this should be obviated when the ? operator is ready. But until then, there is no primitive for 'work on the type you wrapped in Option, short-circuiting and returning None at the first sign of failure', so it has to be done in the library.

If this is an accepted idiom, people will be using it for years to come. Sometimes only to be cool. With "?" and "try!()", Rust is sort of emulating exceptions in a weird way.

  >  Rust is sort of emulating exceptions in a weird way.
Except at the level Rust operates at, the code generation for exceptions vs. not is a thing. Not relying on landing pads, etc, is a thing people care about, and is why there's significant difference between return values vs exceptions can matter, even if at some higher semantic level, they're roughly equivalent.

Re: Destroy All Ifs – A Perspective from Functional Programming

#113

Post by externalreality »

I tried to ask the author the follow: (kept getting deleted as spam). Perhaps he will see it here but its unlikely due to the fact there are many comments as it is.

Hi John,

Are you familiar with Jackson Structured Programming?

https://en.wikipedia.org/wiki/Jackson_structured_programming

Notice how the focus in on using control flows that are derived from the structure of the data being processed and the processed data. Notice how the JSP derived solution in the Wikipedia example lack if-statements.

Pattern matching allows ones to map control flow to the structure of data. What are your thoughts on that? I think inversion of control has other benefits but I don't think it has much to do with elimination of `if` conditionals, the pattern matching does that.

Also, I noticed one thing:

In the article you mention `doX :: State -> IO ()` as being called for its value and suggest that if you ignore the value the function call has no effect. Isn't it the case that a function of that type usually denotes that one is calling the function for its effect and not for any return value? Its value is just an unevaluated `IO ()`.

Re: Destroy All Ifs – A Perspective from Functional Programming

#114

Post by beisner »

sqldba wrote: post #112

Ummm. Many common day to day languages don't use lambdas. Also I have no idea what they are. So - yeah I don't think you can just replace if so easily.

Lambas are actually supported in most popular languages: C++, Java, C#, Go, JavaScript, even C. Sometimes they're called function literals or anonymous functions, but basically they involve creating a function without a name that can be passed around and executed. In some languages (Haskell, OCaml, etc) the anonymous functions can be extremely generic, whereas they are sometimes a bit less flexible in other languages. If you want a quick intro you can find one here: http://stackoverflow.com/questions/16501/what-is-a-lambda-fu...

Re: Destroy All Ifs – A Perspective from Functional Programming

#115

Post by glibgil »

jake-low wrote: post #85
ufo wrote: post #82

I'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?

The comments in this thread and the link to ltu in this thread talk about one of the simplest and most elegant solutions to the expression problem https://m.reddit.com/r/haskell/comments/4gjf7g/is_solving_th...

Re: Destroy All Ifs – A Perspective from Functional Programming

#116

Post by mbrock »

externalreality wrote: post #113

I tried to ask the author the follow: (kept getting deleted as spam). Perhaps he will see it here but its unlikely due to the fact there are many comments as it is. Hi John, Are you familiar with Jackson Structured Programming? https://en.wikipedia.org/wiki/Jackson_structured_programming Notice how the focus in on using control flows that are derived from the structure of the data being processed and the processed da…

The return value of the function is a description of an effect. Calling the function doesn't cause the effect to happen. That's why you could, for example, call the function many times and get a list of IO actions which you then execute in parallel or backwards or whatever. Hence "inversion of control".

Re: Destroy All Ifs – A Perspective from Functional Programming

#117

Post by Hermel »

rrradical wrote: post #28
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…

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.

Re: Destroy All Ifs – A Perspective from Functional Programming

#118

Post by drauh »

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 say, I really don't understand what he's getting at. The last example he gave seemed to make things even more complicated, and it basically renamed "true" and "false" to more descriptive things (forRealOptions, dryRunOptions), which seems to my untrained eye to boil down to the moral equivalent of a C enum.

[0] https://en.wikipedia.org/wiki/Material_conditional

[1] https://en.wikipedia.org/wiki/Quicksort#Algorithm

Re: Destroy All Ifs – A Perspective from Functional Programming

#119

Post by [deleted] »

mbrock wrote: post #116
externalreality wrote: post #113

I tried to ask the author the follow: (kept getting deleted as spam). Perhaps he will see it here but its unlikely due to the fact there are many comments as it is. Hi John, Are you familiar with Jackson Structured Programming? https://en.wikipedia.org/wiki/Jackson_structured_programming Notice how the focus in on using control flows that are derived from the structure of the data being processed and the processed da…

The return value of the function is a description of an effect. Calling the function doesn't cause the effect to happen. That's why you could, for example, call the function many times and get a list of IO actions which you then execute in parallel or backwards or whatever. Hence "inversion of control".

[deleted]

Re: Destroy All Ifs – A Perspective from Functional Programming

#120

Post by externalreality »

mbrock wrote: post #116
externalreality wrote: post #113

I tried to ask the author the follow: (kept getting deleted as spam). Perhaps he will see it here but its unlikely due to the fact there are many comments as it is. Hi John, Are you familiar with Jackson Structured Programming? https://en.wikipedia.org/wiki/Jackson_structured_programming Notice how the focus in on using control flows that are derived from the structure of the data being processed and the processed da…

The return value of the function is a description of an effect. Calling the function doesn't cause the effect to happen. That's why you could, for example, call the function many times and get a list of IO actions which you then execute in parallel or backwards or whatever. Hence "inversion of control".

I was debating whether on not to put that last sentence because I knew that it would lead to a technical discussion that was aside from the meaning of the question. My question is more -- why choose an `IO ()` as an example of something being called for its value (especially since the article isn't aimed at a Haskell audience)
Post reply on HN