This way of thinking about language constraints misses a key point: language constraints are not only there just to bug the programmer into behaving better.

This way of thinking about language constraints misses a key point: language constraints are not only there just to bug the programmer into behaving better. They also provide a way of reasoning about the program to a person trying to understand it. The guarantees that exist in, say Java code, mean that a new person can say with much better precision what any given piece of code does (not what it's meant to do - what it will actually do). In a dynamic language, it might do anything. I experience this exactly in the dual Groovy-Java universe I inhabit these days. I am faster at writing the groovy code and I think the end result looks nicer and smaller. But when there's some strange problem that needs to be debugged that I don't understand, the java code is much much easier to reason about. Simple questions like "how is this function possibly getting called" can be answered definitively in a fraction of a second with a key-press in Eclipse for java, while I have to run a virtual simulation of the program in my head to figure out what the groovy code might do.