Hacker News Reader

Comment by uncomputation | Hacker News Reader

Very interesting and well thought out write up on a high level. Shame on me for being surprised at the technical clarity of an astrology app I suppose. On a lower level, I’m interested in how they balance the purity of Haskell with the necessity of a server actually persisting state and dealing with IO.

View on HN

Doing IO stuff is very well-supported in Haskell. Printing to the terminal just looks like:

    main = putStrLn "Hello World"

Doesn’t this “contaminate” the entire calling function though, as in you now have to specify it is impure?

Yes, impurity (or rather the representation thereof) is contagious. This is where the common "functional core, imperative shell" comes into play. You generally try to push side effects to the edge.

There are other approaches you can take too, like encoding your effects in a monad which has a different runtime representation in tests. It's like mocking on steroids with type safety.

Yes, a significant chunk of Haskell code usually does end up living in whatever monad (the context that represents IO computations) the app is using.

This doesn't negate the advantages of tracking effectful code in the type system, and there's still plenty of code that can be pure.

No contamination, main has a type ‘IO ()’. A readline function would be ‘IO String’, so in a way you can think of them as “upon execution, we have this type”, or the “execution wraps this type”. You can’t touch the inner type of such function naively, so this purity is viral.

This might surprise you, but Haskell can do IO. It even has a name. It's called "IO". Shocking, I know. (IO happens to be a monad, which I'm sure someone will point out soon, but that's not important right now.)

Reply on news.ycombinator.com