I first found it in the early 80s I believe, and then just a year ago I found several copies in a used/vintage book store and bought multiple copies for my family!
For me, personally, the translation REALLY resonates and can provide heartfelt insights. Also, the images are outstanding, and perhaps are a significant aspect to why this book was so impactful to me.
Love your advice about being joyful about the opportunity to introduce people to new things!
I think maybe I need to learn to be joyful about also re-introducing things to people who probably knew the thing at somepoint, but have since forgotten. (Generally applies to people older than their mid 30s)
As an "old guy" with a literal gray beard, I think it's really important to remember to be joyful when explaining things.
Sometimes my computer experience is more than twice the life experience of someone I'm explaining something to ( in years at least :^D )
Honestly, the harder ones are when I'm explaining something to someone in the 40s (or older) who it seems "should have known" something, but for some reason either forgot it or never bumped in to it in the frist place. I often make the wrong assumption that they should've known it, when really, that's just a personal bias based on my own experiences.
REALLY worth reading the Graham Poulter comment in the original post about the difference between spatial and temporal variations.
The idea that you can hard-code everything assumes there is no variation in deployments and use of a piece of software.
If that were the case, you're talking about a SUPER simple piece of software. So sure, hard code everything.
But as soon as you're talking about a piece of software that will be used in multiple locations and with possibly different release / roll-out schedules, "there will be issues".
That comment describes a real issue that the main post overlooks. But the comment also overlooks the obvious solution. It says:
>While "temporal" variations can easily be hardcoded if you have a short release cycle, "spatial" variations are not so easily hardcoded: you end up maintaining a source branch for each active variant.
But that's not the only way. There's a way that we are all very familiar with for customizing a component for being used in different situations: Passing in different arguments to the constructor.
If you have two places you want to deploy a piece of software, which have different environments and need to, e.g., access resources at different paths, then just have two main() functions, each invoked by one of two different executables. Those different main() functions can then hardcode all the specific details of whatever place you're deploying to, in your normal programming language, without you having to create configuration files or anything.
I wonder if there will be any potential for C++ interop. I would __LOVE__ to be able to code Scala that can be called from and in turn call C++ interfaces.
