> Creating the python extractor at all was sort of bizarre. The argument given was that it is too difficult for a developer to spin up a whole dev environment just to compile a tool, but the C extractor is a single C file that only depends on the C standard library and zlib.

He just wanted the extraction utility to be easily available to other people without them needing to spin up a whole development environment. That's quite community-spirited. And honestly, having tried and failed to get a number of things to successfully compile (after spending god knows how long installing different and specific Visual Studio or cmake packages) in the past, I get it.

"For this archive I wanted a Python version that could be kept with the recovered files and run without compiling the original C program. Most developers have easy access to Python, and it's quicker to run a one-off Python script than it is to spin up a dev environment, configure and compile and run a compiled native executable."

> This feels more like your mom likes to wash dishes by hand and you have a known good dishwasher that needs to be plugged in, but instead of plugging it in you build a new one that you tested a couple times and it seems to work but who knows? At least you saved yourself all the work of plugging in that other dishwasher?

If we really want to flog this analogy :) then it's more like: I rent out a holiday property. It has a dishwasher, but it takes 20 minutes of messing around for each new tenant to learn how to turn it on, and there's a non-zero failure rate. So I replace it with a different model without this difficulty.