As long we can both agree, that at an elementary level, it's faster to write code in a dynamic language, than it is with a strongly typed one, then there will a

As long we can both agree, that at an elementary level, it's faster to write code in a dynamic language, than it is with a strongly typed one, then there will always be a trade-off to consider. Like the trade-off between using glue and nails. Being able to change things quickly, or describe things creatively is occasionally going to be more helpful than immutability guarantees in some product domains. That practical focus is the very reason why dynamic languages are so popular. They facilitate rapid iteration, which is a quality which also certainly can lead to positive results when programming. A focus on 'process' is really an understanding that the 'noun' is subject to change, as requirements so often do in engineering and product development. I suspect the modern dynamic languages are a response to this focus on practicality, with Ruby probably being one of the bests illustrations of this idiom (I don't write much Ruby at all, but respect it for what it is). However, this purely practical focus is not always the most desirable quality in a programming language, and in those domains where you know your requirements are written in stone, then an effort should be made to describe requirements as formally as possible. But a myopic preference for only one approach to writing software, will probably introduce some flaw into your program, no matter what language you are using. Every single language is an abstraction after all. We moved away from Assembler in an effort to focus attention on expressing what tasks computers should perform. Dynamic languages are a logical result of that focus.