Mutable Opinions
Ready for a strong opinions, weakly held post? I subscribe to this philosophy as a sort of perscription against dogma. I've also been playing with [the functional language] Elixir recently so you can understand my excitement when I saw the following tweet:
Hey software devs - as you move into the world of functional programming, make sure your opinions stay mutable.
— Brian P. Hogan (@bphogan) January 15, 2016
Of course I got excited about a response that involved Elixir's immutable state that can be rebound to variables. Not wanting to look like a hack, I did a bit of quick googling and, an hour later, decided to write a quick post*.
Immutability in Elixir
(in three bullet points)
- state is immutable in Elixir (it cannot be changed)
- variables often need to change their value
- variables can be re-bound without changing the original value (in memory)
Keeping Opinions Mutable
Here's the meat of this little thought experiment. Your opinions should always be open. Maybe even free. This is the "mutability" of your opinions. Be open to changing them with the right new information. At the same time, your old opinions should also still hold some validity. That's why you held them, and held them so strongly.
The consideration of your opinions should be nuanced enough to account for the situation. Perhaps a given situation will merit taking your old opinion, while a new one will require a new one.
I'm generally a fan of DRY programming, especially in Ruby**. Some code I have write and like in Elixir is not as DRY.
It all comes back around
Maybe the takeaway is that the original tweet had it right: enjoy functional programming, but keep those opinions mutable.
*The twitter had also raised a few questions about the nature of a blog and its scrutiny today, priming the proverbial pump.
** Speaking of dogma, Rubyists need to chill out on the DRYness thing, but that's for another time.