При каких обстоятельствах динамические языки не подходят? [закрытый]
Какие факторы указывают на то, что решение проекта не должно быть закодировано на динамическом языке?
10 ответов:
Знакомство и готовность программистов работать с языком.
Ваш динамический язык, вероятно, мой статический язык.
Разработка на системном уровне-это ключевая группа программ, которые обычно не должны быть написаны на динамических языках. (драйверы, материалы уровня ядра и т. д.).
В основном все, что должно иметь каждую унцию производительности или низкоуровневый аппаратный доступ, должно быть на языке более низкого уровня.
Другой показатель - это если он сильно хрустит числами, как хрустят научные данные. То есть, если ему нужно быстро бегать и делать числовой хруст.
Я думаю, что общая тема-процессор интенсивные проблемы... в этом случае вы легко увидите различия в производительности, и вы обнаружите, что динамический язык просто не может дать вам возможность эффективно использовать аппаратное обеспечение.
Тем не менее, если вы выполняете процессорную интенсивную работу и не возражаете против снижения производительности, то вы все еще можете потенциально использовать динамический язык.
Обновление:
Обратите внимание, что для хруста чисел я имею в виду действительно продолжительный хруст чисел на научной арене, где процесс идет в течение нескольких часов или дней... в этом случае прирост производительности в 2 раза огромен... если он будет гораздо меньше, то динамические языки все еще могут быть полезны.
В значительной степени язык программирования-это выбор стиля. Используйте язык, который вы хотите использовать, и вы будете максимально продуктивны и счастливы. Если по какой-то причине это невозможно, то, надеюсь, ваше окончательное решение будет основано на чем-то значимом, например, на платформе, с которой вы должны работать, или на реальных эмпирических показателях производительности, а не на чьем-то произвольном выборе стиля.
Когда скорость имеет решающее значение. Динамические языки становятся быстрее, но все еще не близки к производительности того, что представляет собой скомпилированный язык.
Взаимодействие абсолютно возможно с динамическими языками. (помните классический visual basic, который имеет "ленивую привязку"?) Это требует, чтобы компонент COM был скомпилирован с некоторыми дополнительными функциями, хотя для помощи их абонентам звонить по имени.
Я не думаю, что хруст чисел должен быть статически скомпилирован, чаще всего это вопрос того, как вы решаете. MATLAB является хорошим примером сделал для подсчетов, а не компилируемым языком. Matlab, однако, имеет очень специфическую среду выполнения для числа и матрицы.
Я считаю, что вы всегда должны выбирать статически типизированный язык, где это возможно. Я не говорю, что C# или Java имеют хорошие статические системы, но C# приближается. Хорошийвывод типа является ключевым, потому что он даст вам преимущества, наблюдаемые в динамических языках, но при этом даст вам безопасность и возможности статически типизированных языков. Проблема решена - больше никаких огнеметов.
Код системного уровня для встроенных систем. Возможная проблема заключается в том, что динамические языки иногда скрывают последствия производительности одного простого на вид оператора.
Как сказать это утверждение Perl:
@contents = <FILE>;
Если файл занимает несколько мегабайт, то это один из ресурсоемких операторов-вы можете исчерпать свою кучу, или вызвать тайм - аут сторожевого пса, или вообще замедлить отклик встроенной системы.
Если вы хотите "программировать ближе к металлу", вы, вероятно, вы хотите использовать статически типизированный и" средний " язык.