First of all, new post: Software Mimicry! It’s about a thing I’ve seen in a lot of software tools and products that I was trying to capture in a single term, so I could share it and explore what it actually means for things. It’s also a rewrite and expansion of one of my very first newsletters: on emulation.
I find myself fascinating with terms. Mimicry is something I see in a lot of different places, and I’ve seen people identify particular instances of it, but not connect the dots and discuss the abstract concept of mimicry. Is “articulating” mimicry into a distinct term useful? I think so! By having a term for something you can discuss it as a thing instead of being forced to gesture vaguely at it through examples.
Take, for example, “side effect”. A side effect is when a function changes the outside world in addition to computing a value. Changing a global value is a side effect. Allocating or freeing memory is a side effect. Updating the cache, advancing the RNG, and making a POST request are all side effects. Side effects are generally something that increases software complexity, so are often implicitly avoided, or explicitly embedded in software constructs like monads and algebraic effects.
That all makes sense, right? But that only makes sense because I have the term “side effect”. Without it, can I really convincingly explain that “generating random numbers” shares a fundamental essence with deleting a reference or logging to a file? We can vaguely wave at it and maybe point out things like idempotetncy. But it’d be a major uphill battle because people don’t conceptually relate HTTP requests to playing a sound. Articulating the concept of “side effects”, then, creates a new category which all these belong to, making us see them as similar. Once we see them as similar, we can elaborate those similarities / find other examples / find synonyms / all the things we do with new knowledge.