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

22

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

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

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

Рафаэль
источник
1
Каковы бы ни были эти архитектурные различия, динамические языки - IronRuby и IronPython - легко дополняют статические языки .Net.
IAbstract
3
Я не уверен, но если метапрограммирование проще в динамических языках (в Ruby он казался проще, чем в Java, в прошлый раз, когда я смотрел), это может повлиять на архитектурные решения. Я не уверен, какое влияние оказывает, потому что я никогда не работал над чем-то таким большим в этих динамических языках.
FrustratedWithFormsDesigner

Ответы:

14

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

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

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

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

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

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

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

Рей Миясака
источник
Может ли Singularity предоставить гарантированную максимальную задержку в реальном времени?
Эонил
@Eonil Не совсем моя сфера, но я думаю, что ты спрашиваешь, может ли она работать в режиме реального времени. Я так не думаю, так как он использует сборку мусора повсюду. Насколько я знаю, Singularity некоторое время не обновлялась, но, возможно, кто-то сделал нечто подобное с помощью сборщика мусора в реальном времени.
Рей Миясака
Спасибо. Я просто хотел проверить. Я слышал, что есть некоторые реализации GC в реальном времени, но я не слышал, как они используются практически в промышленности ...
Эонил
2

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

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

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

Джеймс Андерсон
источник
1

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

vpit3833
источник
1

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

Нет.

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

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

Нет, правда.

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

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

Нет.

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

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

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

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

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

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

С. Лотт
источник
2
«Вы не можете так легко экспериментировать». Правда, компромисс заключается в том, что компилятор помогает вам находить ошибки, тогда как в интерпретируемых языках вы не можете найти ошибку, пока пользователь не выполнит эту строку кода.
Дуг Т.
4
@Doug T .: «Компилятор поможет вам найти ошибки». Иногда. Не достаточно часто. Интересные ошибки не могут быть найдены компилятором вообще. Для этого и есть юнит-тестирование.
С.Лотт
2
@ S.Lott Я считаю, что API, написанные на динамических языках, требуют немного больше документации. В статическом языке сигнатура метода говорит вам, какие типы аргументов требуются. На динамическом языке вы не можете сказать так просто - в документации API должно быть указано, какие объекты ожидаются.
quanticle
1
@ Quanticle: Это не совсем архитектурно, правда?
С.Лотт
2
«Вы не можете экспериментировать так легко». - F # и Haskell оба являются статическими языками, и они имеют полноценные REPL и редко запрашивают у вас идентификатор или тип выражения.
Рей Миясака