4 ms·

>functional programming languages ... break down when you try to coordinate between components, especially when those components are distributed ... I think th

>functional programming languages ... break down when you try to coordinate between components, especially when those components are distributed ... I think the exact opposite. Having spent more than a decade in distributed systems, I became convinced functional programming (and pure functions) are essential for survival in distributed systems. Back then I wrote down my insights here (amazed that the site still exists) https://incubaid.wordpress.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/ https://incubaid.wordpress.com/2012/03/28/the-game-of-distri...

c2247946 1y ago
[dead]
zamalek 1y ago
Even with my limited knowledge about FP I am pretty sure I would only grow more in agreement as I learn more. My only exposure to functional is via Nix and Rust (I promise I'll learn OCaml soon). One thing that I've really come to appreciate is the concept of "making invalid states unrepresentable," a trick that is harder than it should be (though not impossible) in "less functional" languages. Coming back to distributed systems, I have wondered what a functional database would look like. Mutations as pure functions, DUs in tuples, could we store a function, etc.
- toolslive 1y ago
  regarding databases, you get quite far using purely functional data structures and zippers. - https://www.cs.cmu.edu/~rwh/students/okasaki.pdf https://www.cs.cmu.edu/~rwh/students/okasaki.pdf - https://en.wikibooks.org/wiki/Haskell/Zippers https://en.wikibooks.org/wiki/Haskell/Zippers
- addaon 1y ago
  > "making invalid states unrepresentable," a trick that is harder than it should be (though not impossible) in "less functional" languages The flip side of this is to "make representable states valid." If you have an enum that doesn't fill a bitfield, values of the bitfield outside the enum are representable -- and the behavior of the system must be defined in that case. (Most often, this is done by mapping the behavior of undefined states to a chosen defined state, or using it to trigger an abort -- the key is that it must be an explicit choice.)
ndriscoll 1y ago
And part of why functional programming works so well is exactly that you don't need to care about things like control flow and interactions. You're just expanding definitions. Those definitions are local/isolated, and compose in regular ways.

c2247946 1y ago

[dead]

zamalek 1y ago

Even with my limited knowledge about FP I am pretty sure I would only grow more in agreement as I learn more. My only exposure to functional is via Nix and Rust (I promise I'll learn OCaml soon). One thing that I've really come to appreciate is the concept of "making invalid states unrepresentable," a trick that is harder than it should be (though not impossible) in "less functional" languages. Coming back to distributed systems, I have wondered what a functional database would look like. Mutations as pure functions, DUs in tuples, could we store a function, etc.

toolslive 1y ago
regarding databases, you get quite far using purely functional data structures and zippers. - https://www.cs.cmu.edu/~rwh/students/okasaki.pdf https://www.cs.cmu.edu/~rwh/students/okasaki.pdf - https://en.wikibooks.org/wiki/Haskell/Zippers https://en.wikibooks.org/wiki/Haskell/Zippers
addaon 1y ago
> "making invalid states unrepresentable," a trick that is harder than it should be (though not impossible) in "less functional" languages The flip side of this is to "make representable states valid." If you have an enum that doesn't fill a bitfield, values of the bitfield outside the enum are representable -- and the behavior of the system must be defined in that case. (Most often, this is done by mapping the behavior of undefined states to a chosen defined state, or using it to trigger an abort -- the key is that it must be an explicit choice.)

ndriscoll 1y ago

And part of why functional programming works so well is exactly that you don't need to care about things like control flow and interactions. You're just expanding definitions. Those definitions are local/isolated, and compose in regular ways.