Я не думаю, что здесь есть черное и белое - существует целый спектр между динамическим и статическим.
Давайте возьмем два крайних примера для каждой стороны спектра и посмотрим, куда это нас приведет.
Хаскелл - это крайность в статическом направлении.
- Он имеет мощную систему типов, которая проверяется во время компиляции: если ваша программа компилируется, она не содержит распространенных и не очень распространенных ошибок.
- Скомпилированная форма сильно отличается от программы на haskell (это двоичный файл).Следовательно, отражение и модификация во время выполнения трудны, если вы не предусмотрели это.По сравнению с интерпретацией оригинала, результат потенциально более эффективен, так как компилятор может свободно выполнять неожиданные оптимизации.
Так что для статических языков я обычно думаю: требуется довольно длительный анализ во время компиляции, введитеСистема будет препятствовать тому, чтобы я делал глупые ошибки, но также делал некоторые вещи, которые действительно допустимы, и если я хочу сделать какие-либо манипуляции с программой во время выполнения, это будет чем-то вроде боли, потому что представление программы во время выполнения (то естьего скомпилированная форма) отличается от самого языка.Кроме того, может быть затруднительно изменить вещи позже, если я не предвидел это.
Clojure - это крайность в динамическом направлении.
- У него тоже есть система типов, ново время компиляции нет проверки типов.Многие распространенные ошибки могут быть обнаружены только при запуске программы.
- Программы Clojure - это, по сути, просто списки Clojure (структура данных), и ими можно манипулировать как таковыми.Таким образом, при отражении во время выполнения вы фактически обрабатываете программу Clojure более или менее так, как вы бы ее набирали - форма времени исполнения очень близка к самому языку программирования.Таким образом, вы можете делать во время выполнения те же самые вещи, что и во время ввода.Следовательно, производительность во время выполнения может пострадать, потому что компилятор не может выполнить много предварительных оптимизаций.
Для динамических языков я обычно думаю: короткий шаг компиляции (в основном просто чтение синтаксиса), такая быстрая и пошаговая разработкаПрактически нет предела тому, что он мне позволяет делать, но не предотвратит глупых ошибок.
Как указывали другие посты, другие языки пытаются занять более высокий уровень - например, статические языки, такие какF # и C # предлагают возможности отражения с помощью отдельного API и, конечно, могут предлагать поэтапную разработку с использованием умных инструментов, таких как F # REPL.Динамические языки иногда предлагают необязательную типизацию (например, Racket, Strongtalk) и, как правило, имеют более продвинутые тестовые среды, чтобы компенсировать отсутствие проверки работоспособности во время компиляции.Кроме того, подсказки типа, хотя и не проверяются во время компиляции, являются полезными подсказками для создания более эффективного кода (например, Clojure).
Если вы ищете подходящий инструмент для данной проблемы, то это, безусловно, один изРазмеры, на которые вы можете посмотреть, но сами по себе вряд ли заставят принять решение в любом случае.Подумайте о других свойствах языков, которые вы рассматриваете - это функционал или ОО, или логика, или ... язык?У него есть хорошая основа для вещей, которые мне нужны?Нужна ли мне стабильность и двоичная обратная совместимость, или я могу жить с некоторой текучестью в компиляторе?Нужен ли мне обширный инструментарий?