OP's argument, boiled down, is the following: 1) Behavior needs to be automatically checked 2) To check behavior, you can either write tests or specify types 3

OP's argument, boiled down, is the following: 1) Behavior needs to be automatically checked 2) To check behavior, you can either write tests or specify types 3) Tests are more flexible than the type systems of popular languages (e.g. to write end-to-end tests) 4) Testing purely dynamic languages is quicker than compiling statically typed code 5) So prefer tests to type systems because agility Honestly this is a load of bollocks and I'll explain why: * When business execs throw out the old UI (old end-to-end tests) and replace it with a new UI (new end-to-end tests) and your new tests are failing because undefined, well, have fun and good luck! * The longer a system lives, the longer the test suite gets. So no, your developers are not going to be running the entire test suite at their desks, even if at the beginning of that project, running that test suite took all of half of a second. This is one of the reasons for continuous integration servers, actually, so that the massive test suite can be parallelized across a bunch of build slaves and run overnight while the programmer is at home or working on a different feature/problem. And then the difference in compile and start-up times is psychologically irrelevant because the programmer will still think "ok, I submitted the build to CI, time to go home/work on something else". * Good type systems, combined with proper IDE support and proper object-oriented design, do optimize for deletion by reducing the number of places in a codebase in which refactoring has an impact. It is incorrect to state that type refactoring should be some kind of massive refactoring affecting every file in the codebase every time you refactor. A refactor should either eliminate a given subtype, thus leaving the other subtypes unaffected, or add a subtype, where no-longer-common code/behavior can be factored into a new intermediate type. When the supertype needs to be changed, well, you still need to test those changes, but at least you only needed to make the change in one place, and not an indeterminate number of copy/pasted places in dynamically typed code which, you know, good luck finding them all. Static typing is a practical requirement for long-lived, large systems. OP makes way too many assumptions on the basis of small, short-lived projects.