4 ms·
I'm not only talking about MapReduce; I'm saying there are ideas from functional programming that have more affinity for the underlying hardware than state mach
by chubot 13y ago
I'm not only talking about MapReduce; I'm saying there are ideas from functional programming that have more affinity for the underlying hardware than state machines. This is only going to get more important in the future. Right now we're straddling the two worlds kind of awkwardly.
State is useful; however exactly as in "traditional" functional programming, it should be used sparingly in distributed systems. State requires very special handling and thought. Statelessness or purity is the default. Clusters have a tiny bit of state and lots of stateless workers, just like a Haskell program has a tiny bit of state and lots of pure functions.
To be clear, I don't think Haskell makes sense at the single machine level. (I personally don't want to program in it.) I'm saying that the ideas are more appropriate at the level of architecture and not code.