Действительно ли языки с динамической типизацией заслуживают всей критики? [закрыто]

35

Я прочитал несколько статей в Интернете о выборе языка программирования на предприятии. В последнее время популярными стали многие языки с динамической типизацией, например, Ruby, Python, PHP и Erlang. Но многие предприятия все еще используют статические типизированные языки, такие как C, C ++, C # и Java.

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

Основной причиной того, что предприятия не начинают использовать такие языки, как Erlang, Ruby и Python, является тот факт, что они динамически типизированы. Это также, кажется, главная причина, по которой люди в StackOverflow выбирают Эрланга. Посмотрите, почему вы решили "против" Эрланга .

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

Действительно, почему на предприятиях так много критики в отношении динамического набора текста? Это действительно сильно влияет на стоимость проектов или как? Но, возможно, я ошибаюсь.

— Jonas
источник

3

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

— Casebash

2

Я только что взглянул на типизацию утилит в C # (я не пользуюсь языком), и, хотя кажется, что он полностью соответствует определению типизации утиных утилит, требуемая многословность, похоже, не соответствует цели. Это не значит, что это не всегда полезно.

— Чинмай Канчи

3

Это только у меня так или больше критики статически типизированных языков, чем динамически типизированных? Кроме того, по моему опыту, выбор языков / технологий крупных "предприятий", по-видимому, продиктован текущими тенденциями / безопасными вариантами, а не какой-либо реальной технической заслугой.

— МАК

2

@ChinmayKanchi: многословие? Вы просто объявляете что-то как dynamicи начинаете использовать это. Это не более многословно, чем обычные вызовы методов или перегрузки операторов.

— Джои

4

Я не могу сосчитать количество часов, которые я потратил на ошибки отладки моей компании в Groovy в коде Grails, которые компилятор обнаружил бы немедленно, если бы мы использовали Java.

— WKS

46

Да, я верю, что они делают.

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

Скорость выполнения. По сравнению с C / C ++ / Fortran, Perl и Python такие медленные, это забавно.
Скорость инициализации. По сравнению с вышеупомянутыми быстрыми языками Java падает и плачет, поскольку JVM продолжает загружаться и загружаться и ... while(1)....
Prototype-способность. Исчерпывающее прохождение и выполнение работы по объявлению / определению, необходимой для C ++ или Java, увеличивает LOC, который является единственным известным показателем, который надежно коррелирует с количеством ошибок. Это также занимает много времени. Это также требует немного больше думать о типах и связях.
Внутренняя легковесность. Динамически возиться с вашими внутренними компонентами замечательно, пока вы не начнете отлаживать свой самоизменяющийся код . (Python, Lisp, Perl)
Проверка правильности. Компилятор может обеспечить быструю проверку правильности вашего кода на C ++, и это может быть очень приятно.
Статический анализ деталей. C и Java имеют довольно хороший статический анализ. Perl не является полностью статически анализируемым на теоретическом уровне (возможно, также Python). Я вполне уверен, что Лисп тоже нет.
Странные платформы только берут C, в общем.
Опорная цепь. Если у вас может быть контракт, на который вы будете смотреть и работать над ошибками, это огромно .

Если вы можете предположить, что в организации, с которой вы работаете, есть принцип «Движение вперед» (для этого есть учетный термин), и вы не просто случайно решите не работать с программным обеспечением, тогда у вас будет гораздо лучший повод для используя программное обеспечение. Так как крупный бизнес не продает (подразумевает ответственность за его поддержку) Python / Perl / $ dynamic_language, это значительно снижает риск.

По моему опыту, разработчики ПО с открытым исходным кодом часто сталкиваются с проблемой полной ответственности за исправления ошибок и выпуска обновлений. "Это бесплатно, вы работаете над этим!" это не ответ , который является приемлемым для большинства предприятий (не их основные compentencies, между прочим).

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

— Пол Натан
источник

16

