R – Under what circumstances are dynamic languages appropriate

The ability of the interpreter to deduce type and type conversions makes development time faster, but it also can provoke runtime failures which you just cannot get in a statically typed language where you catch them at compile time. But which one's better (or even if that's always true) is hotly discussed in the community these days (and since a long time).

A good take on the issue is from Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages by Erik Meijer and Peter Drayton at Microsoft:

Advocates of static typing argue that the advantages of static typing include earlier detection of programming mistakes (e.g. preventing adding an integer to a boolean), better documentation in the form of type signatures (e.g. incorporating number and types of arguments when resolving names), more opportunities for compiler optimizations (e.g. replacing virtual calls by direct calls when the exact type of the receiver is known statically), increased runtime efficiency (e.g. not all values need to carry a dynamic type), and a better design time developer experience (e.g. knowing the type of the receiver, the IDE can present a drop-down menu of all applicable members). Static typing fanatics try to make us believe that “well-typed programs cannot go wrong”. While this certainly sounds impressive, it is a rather vacuous statement. Static type checking is a compile-time abstraction of the runtime behavior of your program, and hence it is necessarily only partially sound and incomplete. This means that programs can still go wrong because of properties that are not tracked by the type-checker, and that there are programs that while they cannot go wrong cannot be type-checked. The impulse for making static typing less partial and more complete causes type systems to become overly complicated and exotic as witnessed by concepts such as “phantom types” [11] and “wobbly types” [10]. This is like trying to run a marathon with a ball and chain tied to your leg and triumphantly shouting that you nearly made it even though you bailed out after the first mile.

Advocates of dynamically typed languages argue that static typing is too rigid, and that the softness of dynamically languages makes them ideally suited for prototyping systems with changing or unknown requirements, or that interact with other systems that change unpredictably (data and application integration). Of course, dynamically typed languages are indispensable for dealing with truly dynamic program behavior such as method interception, dynamic loading, mobile code, runtime reflection, etc. In the mother of all papers on scripting [16], John Ousterhout argues that statically typed systems programming languages make code less reusable, more verbose, not more safe, and less expressive than dynamically typed scripting languages. This argument is parroted literally by many proponents of dynamically typed scripting languages. We argue that this is a fallacy and falls into the same category as arguing that the essence of declarative programming is eliminating assignment. Or as John Hughes says [8], it is a logical impossibility to make a language more powerful by omitting features. Defending the fact that delaying all type-checking to runtime is a good thing, is playing ostrich tactics with the fact that errors should be caught as early in the development process as possible.

I like slim's answer. I do spend a crazy amount of time in Java and C++ crafting custom data structures that are just free in Python/Ruby. And crafting specialized functions to process these custom data structures. Yes, in C++, STL is really nice. Yes, Generics in Java are nice. They help create custom data structures much faster, however they still require a lot of thought and consideration.

However, there is a more fundamental reason why dynamic languages are easier to work with. It is a deep idea which is called duck typing. Some comments above refer to duck typing, but please take time to reflect on what duck typing is. It is a fundamentally different way to view the world. A view that is incompatible with languages like Java and C++.

Duck typing means that you waste not time in defining what a duck is. By not having to formally define your objects you save a lot of time and energy. Getting definitions right is hard. Have a look at this blog post of mine where I give examples: Formal definitions are less useful than you think

Duck typing has proven extremely useful. The "Must Ignore" principle in XML is what has made XML so significant and useful on the web. But that's just an instance of duck typing.

Another way to express duck typing is by the Web mantra "Be strict in what you send, generous in what you accept". That is also a very fundamental idea.

Finally, you may want to back to a long blog post of mine where I explain duck typing and how it relates to things like AI and modelling: Duck Typing, Artificial Intelligence and Philosophy