Hacker News Reader

Comment by bitL | Hacker News Reader

I would suggest the following:

- write all functions related to math/geometry/combinatorics in pure functional style, even better with accompanying mathematical proofs to be sure they are principally sound (you won't avoid problems with floating numbers etc. that way)

- think about using functional programming in parallel/distributed tasks if you can manage communication complexity directly (i.e. this is not handled to you by some opaque, un-debuggable monad)

- write everything else in imperative style of your choice

I/O is the elephant in the room of functional programming, monads are "imperative" hacks to make functional programming useful in any real-world-related way, and most monad tutorials will only confuse you about what they are actually.

View on HN

> monads are "imperative" hacks to make functional programming useful in any real-world-related way

Monads are a quite clever solution to control IO: instead of allowing functions to directly perform IO, allow them to compose a sequence of IO operations and return them, such that you can compose a program which the runtime will then execute.

They're not imperative: they represent programs in a purely functional way, and they don't let you opt out of any of the guarantees a purely functional language provides. And they're not a hack, they fit properly into the type system.

Unlike "mostly functional" programming, use of monadic IO in a purely functional language will force you to cleanly separate IO and computation. Not only does this make a more maintainable program (no side effects everywhere), but you get nice bonuses, like lazy computation.

> and most monad tutorials will only confuse you about what they are actually.

Perhaps because many monad tutorials try to hide how they work, despite this really being quite simple.

> use of monadic IO in a purely functional language will force you to

have `unsafePerformIO` in the language.

GHC has `unsafePerformIO` in order to implement pure abstractions. It's an implementation detail, Haskell proper does not support it, and you wouldn't use it in your code.

> and you wouldn't use it in your code

Speak for yourself. I don't see any value in not using a tool when it's available and seems to do the job:

http://science.raphael.poss.name/haskell-for-ocaml-programme...

Personally I don't believe in 100% pure FP, it's both a pain in the ass and doesn't really give you more than 85% FP already would. Actually, most of the FP world seems to agree: out of many Lisps, Scala, OCaml, SML, F#, Erlang/Elixir etc. only Haskell is that hell-bent on purity. Even things like PureScript are more pragmatic than Haskell in this regard.

Here's a great talk on getting what's best from FP without also taking all the problems: http://www.infoq.com/presentations/functional-pros-cons

> Even things like PureScript are more pragmatic than Haskell in this regard

Interesting. In what way?

> Personally I don't believe in 100% pure FP, it's both a pain in the ass and doesn't really give you more than 85% FP already would.

How so? Having a pure language has some significant benefits, like laziness. Data structures as control flow is awesome.

I've been very excited by many approaches before, then Haskell, and now I'm past it. While pure functional language will force you to cleanly separate computation and IO, with an app big enough you'll find yourself one day in a situation where independent data from 3 different places comes together in a way that the only reasonable way to proceed is to log a warning, tweak the value, and continue the computation. And that's what you'll do in any unpure language. In a pure one, you'll start to think how to redesign the computation to allow this... It's not wrong, but in many cases it's pointless.

> In a pure one, you'll start to think how to redesign the computation to allow this... It's not wrong, but in many cases it's pointless.

Are you sure it's pointless? Having to show I/O in the type signature means you can't end up with accidental side-effects.

In some cases - yes, pointless. You rarely care if a function logs something or not. If you do care, you can still return the log lines as an extra value and use the pure solution. At least you have a choice.

You either add the logs as type annotations, or you run it inside a logging monad (not IO).

I found that as I was learning functional programming, I started changing the way I was writing code even in imperative mode. I was separating things better, programs became more semantic and there are many opportunities to use functional style, but I still think imperative code is faster and easier to write for small functions, up to 20-30 lines of code.

Also, because it is so similar in a way, I learned a new appreciation for unix pipes and the shell syntax for composing programs.

I will continue to learn FP just to upgrade my programming skills.

Monad tutorials are a problem because they try to teach you to play football without first learning to walk. Progressive tutorials/introductions on the category theory constructs leading up to and including monads are better.

do you have any recommendations on such tutorials/introductions that teach category theory?

I found this one quite approachable:

https://hseeberger.wordpress.com/2010/11/25/introduction-to-...

For category theory constructs in a Haskell context, I think the Typeclassopedia [0] is the best thing I've found.

[0] https://wiki.haskell.org/Typeclassopedia

Bartosz Milewski is writing a category theory tutorial, which is in progress:

http://bartoszmilewski.com/2014/10/28/category-theory-for-pr...

The problem is that category theory is "elitist", i.e. most programmers aren't equipped to comprehend even the basics properly if they didn't study theoretical computer science, computability theory, recursion theory etc. or even philosophy :-(

The problem is that 99.9% of the material about Category Theory in existence just forget to talk about two features of it: what is it useful for, and how it relates to mode widely known concepts, like functions.

Haskell is accessible. Just ignore the monad tutorials.

Reply on news.ycombinator.com