WH>Единственный объективный аргумент в пользу динамической типизации: Нужно писать меньше кода.

Но это очень сильный аргумент.

Вообще, отвечая сразу и на вопрос выше о задачах, где динамика может выиграть перед статикой, попробую собрать все в кучу:

1) Динамика удобнее при интеграции с другими динамическими системами или сервисами, о типизации которых на этапе компиляции ничего не известно.
Примеры — работа с удаленным rpc-сервером без схемы, чтение данных из базы если схема заранее неизвестна, стык с другими динамическими системами, в общем все юзкейсы для которых ms ввел dynamic.
Статическая типизация здесь никаких гарантий не даст, а под ногами мешаться будет.

2) Динамика удобнее, когда статическая типизация в имеющихся альтернативах недостаточно гибка. Например когда нужно объединение типов — вот в Nemerle есть variant, но что делать если одна переменная имеет тип A | B | C | D, а другая — A | C | E | F? Один variant-тип неудобно по многим причинам (ну например он должен быть объявлен в одной сборке) да и нужные нам статические проверки он не обеспечит, а если два — то проблема в том, что значения A1 и A2 будут разными, и вот мы уже пишем кучу ненужного затрудняющего понимание кода. Ну а если в языке даже неуклюжего variant/pm нет, то вообще туши свет — мысль, которая могла быть выражена лаконично, растекается. Да что там, в большинстве языков даже тип со значениями ( T | null (значение отсутствует) | undefined (значение не определено) ) уже страшная проблема.

3) Системы с горячей заменой кода. Наверное, удачно совместить ее со статической типизацией в принципе возможно, но пока на этом поле играет динамика.

WH>Но если в случае с жабой выигрыш существенный. То в случае с языками, где есть вывод типов и метапрограммирование выигрыш сводится примерно к нулю.

Когда в руках молоток, все вокруг кажется гвоздями. Если проблемы типизации должно решать метапрограммирование, то у типизации проблема.

WH>1)Медленное исполнение.
WH>2)Большое потребление памяти.
WH>3)Серьёзные проблемы с поддержкой кода, если его больше 100 строк.
WH>4)Плохая поддержка ИДЕ.

Как и все трюизмы, эти, верные в целом (если, конечно, опустить "100 строк"), могут не соответствовать действительности в конкретных условиях.

Например, почему-то поддержка того же Эрланга со стороны ИДЕ намного лучше, чем существующая на данный момент поддержка Nemerle.

Резюмируя — чтобы тащить динамику в продакшн действительно нужны веские причины, но при их наличии динамика не табу.