4 ms·
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 low
by uncomputation 5y ago
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.
- anchpop 5y agoDoing IO stuff is very well-supported in Haskell. Printing to the terminal just looks like: main = putStrLn "Hello World"
- uncomputation 5y agoDoesn’t this “contaminate” the entire calling function though, as in you now have to specify it is impure?
- samhh 5y agoYes, 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.
- sullyj3 5y agoYes, 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.
- kaba0 5y agoNo 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.
- 08-15 5y agoThis 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.)