Языки динамического типа по сравнению с языками статического типа

Ответ 1

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

Хорошим решением проблемы является здесь

Сторонники статической типизации утверждают, что преимущества статической типизации включают более раннее обнаружение ошибки программирования (например, предотвращение добавление целого к логическому) лучшей документации в форме типа (например, включение количество и типы аргументов, когда разрешение имен), больше возможностей для оптимизации компилятора (например, замена виртуальных вызовов прямым вызывает точный тип приемник известен статически), повышение эффективности работы (например, не все значения должны иметь динамический тип) и лучшее время разработки опыт разработчика (например, знание тип приемника, IDE может представить раскрывающееся меню всех применимые участники). Статическая типизация фанатики пытаются заставить нас поверить, что "хорошо типизированные программы не могут пойти не так". Хотя это, безусловно, звучит впечатляет, это довольно пусто выражение. Проверка статического типа - это абстракция времени компиляции время выполнения вашей программы и следовательно, это обязательно только частично звуковой и неполной. Это значит, что программы могут по-прежнему ошибаться из-за свойства, которые не отслеживаются типа, и что есть программы, пока они не могут неправильный не может быть проверен типом. импульс для упрощения статического ввода частичный и более полный тип причин системы, чтобы стать чрезмерно сложными и экзотические, о чем свидетельствуют концепции таких как "phantom типы" [11] и "шаткие типы" [10]. Это похоже на пытается запустить марафон с мячом и цепь привязана к вашей ноге и торжественно крича, что ты почти сделал это, даже несмотря на то, что вы вырулили после первой мили.

Адвокаты динамически типизированных Языки утверждают, что статическая типизация слишком жесткой, и что мягкость динамически языки делают их идеально подходит для прототипов с меняющимися или неизвестными требованиями, или которые взаимодействуют с другими системами которые непредсказуемо изменяются (данные и интеграция приложений). Конечно, динамически типизированные языки незаменим для динамическое поведение программы, такое как метод перехвата, динамическая загрузка, мобильный код, отражение во время выполнения и т.д. В матери всех работ по сценариев [16], Джон Оустерхаут утверждает что статически типизированные системы языки программирования делают код меньше многоразовые, более многословные, не более безопасные, и менее выразительные, чем динамически набранные языки сценариев. Эта аргумент по буквам сторонники динамически типизированных языки сценариев. Мы утверждаем, что это ошибка и попадает в той же категории, что и Суть декларативного программирования устраняя назначение. Или как Джон Хьюз говорит [8], это логично невозможность сделать язык более мощный, опустив функции. Защищая тот факт, что откладывание всех проверка типов во время выполнения является хорошей вещь, играет тактическую тактику с тот факт, что ошибки должны быть пойманы как в начале процесса разработки, так и возможно.

Ответ 2

Системы статического типа стремятся устранить определенные ошибки статически, проверяя программу, не запуская ее и пытаясь доказать обоснованность в определенных отношениях. Некоторые системы типов способны ловить больше ошибок, чем другие. Например, С# может исключать исключения нулевого указателя при правильном использовании, тогда как Java не имеет такой мощности. У Twelf есть система типов, которая фактически гарантирует, что доказательства будут прерваны, "решая" проблема с остановкой.

Однако система типа не идеальна. Чтобы устранить определенный класс ошибок, они должны также отклонить некоторые совершенно правильные программы, которые нарушают правила. Вот почему Twelf на самом деле не решает проблему остановки, он просто избегает этого, выкидывая большое количество абсолютно достоверных доказательств, которые случаются с чередованием. Аналогично, система типа Java отклоняет реализацию Clojure PersistentVector из-за использования гетерогенных массивов. Он работает во время выполнения, но система типов не может его проверить.

