> If complexity buys you nothing, then why make something complex? And, believe me, if you are thinking "Visitor" or "AbstractFactory" then I have already lost you. ;-)
I think maybe the disconnect here is that I work on products with a much larger scale than you may be accustomed to. My idea of complexity begins to blossom at scales past many boxes. For me, 25 interconnected machines is barely enough to register as a "big system". So perhaps I am just desensitized?
Abstraction is generally trying to find ways to mitigate complexity, not embrace it. At some point we need to have sympathy for the machines we run on to have efficient code, but at the same time you and I need to find good perspectives to write code at.
A more concrete example of this is my advice that people building distributed systems take a cue from Boundary and have systems rendezvous in Zookeeper rather than just using something like hardwired ports and /etc/hosts. You may think that "sounds complex" but it's actually a very simple solutin from our perspective as users of Zookeeper. It ends up being pretty nice the next time a giant storm takes out half of us-east-1 and you're frantically re-provisioning boxes to keep your service up.
Monoids are that kind of choice at the programming level.
> Complexity: when required; otherwise, choose simple. Believe me, I have learned this lesson over and over again during my 45 years of programming.
I think c_wraith's monoid example made the program simpler, cleaner, and less bug prone. If you think monoids are a "complex" idea, then my blog post has failed profoundly and I apologize for wasting your time.