Hacker News Reader

Comment by anc2020 | Hacker News Reader

anc2020

I really don't get it, what does this guy mean by 100% pure functional programming?

Because we all know already that a program needs to print values or "do" something to be useful, so in that way no program is ever 100% pure - is that what he's talking about?

Or is he talking about 100% pure functional languages which allow functional ways of writing IO code, like Haskell?

In Haskell can't you still program nearly 100% imperatively, just by wrapping stuff in the IO mondad?

    mysquare  x = x * x
    mysquarer x = do
                    putStrLn "Hey look, it squared"
                    return (mysquare x)
    
    main = do
             putStrLn "Starting program..."
             x' <- mysquarer 9
             putStrLn (show x')

Can't he just write his program like that?

Or is he just arguing that we should write programs in functional languages but just with an imperative style (no points-free and simple use of IO)?

View on HN

Monads don't mean "impure," by the way.

What he means is that purity is more of a curse than a blessing. That the pure approach is not a good way to think about the problem. That you should use purity as a tool, but not dogma.

What I'm arguing is that you can still think and write with an imperative style using the IO monad if you want, so I'm not sure what the issue is.

Edit: As an aside, I already know that "Monad" doesn't mean impure (having implemented an IO monad in my spare time to find out) and that was implied when I said "100% pure functional [...] like Haskell".

They are implemented purely, nonetheless they do allow side-effect (impure) programming.

His issue is precisely with things like the IO monad. At least that's how I parse this sentence:

"what's often a tremendous puzzle in Erlang (or Haskell) turns into straightforward code in Python or Perl or even C." (http://prog21.dadgum.com/54.html)

In my limited experience, the type-checking constraints in haskell make programs using monads unnecessarily hard to change. I just assumed I didn't know what I was doing; it's interesting that James Hague is agreeing with a lot more knowledge and experience.

If you do it wrong, sure. If you use a newtype alias instead of the raw underlying type, it's very easy to change things around.

Good suggestion, thanks.

Please correct me if I'm wrong, but my understanding is that most Haskell code doesn't generate values, but "thunks" that evaluate to values if needed.

When you write

  x = 4 + 5

you aren't setting x to 9, but creating a thunk that evaluates 4 + 5 at runtime. An Integer is a thunk that returns an integer and has no other effects. An IO Integer is one that does some I/O before returning that integer.

As I understand it, the only function that has the power to "do" anything (computation or IO) undernormal circumstances is main, which always has type IO ().

I think you are correct that the language does think of all expressions in terms of thunks, but I'm guessing `4 + 5` won't actually be run at run-time!

Since it's pure a decent compiler should be able to simply replace any `x` with the number 9 - correct me if I'm wrong :)

Any primitive (C code) however won't run until run-time, which is probably the pressing reason putStr doesn't run until run-time (and that's a good thing :)

This is true, but not really relevant to the original article or the comment you are replying to.

When you sequence computations with >>=, like the grandparent does, you generally evaluate the left side of the operation before running the computation. That is the point of monads; sequencing computations and controlling the order of evaluation. Sine the rhs depends on the lhs, the sequence is "evaluate lhs completely", "evaluate rhs completely", and so on.

Reply on news.ycombinator.com