Being explict is better than being implicit - only when everything else is constant

The benefits of dependency injection are:

1. Separating configuration of dependencies from their use.
2. Improving unit testability.
3. Making dependencies explicit.

As I finished explaining these points to some new hires, I followed it up with a generalisation, "And in general, being explicit is better than being implicit - it reduces ambiguity and improves communication, always welcome in software development." Immediately I was struck by a few incongruities. After all, we have come to appreciate:

1. The absence of Java-esque checked exceptions in C#.
2. The flexibility afforded by dynamically typed languages.
3. The evolution friendliness and interoperability of loosely typed SOAP web service contracts (documents, coarse-grained interfaces, restricting ourselves to the simplest of XSD types).

In the above cases, being explicit comes with a stiff cost. We trade it off for flexibility. So the generalisation still holds. In general, being explicit is better than being implicit. But there is a caveat implicit in there - "In general, being explicit is better than being implicit provided everything else remains constant." If there are additional benefits to be gained from going implicit, then being explicit is questionable.

It helps to make this caveat explicit. A case of making the generalisation practise what it preached.