There is a very delicate balance to be struck here.   On the one hand, we want it to be convenient for us to write accurate, robust software.   On the other hand, we must always be able to look at a piece of software and to ascertain, correctly, what it will do.   Programmers handle this by devising standard practices within each “shop.”   They dub their favorite things, “best practices,” and subsequently stand around the Monastery's electronic water-cooler, bickering in a friendly way about what “best” actually means; what is “better.”

Being good Perl programmers, they practice laziness and hubris.   They automate things.   Then, they insist that everyone else should automate things just the way they did.   But change happens slowly, if at all.

They’re professionals, often with twenty or thirty years in.   Among the very best.   The disagreements, and the insistence, and the resistance, all come from people who know whereof they speak.   Change happens.   Slowly.

I have learned to be reluctant about things that are “too convenient.”   Specifically, about things that place substantial influences over the behavior of a piece of source-code, anywhere outside of that piece of source-code.   In my experience, such things, well-intentioned though they might be, create substantial difficulties.   Call me a Luddite if you want to... ;-)   I can be convinced, but not quickly.