Архитектурные различия между динамическими и статическими языками

Существуют ли серьезные архитектурные различия при разработке приложений, которые будут построены на статических языках (таких как C # или Java) и динамических языках (таких как Ruby или Python)?

Какие дизайнерские возможности могут быть хорошим выбором для одного типа, а для другого - плохим? Существуют ли какие-либо полезные функции, достижимые с одним типом, но не с другим (в дизайне и архитектуре, конечно)?

Кроме того, есть ли какие-то динамические шаблоны проектирования?

Давайте разберемся несколько вещей:

1. Интерактивные скриптовые и статические языки не являются взаимоисключающими. F # и Haskell оба имеют интерфейсы REPL.
2. Динамические языки и высокая производительность не являются взаимоисключающими, хотя некоторые оптимизации есть. JavaScript работает чертовски быстро в большинстве браузеров в настоящее время.
3. Даже в динамических языках вам все равно нужно документировать, запоминать и думать о типах.
4. Из-за растущей популярности вывода типов, многие статические языки больше не должны часто записывать типы. В статических языках со строгим выводом типов компилятор выясняет, какие типы взяты из вашего кода, поэтому большую часть времени сообщает вам, если вы когда-нибудь делаете что-то, что нарушает определения типов. Что касается синтаксиса, это обеспечивает лучшее из обоих миров.
5. ООП и динамические языки не являются взаимоисключающими. PHP теперь поддерживает классы и даже наследование.

Помимо всех этих удивительных сходств, есть некоторые практические различия, которые влияют на процесс разработки:

1. Динамические языки допускают интересные способы передачи данных в малых .
2. Статические языки позволяют вам сократить объемы тестирования, делая невозможными многие виды ошибок.
3. В том же духе статические языки допускают интересные функции проверки и автоматического преобразования, такие как единицы измерения в F # .
4. Взятые до крайности, статические языки допускают контракты кода и формальную проверку, которая может документировать и выравнивать, предотвращать такие вещи, как потенциальные деления на нули, бесконечные циклы, нулевые ссылки, недопустимые размеры или индексы списка, ошибки диапазона и другое логически недопустимое состояние что вы можете определить.
5. Принимая это крайнее значение, можно оптимизировать процессор на основе этих статических ограничений, что приводит к еще большей производительности.

Существует также один тип программ, который никогда бы не был создан без статической типизации: Singularity , ОС без аппаратных границ процессов. Он написан на небольшом количестве C, немного C # и диалекте C #, называемом Spec #, который поддерживает контракты кода.

Несмотря на то, что она написана на языке для сбора мусора, производительность многозадачности и межпроцессного взаимодействия в этой ОС на самом деле лучше, чем что-либо еще, из-за того, что все процессы выполняются в одном пространстве памяти, и из-за формальной оптимизации проверки упомянутый выше. Вы не могли бы сделать это без статической типизации, потому что для того, чтобы программы не могли поставить под угрозу остальную часть системы, объекты связи должны быть статически проверяемыми.

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

Существует значительная архитектурная разница. Спектакль.

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

Чаще всего скорость разработки и гибкость, обеспечиваемые динамическими языками, компенсируют более медленное время отклика, увеличивая процессор и потребление памяти. Но для более крупных систем с ограниченным бюджетом или производительностью накладные расходы динамического языка могут быть высокими.

Я никогда не думал в этом направлении. Поэтому, когда появился Google, блог Питера Норвига был одним из лучших хитов. В нем говорится, что некоторые шаблоны проектирования легче реализовать в динамических языках, чем в традиционных объектно-ориентированных языках, таких как C ++. Я думаю, что должны быть различия в дизайне / архитектуре, так как он отмечает, что реализация в динамических языках проще. Я постараюсь добавить больше к ответу, поскольку я учусь дальше.

Существуют ли серьезные архитектурные различия при разработке приложений, которые будут построены на статических языках (таких как C # или Java) и динамических языках (таких как Ruby или Python)?

Нет.

Немного проще писать модные фреймворки для динамических языков. Но это не вопрос приложения.

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

Нет, правда.

Вы можете писать хорошие вещи на любом добром языке.

Существуют ли какие-либо полезные функции, достижимые с одним типом, но не с другим (в дизайне и архитектуре, конечно)?

Нет.

Разница в том, что динамические языки «пишите, бегите, исправляйте». Вы можете экспериментировать и быстро исправить.

Статические языки: «писать, компилировать, строить, запускать, исправлять». Вы не можете так легко экспериментировать.

Кроме того, они почти идентичны по своим возможностям.

Существуют ли динамические шаблоны проектирования?

Может быть. Python eval()и execfile()функции - в некотором роде - указывают на динамическую языковую особенность, которую трудно (но далеко не невозможно) обрабатывать на статическом языке. Было бы намного больше строк кода для компиляции и выполнения кода в одном и том же пространстве процесса.

Это не зависит от языка. Это просто проще