3 ms·
I don't tend to handle things in the domain you're talking about here - 99% of problems I solve are along the lines of "how do I split the function to solve thi
by vertex-four 9y ago
I don't tend to handle things in the domain you're talking about here - 99% of problems I solve are along the lines of "how do I split the function to solve this problem up in such a way that it obviously matches the spec and each part is difficult to misuse". Think security-centric applications - an identity server implementing OpenID Connect and SCIM, for example.
As a result, I currently use languages with decent type systems - Rust, recently F# - but I've still never come across a reason to know that something is a monoid, and I don't regularly come across duplicated code, so I'm not exactly sure what problem knowing something is a monoid is supposed to solve in my domain.
- ShaneWilton 9y agoIn my experience, it's more important to know that something isn't a monoid / semilattice / <insert structure here> The CRDTs linked by the parent are a great example. If you're working on an eventually consistent system, and you see a structure that doesn't form a monoid, it's most likely the case that there's going to be some sort of race condition. That isn't to say that any given monoid is going to solve the problem, but it can definitely help to pinpoint possible problems in otherwise complicated code. It definitely doesn't come up in every discipline, but studying these structures has improved my engineering a ton. If design patterns are about class and object composition, then I'd argue that algebraic structures are the equivalent for function composition. Full disclosure: I write mostly functional Erlang code for a living