При каких обстоятельствах динамические языки не подходят? [закрытый]


Какие факторы указывают на то, что решение проекта не должно быть закодировано на динамическом языке?

10 6

10 ответов:

Скорость обычно является основным ответом. Хотя в наши дни это становится все меньшей проблемой.

Знакомство и готовность программистов работать с языком.

Ваш динамический язык, вероятно, мой статический язык.

Разработка на системном уровне-это ключевая группа программ, которые обычно не должны быть написаны на динамических языках. (драйверы, материалы уровня ядра и т. д.).

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

Другой показатель - это если он сильно хрустит числами, как хрустят научные данные. То есть, если ему нужно быстро бегать и делать числовой хруст.

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

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


Обновление:

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

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

Драйверы устройств видеокарт

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

Взаимодействие абсолютно возможно с динамическими языками. (помните классический visual basic, который имеет "ленивую привязку"?) Это требует, чтобы компонент COM был скомпилирован с некоторыми дополнительными функциями, хотя для помощи их абонентам звонить по имени.

Я не думаю, что хруст чисел должен быть статически скомпилирован, чаще всего это вопрос того, как вы решаете. MATLAB является хорошим примером сделал для подсчетов, а не компилируемым языком. Matlab, однако, имеет очень специфическую среду выполнения для числа и матрицы.

Я считаю, что вы всегда должны выбирать статически типизированный язык, где это возможно. Я не говорю, что C# или Java имеют хорошие статические системы, но C# приближается. Хорошийвывод типа является ключевым, потому что он даст вам преимущества, наблюдаемые в динамических языках, но при этом даст вам безопасность и возможности статически типизированных языков. Проблема решена - больше никаких огнеметов.

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

Как сказать это утверждение Perl:

@contents = <FILE>;

Если файл занимает несколько мегабайт, то это один из ресурсоемких операторов-вы можете исчерпать свою кучу, или вызвать тайм - аут сторожевого пса, или вообще замедлить отклик встроенной системы.

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

Как насчет взаимодействия? Можно ли вызвать com-компонент из Ruby или Python?