HarderIsntHardEnough

There is an intellectual fallacy that designers of programming languages and libraries often fall into, which is to believe that "if we just make doing the wrong thing more difficult, then people will do the right thing."

You can see the results of this attitude in Go, whose verbose error handling syntax ostensibly pushes programmers to write simpler, less error-prone code; in Java, whose verbose local variable syntax and insistence on classes were supposed to discourage procedural programming; and in test-driven development, which, by making it harder to write tightly-coupled code, was supposed to encourage programmers to loosen coupling.

The problem with this approach is that it never has the desired effect. People exploit the loopholes in the system to continue doing things the old, bad way, and then they complain that the language/library/technique is getting in their way.

The cause of the problem is twofold:

• "You can write bad code in any language." (I haven't been able to find the attribution for this quote)
• It is not possible to force someone to do something they don't know how to do.

Tool design can't substitute for education. If you want someone to do something, you have to teach them to do it and teach them why it's the right thing to do, and then provide tools that support it.