По этой причине большинство систем типов предоставляют "escape-последовательности", способы переопределения статической проверки. Для большинства языков они принимают форму кастинга, хотя некоторые (например, С# и Haskell) имеют целые режимы, отмеченные как "небезопасные".

Субъективно, мне нравится статическая типизация. Реализовано правильно (подсказка: не Java), система статического типа может быть огромной помощью в устранении ошибок до того, как они разрушат производственную систему. Динамически типизированные языки, как правило, требуют большего объема тестирования, что является утомительным в лучшие времена. Кроме того, статически типизированные языки могут иметь определенные функции, которые либо невозможны, либо небезопасны в системах динамического типа (неявные преобразования spring). Все это вопрос требований и субъективного вкуса. Я больше не буду строить следующий Eclipse в Ruby, чем попытаться написать резервную копию script в сборке или исправить ядро ​​с помощью Java.

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

Заключительное примечание: не беспокойтесь о производительности при сравнении статичности с динамической типизацией. Современные JIT, такие как V8 и TraceMonkey, опасно приближаются к статическим языковым характеристикам. Кроме того, тот факт, что Java на самом деле сводится к динамически развивающемуся промежуточному языку, должен быть намеком на то, что в большинстве случаев динамическая типизация не является огромным производителем-убийцей, который некоторые люди делают.

Ответ 3

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

Статические типы - это ограничение грамматики языка. Статически типизированные langauges строго можно сказать, чтобы они не были свободными от контекста. Простая истина заключается в том, что неудобно выражать язык в контексте свободных грамматик, которые не обрабатывают все свои данные просто как битовые векторы. Системы статического типа являются частью грамматики языка, если таковые имеются, они просто ограничивают его больше, чем свободная от контекста грамматика, поэтому грамматические проверки происходят в два прохода над источником. Статические типы соответствуют математическому понятию теории типов, теория типов в математике просто ограничивает законность некоторых выражений. Например, я не могу сказать 3 + [4,7] в математике, это из-за теории его типов.

Статические типы, таким образом, не являются способом "предотвращения ошибок" с теоретической точки зрения, они являются ограничением грамматики. Действительно, при условии, что +, 3 и интервалы имеют обычные теоретические определения набора, если мы удалим систему типов 3 + [4,7], получим довольно хорошо определенный результат, что набор. "Ошибки типа времени выполнения" теоретически не существуют, практическое применение системы типов - предотвращение операций, которые для людей не имеют смысла. Операции по-прежнему являются просто смещением и манипуляцией битами, конечно.

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

1: доказать, что ошибки типа будут происходить в программе
2: доказать, что они не будут встречаться в программе

Это может показаться мне противоречивым. Но что делает C или Java-тип checker, это отклоняет программу как "неграмматическую" или как она называет ее "ошибка типа", если она не может добиться успеха в 2. Она не может доказать, что они не будут происходить, это не означает, что они не будут происходить, это просто означает, что он не может это доказать. Вполне возможно, что программа, которая не будет иметь ошибки типа, отвергается просто потому, что она не может быть доказана компилятором. Простой пример if(1) a = 3; else a = "string";, конечно, поскольку он всегда верен, ветвь else никогда не будет выполняться в программе, и ошибка типа не возникнет. Но он не может доказать эти случаи в общем, поэтому он отверг. Это основная слабость множества статически типизированных языков, защищая вас от вас самих, вы также должны быть защищены в тех случаях, когда вам это не нужно.

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

Другим преимуществом статической типизации является то, что типы известны во время компиляции, и, таким образом, компилятор может это использовать. Если мы в Java делаем "string" + "string" или 3 + 3, тег + в тексте в конце представляет собой совершенно другую операцию и дату, компилятор знает, какие из них выбрать сами.

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

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

Почему у них нет типов? Поскольку каждая операция определена и разрешена для каждого операнта, что такое "ошибка типа времени выполнения"? Это из теоретического примера чисто побочный эффект. Если выполнение print("string"), которое печатает строку, является операцией, то так же length(3), первый имеет побочный эффект записи string на стандартный вывод, последний просто error: function 'length' expects array as argument., что он. С теоретической точки зрения нет такой вещи, как динамически типизированный язык. Они являются нетипизированными.

Хорошо, очевидное преимущество "динамически типизированного" языка - выразительная сила, система типов - это не что иное, как ограничение выразительной силы. И вообще, языки с системой типов действительно будут иметь определенный результат для всех тех операций, которые не разрешены, если система типов просто игнорируется, результаты просто не имеют смысла для людей. Многие языки теряют свою полноту Тьюринга после применения системы типов.

Очевидным недостатком является тот факт, что могут произойти операции, которые будут приводить к результатам, несущественным для людей. Чтобы защититься от этого, динамически типизированные языки обычно переопределяют эти операции, вместо того, чтобы производить этот бессмысленный результат, они переопределяют его, чтобы иметь побочный эффект при написании ошибки и, возможно, полностью остановить программу. Это вовсе не "ошибка", на самом деле спецификация языка обычно подразумевает это, это так же поведение языка, как печать строки с теоретической точки зрения. Таким образом, системы типов заставляют программиста рассуждать о потоке кода, чтобы убедиться, что этого не происходит. Или действительно, причина, по которой это происходит, также может быть полезна в некоторых моментах для отладки, показывая, что это не "ошибка" вообще, а четко определенное свойство языка. По сути, единственный остаток "динамического набора", который имеет большинство языков, защищен от деления на ноль. Это динамическая типизация, нет типов, нет больше типов, чем нулевой тип, отличный от всех остальных. То, что люди называют "типом", - это еще одно свойство нулевой точки, например длина массива или первый символ строки. И многие динамически типизированные языки также позволяют вам записывать такие вещи, как "error: the first character of this string should be a 'z'".

Другое дело, что динамически типизированные языки имеют тип, доступный во время выполнения, и обычно могут проверять его и решать с ним и решать из него. Конечно, теоретически это не отличается от доступа к первому char массива и тому, что он есть. Фактически, вы можете создать свой собственный динамический C, просто используйте только один тип, например long long int, и используйте первые 8 бит его для хранения ваших "типов" функций и записи соответственно, которые проверяют его и выполняют добавление float или integer. У вас есть статически типизированный язык с одним типом или динамическим языком.

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

Как я уже отмечал, "статически типизированный" в общем случае означает случай 2, виновный до тех пор, пока не окажется невиновным. Но некоторые языки, которые не выводят свою систему типов из теории типов при любом правиле использования 1: Иннокентий до тех пор, пока не будут признаны виновными, что может быть идеальным гибридом. Итак, может быть, Typed Racket для вас.

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

Ответ 4

Возможно, самой большой "выгодой" для динамической типизации является более низкая кривая обучения. Нет системы типов для обучения и нет нетривиального синтаксиса для таких угловых случаев, как ограничения типа. Это делает динамическую типизацию доступной для гораздо большего числа людей и выполнимую для многих людей, для которых сложные системы статического типа недоступны. Следовательно, динамическая типизация улавливается в контексте образования (например, Scheme/Python at MIT) и доменных языках для не-программистов (например, Mathematica). Динамические языки также попадают в ниши, где у них мало или вообще нет конкуренции (например, Javascript).

Наиболее сжатые языки с динамическим типом (например, Perl, APL, J, K, Mathematica) являются специфичными для домена и могут быть значительно более сжатыми чем наиболее сжатые статически типизированные языки общего назначения (например, OCaml) в нишах, для которых они были разработаны.

Основными недостатками динамического набора текста являются:

• Ошибки времени выполнения.

• Может быть очень сложно или даже практически невозможно достичь того же уровня правильности и требует гораздо большего тестирования.

• Документация, не подтвержденная компилятором.

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

Лично я вырос на динамических языках, но не трогал их 40-футовым полюсом в качестве профессионала, если бы не было других жизнеспособных вариантов.

Ответ 5

Из Artima Ввод: сильный или слабый, статический или динамический статья:

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

слабая типизация означает, что вы можете смешивать типы без явного преобразования

В документе Паскаля Костанцы "Динамическая и статическая типизация - анализ на основе шаблонов" (PDF), он утверждает, что в некоторых случаях, статическая типизация более подвержена ошибкам, чем динамическая типизация. Некоторые статически типизированные языки заставляют вас вручную эмулировать динамическую типизацию, чтобы сделать "Правильную вещь" . Он обсуждался на Lambda the Ultimate.

Ответ 6

Это зависит от контекста. Там много преимуществ, которые подходят для динамической типизированной системы, а также для сильного ввода. Я считаю, что поток динамических типов быстрее. Динамические языки не ограничены атрибутами класса и компилятором, которые думают о том, что происходит в коде. У вас есть какая-то свобода. Более того, динамический язык обычно более выразителен и приводит к меньшему количеству кода, который хорош. Несмотря на это, это больше подвержено ошибкам, что также вызывает сомнения и больше зависит от покрытия unit test. Это простой прототип с динамическим языком, но обслуживание может стать кошмаром.

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

Ответ 7

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

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

Ответ 8

Это все о правильном инструменте для работы. Не лучше в 100% случаев. Обе системы были созданы человеком и имеют недостатки. Извините, но мы сосать и делать идеальный материал.

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

Ответ 9

Статический ввод: Языки, такие как Java и Scala, являются статическими.

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

для ex. int x; x = 10;

System.out.println(х);

Динамический ввод: Perl - это динамически типизированный язык.

Переменные не обязательно должны быть инициализированы до их использования в коде.

у = 10; используйте эту переменную в более поздней части кода