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

191–200 of 226 posts

Re: Destroy All Ifs – A Perspective from Functional Programming

#191

Post by wyager »

cousin_it wrote: post #186
wyager wrote: post #181

Earlier quoted context omitted.

??? Haskell absolutely has tail recursion; foldl just evaluates non-strictly and therefore can leave thunks in memory. This is fine for e.g. reversing a cons-list. Regardless, it is tail recursive (and uses constant stack space). foldl' is also tail recursive and has strict semantics. Structural recursion can't be guaranteed to terminate in any language that supports codata unless you have some sort of totality check…

The point of tail recursion is using constant space, not constant stack space (does Haskell even have a stack?) Anyways, the Haskell spec allows foldl' to use linear space just like its lazier counterparts. The fact that it uses constant space is an implementation detail of GHC. Reference: https://github.com/quchen/articles/blob/master/fbut.md#seq-d... Structural recursion always terminates in SML. Supporting infinit…

Tail recursion can't use constant space if it's strictly generating another data structure of the same size. That doesn't even make sense.

Interesting fact about foldl'. Regardless, in practice it is strict and tail recursive. As I mentioned earlier, this does not mean the same thing as constant space unless the reduction function returns a fixed size result.

Yes, you can guarantee that a linked list in Java is finite because Java does not support codata.

Haskell's tail call recursion is also often optimized to be allocation-free, unless, again, it is generating some data structure.

Re: Destroy All Ifs – A Perspective from Functional Programming

#192

Post by _asummers »

sgt101 wrote: post #139
rrradical wrote: post #128

Earlier quoted context omitted.

It's true. Personally, I took that to be a bit tongue in cheek. I would compare it to "GOTO Considered Harmful"-- where the author wants you to imagine a world without such a technique in order to expand your abilities. (Even though there are probably edge cases where such usage is justifiable.)

The stance is rather different though - "GOTO Considered Harmful" as a phrase is both inviting a discussion and making a limited statement. "Destroy all ifs" is definitive; the argument is over at the end of the phrase and there will be no negotiation or concessions. I know that this is trivial in this case, but I think it would help discourse in the world generally if we could move away from this kind of position ta…

"Ifs considered suboptimal" carries the spirit of Dijkstra and the general argument of the anti if folks.

Re: Destroy All Ifs – A Perspective from Functional Programming

#193

Post by tome »

cousin_it wrote: post #186
wyager wrote: post #181

Earlier quoted context omitted.

??? Haskell absolutely has tail recursion; foldl just evaluates non-strictly and therefore can leave thunks in memory. This is fine for e.g. reversing a cons-list. Regardless, it is tail recursive (and uses constant stack space). foldl' is also tail recursive and has strict semantics. Structural recursion can't be guaranteed to terminate in any language that supports codata unless you have some sort of totality check…

The point of tail recursion is using constant space, not constant stack space (does Haskell even have a stack?) Anyways, the Haskell spec allows foldl' to use linear space just like its lazier counterparts. The fact that it uses constant space is an implementation detail of GHC. Reference: https://github.com/quchen/articles/blob/master/fbut.md#seq-d... Structural recursion always terminates in SML. Supporting infinit…

> does Haskell even have a stack?

Yes

Re: Destroy All Ifs – A Perspective from Functional Programming

#194

Post by edwintorok »

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.

The OCaml solution with polymorphic variants: http://www.math.nagoya-u.ac.jp/~garrigue/papers/fose2000.htm....

A very good summary of that paper is available here: http://lambda-the-ultimate.org/node/1518#comment-17566

Another alternative based on recursive modules: http://www.math.nagoya-u.ac.jp/~garrigue/papers/#privaterows

Re: Destroy All Ifs – A Perspective from Functional Programming

#195

Post by oliv__ »

ta0967 wrote: post #162
drauh wrote: post #118

Earlier quoted context omitted.

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.

What if I want a vanilla latte instead?

Re: Destroy All Ifs – A Perspective from Functional Programming

#196

Post by vorg »

kmiroslav wrote: post #167
SatvikBeri wrote: post #155

Earlier quoted context omitted.

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?

Use a function that prints then returns its parameter:

  list(1, 2, 3, 4).reduce{print(_) + _} == 10
Use it if you or your language hasn't defined such a function:

  list(1, 2, 3, 4).reduce{it:= _; println(it); it + _} == 10
In fact, any name for it will do.

Re: Destroy All Ifs – A Perspective from Functional Programming

#197

Post by [deleted] »

jasonm23 wrote: post #153
sgt101 wrote: post #139

Earlier quoted context omitted.

The stance is rather different though - "GOTO Considered Harmful" as a phrase is both inviting a discussion and making a limited statement. "Destroy all ifs" is definitive; the argument is over at the end of the phrase and there will be no negotiation or concessions. I know that this is trivial in this case, but I think it would help discourse in the world generally if we could move away from this kind of position ta…

Absolutely. Simply replacing "ifs" with anything else. I think it's clear how this is simply juvenile hyperbolic invective.

[deleted]

Re: Destroy All Ifs – A Perspective from Functional Programming

#198

Post by runeks »

janekm wrote: post #68
runeks wrote: post #43

Earlier quoted context omitted.

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…

Not functional code though. The aim of functional code is to be side-effect free, and affecting reality really gets in the way of that. /snark, but articles like this really do fall into that trap...

I know you're making a joke, so I'm not writing this to correct you, but I'd like to point out that Haskell/pure FP is different not because it denies affecting reality, but because it only offers a one-way interface to affecting reality: it allows you to alter values in reality using pure functions, but it denies you the ability to "pull in" values from reality, into your pure functions.

This paradigm is powerful because it accurately reflects how our universe works: it is possible for a thought to affect reality (through a human being acting on it), but it is not possible to "pull in" an object from reality, into your mind. The only way to form a thought about something is to look at that thing, and try to construct - in your mind - a thought that reflects certain properties of the thing you're looking at. You can't "pull" that thing from reality into your mind, thus creating a thought. No such interface exists in this universe, as far as I'm aware.

It is, however, very possible for a human being to choose to act on a thought, thereby causing the thought to have a side effect. The analog to this in Haskell is applying a pure function to a value in IO. The function is pure, but we can use it to alter a value that resides in IO (reality). Similarly, a thought, in and of itself, does not affect reality (it is pure); it requires a human being to act on it - "apply it to reality" - in order for it to have an effect.

In short: Haskell allows your program to alter reality, but it does not allow reality to alter your program.

Re: Destroy All Ifs – A Perspective from Functional Programming

#199

Post by joeyh »

asQuirreL wrote: post #24

The article seems to advocate type synonyms like the following: type Case = String -> String -- ... type Announcer = String -> IO String I would argue that these are actually much worse than not having type synonyms at all. (String -> String) functions could do anything to your query parameter and text, the type is too coarse, and the inhabitants too opaque for us to reason about them easily. Naming the type suggests…

    data Case = CaseSensitive | CaseInsensative
This is just as efficient as the newtype, and leads to clearer code when matching on the value.

Also, sometimes types you thought only had two inhabitants get a third one added later, which this facilitates.

Re: Destroy All Ifs – A Perspective from Functional Programming

#200

Post by delian66 »

js8 wrote: post #146

The idea that functional programming is a type of inversion of control reminds me of similar idea I had, when comparing OOP and FP. In OOP, you encapsulate data into objects and then pass those around. The data themselves are invisible, they only have interface of methods that you can apply on them. So methods receive data as package on which they can call methods. In FP, in contrast, the data are naked. But instead…

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
Post reply on HN