From this thread, a perspective on types:
Getting a type system right requires so much detailed specification that the cost is so high that mistakes are actively discouraged. this cost is not necessarily offset by the benefits of using such types, especially not if the program needs to adapt its specification to changing needs discovered only as the program is being used in preliminary forms (often called “prototypes”, but I’m not sure building a prototype only to discard it and build “the real thing” is a good idea. It seems the projects that go into a state of completion such that they are no longer learning from the experience of use are extremely rare. projects that no longer can learn from the experience of use is, however, quite common.
My conclusion is that less strongly typed (i.e., dynamically typed) systems are the ultimate type systems, because they allow growth and change, while preserving the ability to use machine reasoning about types. strict type systems, where every “object” is a type, do not scale well because the computer is not involved in the typing decisions, only in checking them. still, some of the lessons of “object-oriented” programming in the Algol family can be fruitfully employed in dynamically typed systems.
Essentially, it is the a priori aspect of strongly typed systems that is fundamentally unsuited to the process of acquiring the knowledge of the types necessary to implement them and relate them correctly.