The high level point that is of great importance is that if one wants a computer program to function in a reliable way one needs simple and understandable algor

The high level point that is of great importance is that if one wants a computer program to function in a reliable way one needs simple and understandable algorithms/components. Nowadays even the processor is no longer simple and assembly has become a high level language and it got us 'nice' things like spectre. For the practical day to day work the KISS principle that has been the corner stone of effective programming for half a century is now more important than ever. Yes, there is a nice library available to do such and such and maybe you need it, but are you also thinking about the dangers that any additional moving part may increase unpredictability? Let me give one very stupid example that I ran into this very week. The agreed-upon answer according to https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my https://unix.stackexchange.com/questions/29608/why-is-it-bet... is that it is better to do #!/usr/bin/env bash than #!/usr/bin/bash. I say: absolutely not! You have just increased the number of moving parts involved by one for an immeasurably small benefit. And if you are worrying about bash versions then just stop using any bash features that are less than a decade old. I also say that unless it is necessary for the core problem that you are trying to solve stay away from any features of anything that are less than 5 years old. And if you actually need the new and fancy stuff, and maybe you do, expect to pay a hefty price for it. Every new tool that you introduce has its own peculiarities that you will spend hours of debug time on and one should err on the side of just saying no.