"Это бесплатно, вы работаете над этим!" <- Самая большая проблема с F / OSS в целом, я бы +1, но у меня нет голосов :(

— Билли ONeal

4

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

— smithco

4

Вы можете получить коммерческую поддержку для любого крупного проекта с открытым исходным кодом. Большие компании используют динамически типизированный PL для больших частей (конечно, подходящие), Facebook использует PHP (UI) и Erlang (чат), Twitter использует Ruby (UI), Google использует Python (я не знаю для чего), а Lisp и Python являются используется во многих сложных исследовательских проектах. Примечание: я разработчик C #, я (почти) никогда не использовал динамически типизированный язык; все же эти пункты не имеют силы в значительной степени.

— Каве Шахбазян

4

Мне нравится ваш ответ, но Java не динамически набирается ...

— Mehrdad

2

@PaulNathan: Ты слишком много думаешь. Вопрос задавался о динамически типизированных языках, и в этом ответе Java упоминается так, как будто он динамически типизирован.

— Мердад

24

Вы даете слишком много технической поддержки лицам, принимающим решения Enterprise. Существует старая поговорка: «Никто не был уволен за покупку IBM». Если вы идете другим путем, и все становится непросто (они всегда так делают), никто не хочет рисковать быть обвиненным. Придерживайтесь стандартов и обвиняйте кого-то еще.

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

И давайте не будем забывать о миллиардных строках кода, написанных на VBA!

— JeffO
источник

1

+1 за "... предприятия завтрашнего дня [и] будут использовать эти языки".

— rdmueller

6

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

— Джорджио

17

Причина, по которой предприятия используют C, C ++, C # и Java, не в том, что они статически типизированы (по крайней мере, не напрямую). Я уверяю вас, что лица, принимающие решения на предприятии, не делают такой выбор на основе объективного сравнения систем типов.

Компании делают заботу о:

Долгосрочные затраты на обслуживание : можете ли вы ожидать, что все будет хорошо работать через 10 лет? Это на самом деле хорошо, если эволюция языка консервативна и обратно совместима (как с Java). Статическая типизация здесь полезна, потому что она улавливает основные типы ошибок во время компиляции, прежде чем они попадут в ваши производственные системы .....
Наличие талантов - сможете ли вы найти разработчиков для поддержки вашей новой блестящей системы? что если оригинальный разработчик уйдет, все остальные поймут код? Это ставит большие препятствия на пути введения любого «нового» языка (особенно если он также создает новые требования к развертыванию, системам сборки, операционной поддержке и т. Д.). Это дает огромные преимущества широко используемым языкам (C, C ++, C # и Java)
Затраты на интеграцию : легко ли подключиться / интегрироваться с другими технологиями, которые у вас уже есть или которые вы можете приобрести? Если у вас уже есть стек устаревших систем J2EE, вам необходимо интегрироваться с ними. Новое решение Java EE, вероятно, будет гораздо более практичным для этого, чем, например, Python.
Предсказуемость / низкий риск : подтверждена ли платформа / язык, и могу ли я быть уверен, что она будет работать? Это, как правило , более важным , чем просто производительность. Менеджеру гораздо легче убедить своего начальника выделить ему большой бюджет для рабочей силы, чтобы построить новую систему, чем вернуться назад и сказать, что она не сработала .....
Поддержка / поддержка предприятия - готовы ли основные международные организации поддерживать язык и платформу? Будут ли они подписывать контракт, чтобы поддержать меня, чтобы мне было, к кому обратиться, если что-то пойдет не так?
Нейтральность поставщика / независимость от платформы - собираюсь ли я быть привязанным к одному поставщику? Или у меня есть широкий выбор будущих вариантов поставщиков / путей перехода? Вы не хотите застрять в архитектурном тупике, неспособны добиться прогресса, пока ваши конкуренты едят ваш обед. Если вы выполняете свою работу должным образом как корпоративный архитектор, вам нужно подумать об этом как минимум на 5-10 лет вперед.

Лично я думаю, что если вы хотите использовать динамические языки в Enterprise, то ваш лучший шанс на данный момент - использовать что-то, что поддерживает существующую корпоративную экосистему. Наиболее заметными являются новые динамические языки JVM: например, JRuby, Groovy, Clojure. Что касается управления ИТ, то это «безопасный» выбор динамического языка, потому что они работают внутри и хорошо взаимодействуют с остальной частью корпоративной экосистемы Java.

— mikera
источник

1

Я не могу поверить, что никто еще не проголосовал за твой ответ.

— Себастьян Н.

11

Основной причиной того, что предприятия не начинают использовать такие языки, как Erlang, Ruby и Python, является тот факт, что они динамически типизированы.

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

К сожалению, практически нет языка со статической типизацией, который был бы столь же популярен, как имена крупных компаний. Почему среды программирования с открытым исходным кодом / свободные программы почти всегда динамически типизированы? Это может указывать на то, что язык со статической типизацией на самом деле не так прост в создании, а динамическая типизация - это «хак для ленивых» Если это так, то компании, которые выбирают языки с динамической типизацией, могут иметь смысл.

— Timwi
источник

8

В самом деле? Последнее, что я увидел, Google бросил большой вес и значительные усилия по разработке Python, в том числе нанял создателя Python и позволил ему тратить 50% своего времени на работу над языком. Google также вносит большое количество кода в Python, особенно теперь, когда unladen-swallow был объединен с исходным деревом Python 3. Это делает Python «большим бизнес-именем» для меня.

— Чинмай Канчи

13

@Chinmay Kanchi: Интересно, как вы делаете выводы из статистики с размером выборки 1.

— Тимви,

6

Туш. Тем не менее, некоторые из ваших выводов также ошибочны. Правильно реализовать динамический язык гораздо сложнее, чем реализовать статически типизированный язык. Динамическая типизация, конечно, не является «взломом ленивца», как вы выразились. Это позволяет разработчикам быть ленивым, но не человеком, который пишет компилятор / интерпретатор. На самом деле, оптимизация динамически типизированного языка настолько сложна, что я могу думать только об одном языке, который в последнее время получил широкое распространение (JavaScript), хотя существуют проекты оптимизации / JITting для других языков (Python, PHP).

— Чинмай Канчи

2

Кроме того, если вы думаете, что динамически типизированные языки наиболее часто используются в средах с открытым исходным кодом, это далеко не ясно. В зависимости от выбранного вами показателя, это может быть правдой, но часто это не так. Измеряя строки кода, С выигрывает с дальнего удара. Если вы измеряете, какие языки используются в проектах с открытым исходным кодом, включая многоязычные, наиболее популярными языками являются JavaScript, C, C ++ и PHP в этом порядке. Если вы измеряете только основной язык, наиболее популярными языками являются Perl, Java, C # и JavaScript. bit.ly/C6xTB

— Чинмай Канчи

7

Конечно, написать оптимизатор для языков с динамической типизацией сложно, но это не интерпретатор : вы можете покончить со всей проверкой типов, а остальное - то же самое. Ни один любитель языка не думает о написании оптимизатора. - Что касается последнего, я не имел в виду, что большинство программного обеспечения с открытым исходным кодом написано на языке программирования с динамической типизацией, а скорее на большинстве языков программирования с открытым исходным кодом (я сказал «среды», потому что я говорю о компиляторы / интерпретаторы, IDE и т. д.) динамически типизируются.

— Тимви

9

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

РЕДАКТИРОВАТЬ: я должен отметить, что мой основной язык программирования в настоящее время Python, который динамически типизируется. Лично мне нравится свобода, заключающаяся в том, что нет необходимости предварительно объявлять переменные, но иногда было бы неплохо указать (например), какие параметры принимает функция, чтобы отлавливать ошибки раньше, чем поздно.

— Чинмай Канчи
источник

1

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

— Уинстон Эверт

17

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

— Фрэнк Шиарар

1

@Frank: Мне безумно нравится, что в Perl есть настройка для принудительного объявления переменных. На мой взгляд, это одно из преимуществ Perl.

— Пол Натан

8

Динамически типизированные языки воспринимаются (некоторыми программистами / боссами) для создания кода, который также не работает. Тот факт, что динамически типизированная программа компилирует, очень мало говорит о ее правильности. Тот факт, что статически типизированный язык компилируется, говорит вам намного больше. (С другой стороны, между компиляциями все еще есть большой путь, и он поступает правильно, так что это может быть менее значимым, чем кажется)

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

Динамически типизированные языки медленнее, чем статически типизированные. (Но мы увидим, насколько хорошо работает работа над JIT)

— Уинстон Эверт
источник

2

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

— Фрэнк Шиарар

1

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

— Уинстон Эверт

2

@Frank: я использовал такой язык, и в большинстве случаев результатом был неразрывный беспорядок. (Честно говоря, это был PHP, и у PHP есть и другие проблемы, кроме динамической типизации)

— Billy ONeal,

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

— Shog9

@Winston: я говорю, что люди, с которыми я спорил, не имеют. Для меня это был случай, когда «динамическая типизация не может работать» ... но они с радостью будут использовать многие методы, впервые разработанные для динамических языков и для них (интегрированные среды разработки, рефакторинг, вне моей головы). Кроме того, подобные вопросы: stackoverflow.com/questions/2317579 указывают на то, что, хотя, вероятно, это не универсально, мой случай спора с программистами «не может работать, но я не пробовал» не является изолированным. (Я думаю, что оба подхода имеют ценность.)

— Фрэнк Шиарар,

8

Примечание: это в основном субъективно и основано на моем опыте и впечатлениях.

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

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

Динамически типизированные языки, с другой стороны, очень прагматичны. Преобразования типов часто происходят неявно, функции могут даже совпадать, если вы введете неправильный тип ввода, если он ведет себя достаточно схожим образом. В таких языках, как Python, даже уровни доступа будут основаны на контракте, а не на технических ограничениях (т. Е. Это только privateпотому, что вам сказали не использовать его, и у него забавное название).

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

Теперь причина того, что «корпоративные» компании часто предпочитают статически типизированные языки, заключается именно в том, что они более ограничительны и более явны в отношении этих ограничений. Хотя на практике даже статически типизированный код может быть взломан идиотами с помощью компилятора, многие проблемы будут гораздо более заметны гораздо раньше в процессе (т. Е. До выполнения). Это означает, что даже если кодовая база большая, монолитная и сложная, многие ошибки могут быть легко обнаружены без необходимости запуска кода или его передачи в отдел контроля качества.

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

Другой причиной того, что корпоративные корпорации не используют динамически типизированные языки, является устаревший код. Как бы глупо это ни казалось нам, ботаники, крупные корпорации часто будут придерживаться решений, которые работают, даже если они уже давно истекли. Вот почему так много крупных компаний используют Internet Explorer 6 и так медленно обновляют свои операционные системы. Именно поэтому они часто пишут новый код на «старых» языках (например, древние версии Java): гораздо проще добавить несколько строк кода в неживую часть программного обеспечения, чем получить разрешение на полное переписывание в новом язык.

tl; dr: статические языки больше похожи на бюрократию, поэтому руководителям предприятий они нравятся больше.

— Алан слива
источник

3

Языки с неаккуратными правилами печати создают много возможностей для вещей, которые не подходят для своего рода работы. Например, в JavaScript передача числа в код, который ожидает, что строка будет часто вести себя так, как если бы она передавала строковое представление этого числа, но не всегда. Например, попытка добавить 456 к 123 не даст 123456, но вместо этого приведет к 579. Если не ясно, кто отвечает за преобразование числа в строку, это может быть выполнено с избыточностью или не выполнено вообще.

— суперкат

1

@supercat, я думаю, что PHP и JavaScript являются хорошими примерами двух способов решения этой проблемы (в отношении операторов): в PHP операторы однозначны - +берет числа и добавляет их, если вы хотите использовать объединение .; в JS обе операции используют один и тот же оператор - если вы не знаете, как будут вести себя ваши значения, вы должны явно их преобразовать. Конечно, это также связано с произвольной типизацией и строгой типизацией (Python еще строже), но в основном вы должны либо убедиться, что ваши значения имеют правильный тип, либо заставить ваши операции обеспечивать ожидаемые типы.

— Алан Плам

1

Я не очень знаком с PHP, но, похоже, он использует то, что я бы назвал «правильным» подходом. Javascript ИМХО отвратителен во многих отношениях, но я думаю, что поведение «+» является одним из худших. На самом деле, я не убежден, что неаккуратная динамическая типизация будет иметь много преимуществ по сравнению с более сильной системой типов, которая позволяет интерфейсу объявлять, что вещи некоторого другого класса или типа интерфейса следует рассматривать как реализующие или производные от него, с конкретными правилами о том, как претензии будут приоритетными. Большое ограничение, которое я знаю о существующих структурно типизированных

— средах,

1

... если два человека независимо разрабатывают похожие интерфейсы, третьи лица не могут написать код, который может использовать их взаимозаменяемо. Если третья сторона может определить новый интерфейс и объявить, что реализации одного или обоих из существующих должны автоматически реализовывать новый (при необходимости используя обертки, поставляемые в новом интерфейсе), я думаю, что это обработает 99% того, что семантически хорошо о динамической типизации.

— суперкат

3

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

По моему опыту (и я не пытаюсь обобщить это утверждение), программисты, которые критикуют динамические языки, не использовали их. Разговор обычно идет "но при статической типизации компилятор ловит так много ошибок!" и я говорю "ну, это не проблема, по моему опыту". (Обычно другие программисты из Java, Delphi или аналогичного уровня; я не знаю программистов на Haskell или ML.)

Единственное, что меня действительно волнует, - это когда кто-то заявляет, что метод Foo не может быть выполнен (или может быть очень сложным) на языке с динамической типизацией ... когда эта методика была изобретена динамически типизированной и для нее язык. Иды? Болтовня. Автоматический рефакторинг? Болтовня. Вызывающие-о / реализаторы-о? Болтовня.

— Фрэнк Шиарар
источник

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

— Фрэнк Шиарар

6

Когда другой программист прибывает из Хаскелла, он / она уже знает, что это превосходный язык как для Java, так и для динамических языков;)

— Andres F.

0

Предприятия просто недостаточно быстро внедряют новые языки и инструменты, и для этого есть веские причины. Но когда один из основных инструментов, таких как C #, реализует некоторые из этих функций, они попадут в основные предприятия ....

— aggietech
источник

Я не знаю, почему за это проголосовали, но это проницательное утверждение. Предприятия медленные и консервативные. Люди также предпочитают постепенное изменение (например, динамическое ключевое слово в C #, которое позволяет вам иногда использовать динамическую типизацию на статически типизированном языке) внезапному изменению (например, Ruby).

— Ваддади Картик