Динамические языки типа по сравнению со статическими языками типа
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
8 ответов
Способность интерпретатора вывести преобразования типов и преобразования типов делает время разработки быстрее, но это также может вызвать отказы во время выполнения, которые Вы просто не можете войти в статически типизированный язык, где Вы ловите их во время компиляции. Но который лучше (или даже если это всегда верно) горячо обсужден в сообществе в эти дни (и с долгого времени).
Хорошее взятие по проблеме от Статического контроля типов, Где Возможно, Динамического контроля типов При Необходимости: Конец холодной войны Между Языками программирования Erik Meijer и Peter Drayton в Microsoft:
Защитники статического контроля типов утверждают, что преимущества статического контроля типов включают более раннее обнаружение программирования ошибок (например, предотвращение добавления целого числа к булевской переменной), лучшая документация в форме подписей типа (например, слияние числа и типов аргументов при разрешении имен), больше возможностей для оптимизации компилятора (например, заменяя виртуальные вызовы прямыми вызовами, когда точный тип получателя известен статически), увеличил эффективность во время выполнения (например, не все значения должен нести динамический тип), и лучший опыт разработчика времени проектирования (например, знание типа получателя, IDE может представить выпадающее меню всех применимых участников). Фанатики статического контроля типов пытаются заставить нас полагать, что “хорошо введенные программы не могут пойти не так, как надо”. В то время как это, конечно, звучит впечатляющим, это - довольно вырожденный оператор. Статическая проверка типа является абстракцией времени компиляции поведения во время выполнения Вашей программы, и следовательно это обязательно, только частично звучат и неполный. Это означает, что программы могут все еще пойти не так, как надо из-за свойств, которые не прослежены средством проверки типа, и что существуют программы, которые, в то время как они не могут пойти не так, как надо, не могут быть проверены в типе. Импульс для того, чтобы сделать статический контроль типов меньше неравнодушный и больше полных систем типов причин для становления чрезмерно сложным и экзотичным, как засвидетельствовано понятиями, такими как “фантом вводит” [11] и “шаткие типы” [10]. Это похоже на попытку пробежать марафон с ядром на цепи, связанным с Вашим участком и торжествующе криком, что Вы почти сделали его даже при том, что Вы прыгнули с парашютом после первой мили.
Защитники динамически типизированных языков утверждают, что статический контроль типов слишком тверд, и что мягкость динамично языков делает их идеально удовлетворенными для разработки прототипа систем с изменением или неизвестными требованиями, или которые взаимодействуют с другими системами, которые изменяются непредсказуемо (интеграция данных и интеграция приложений). Конечно, динамически типизированные языки необходимы для контакта с действительно динамическим поведением программы, таким как перехват метода, динамическая загрузка, мобильный код, отражение во время выполнения, и т.д. В родительском элементе всех статей о сценариях [16], John Ousterhout утверждает, что системные языки программирования со статическим контролем типов делают код менее допускающим повторное использование, более подробным, не более безопасный, и менее выразительный, чем языки сценариев с динамическим контролем типов. Этот аргумент бессмысленно повторен буквально многими сторонниками языков сценариев с динамическим контролем типов. Мы утверждаем, что это - ошибка и попадает в ту же категорию как утверждающий, что сущность декларативного программирования устраняет присвоение. Или поскольку John Hughes говорит [8], это - логическая невозможность сделать язык более мощным путем исключения функций. Защита того, что задержка всей проверки типа на время выполнения является хорошей вещью, играет в страусовую тактику с тем, что ошибки должны быть зафиксированы максимально рано в процессе разработки.
Статические системы типов стремятся устранить определенные ошибки статически, осматривая программу, не выполняя его и пытаясь доказать разумность в определенных отношениях. Некоторые системы типов в состоянии зафиксировать больше ошибок, чем другие. Например, C# может устранить исключения нулевого указателя, когда используется правильно, тогда как Java не имеет такой силы. Twelf имеет систему типов, которая на самом деле гарантии, что доказательства завершатся , "решая" проблема остановки .
Однако никакая система типов не прекрасна. Для устранения конкретного класса ошибок они должны также отклонить определенные совершенно действительные программы, которые нарушают правила. Поэтому Twelf действительно не решает проблему остановки, он просто избегает его путем вывода большого количества совершенно допустимых доказательств, которые, оказывается, завершаются нечетными способами. Аналогично, система типов Java отклоняет Clojure PersistentVector реализация из-за ее использования разнородных массивов. Это работает во времени выполнения, но система типов не может проверить его.
По этой причине, большинство систем типов обеспечивает "Escape", способы переопределить статическое средство проверки. Для большинства языков они принимают форму кастинга, хотя у некоторых (как C# и Haskell) есть все режимы, которые отмечены как "небезопасные".
Субъективно, мне нравится статический контроль типов. Реализованный правильно (подсказка: не Java), статическая система типов может быть огромной справкой в избавлении от ошибок, прежде чем они разрушат производственную систему. Динамически типизированные языки имеют тенденцию требовать большего количества поблочного тестирования, которое утомительно в лучшие времена. Кроме того, статически типизированные языки могут иметь определенные функции, которые или невозможны или небезопасны в динамических системах типов (, неявные преобразования приходят на ум). Это - весь вопрос требований и субъективного вкуса. Я больше не создал бы следующий Eclipse в Ruby, чем я попытаюсь записать резервный сценарий в блоке или исправить ядро с помощью Java.
, О, и люди, которые говорят, что" x ввод в 10 раз более продуктивен, чем , ввод y" просто уносит дым. Динамический контроль типов может "чувствовать себя" быстрее во многих случаях, но он теряет позиции, как только Вы на самом деле пытаетесь заставить свое необычное приложение работать . Аналогично, статический контроль типов может казаться, что это - идеальная система поддержки, но один взгляд на некоторые более сложные универсальные определения типа в Java отправляет большинство разработчиков, несущихся за глазными шорами. Даже с системами типов и производительностью, нет никакой серебряной пули.
Заключительное примечание: не волнуйтесь о производительности при сравнении статичный динамическому контролю типов. Современные МОНЕТЫ В ПЯТЬ ЦЕНТОВ как V8 и TraceMonkey прибывают опасно - близко к статической производительности языка. Кроме того, то, что Java на самом деле компилирует вниз в по сути динамический промежуточный язык, должно быть подсказкой, что для большинства случаев, динамический контроль типов не является огромной производительностью уничтожителем, которой некоторые люди разбирают его, чтобы быть.
От Artima Ввод: Сильный по сравнению со Слабым, Статическим по сравнению с Динамическим статья:
строгий контроль типов предотвращает смешивание операций между несогласованными типами. Для смешивания типов необходимо использовать явное преобразование
, слабый контроль типов означает, что можно смешать типы без явного преобразования
В статье Pascal Costanza, Динамичный по сравнению со Статическим контролем типов — Основанный на шаблоне Анализ (PDF), он утверждает, что в некоторых случаях, статический контроль типов более подвержен ошибкам, чем динамический контроль типов. Некоторые статически типизированные языки вынуждают Вас вручную эмулировать динамический контроль типов, чтобы сделать "Правильную Вещь". Это обсуждено в Лямбда Окончательное .
Существует много разных вещей о статических и динамических языках. Для меня основное различие - то, что на динамических языках переменные не имеют зафиксированных типов; вместо этого, типы связываются со значениями. Из-за этого точный код, который выполнен, является неопределенным до времени выполнения.
В ранних или naГЇve реализациях это - огромная производительность, перетаскивают, но современные МОНЕТЫ В ПЯТЬ ЦЕНТОВ добираются дразняще близко к лучшему, которое можно получить с оптимизацией статических компиляторов. (в некоторых случаях края, еще лучше, чем это).
Это - все о правильном инструменте для задания. Ни один не лучшие 100% времени. Обе системы были созданы человеком и имеют дефекты. Извините, но мы сосем и создание идеального материала.
мне нравится динамический контроль типов, потому что он выходит из моего пути, но да ошибки периода выполнения могут накопиться, который я не запланировал. Где, поскольку статический контроль типов может зафиксировать вышеупомянутые ошибки, но управлять новичком (на типизированных языках) программист сумасшедшая попытка бросить между постоянным символом и строкой.
Это зависит от контекста. Есть много преимуществ, которые подходят как для динамически типизированной системы, так и для строго типизированной. Я считаю, что поток языков динамических типов быстрее. Динамические языки не ограничены атрибутами класса и компилятором, который думает о том, что происходит в коде. У тебя есть какая-то свобода. Кроме того, динамический язык обычно более выразителен и приводит к меньшему количеству кода, что хорошо. Несмотря на это, он более подвержен ошибкам, что также вызывает сомнения и больше зависит от покрытия модульных тестов. Это простой прототип с динамическим языком, но обслуживание может стать кошмаром.
Основным преимуществом по сравнению со статической типизированной системой является поддержка IDE и, конечно же, статического анализатора кода. Вы становитесь более уверенными в коде после каждого изменения кода. С такими инструментами обслуживание простое.
Возможно, самое большое «преимущество» динамического набора текста - это более мелкая кривая обучения. Нет системы типов для изучения и нетривиального синтаксиса для крайних случаев, таких как ограничения типа. Это делает динамическую типизацию доступной для гораздо большего числа людей и осуществимой для многих людей, для которых сложные системы статических типов недоступны. Следовательно, динамическая типизация прижилась в контексте образования (например, Scheme / Python в Массачусетском технологическом институте) и предметно-ориентированных языков для непрограммистов (например, Mathematica ). Динамические языки также завоевали популярность в нишах, где у них мало или совсем нет конкуренции (например, Javascript).
Наиболее сжатые языки с динамической типизацией (например, Perl, APL, J, K, Mathematica ) зависят от предметной области и могут быть значительно более краткими, чем наиболее сжатые языки общего назначения со статической типизацией (например, OCaml ) в нишах, для которых они были предназначены.
Основные недостатки динамической типизации:
Ошибки типов во время выполнения.
Может быть очень сложно или даже практически невозможно достичь того же уровня правильности и требует значительно большего количества тестов.
Нет документации, проверенной компилятором.
Низкая производительность (обычно во время выполнения, но иногда вместо этого во время компиляции, например, по схеме Сталина) и непредсказуемая производительность из-за зависимости от сложных оптимизаций.
Лично я вырос на динамических языках, но как профессионал не стал бы трогать их 40-футовым полюсом, если бы не было других жизнеспособных вариантов.
Ну, оба они очень-очень-очень-очень неправильно поняты, и это две совершенно разные вещи. , которые не исключают друг друга .
Статические типы - это ограничение грамматики языка. Строго говоря, статически типизированные языки не являются контекстно-зависимыми. Простая истина заключается в том, что становится неудобным разумно выражать язык в контекстно-свободных грамматиках, которые не обрабатывают все свои данные просто как битовые векторы. Системы статических типов являются частью грамматики языка, если таковые имеются, они просто ограничивают ее больше, чем это могла бы сделать контекстно-свободная грамматика. Таким образом, грамматические проверки действительно происходят в два прохода по исходному тексту.Статические типы соответствуют математическому понятию теории типов, теория типов в математике просто ограничивает законность некоторых выражений. Например, я не могу сказать 3 + [4,7] в математике, это из-за теории типов.
Статические типы, таким образом, не являются способом «предотвращения ошибок» с теоретической точки зрения, они являются ограничением грамматики. Действительно, при условии, что +, 3 и интервалы имеют обычные теоретические определения множеств, если мы удалим систему типов 3 + [4,7] , мы получим довольно хорошо определенный результат, то есть набор. «Ошибки типов во время выполнения» теоретически не существуют, практическое использование системы типов заключается в предотвращении операций, которые для людей не имели бы смысла. Операции, конечно же, по-прежнему являются просто перемещением и манипулированием битами.
Загвоздка в том, что система типов не может решить, будут ли такие операции выполняться или нет, будет ли разрешено их выполнение. Например, точно разделите набор всех возможных программ на те, которые будут иметь «ошибку типа», и те, у которых нет. Он может сделать только две вещи:
1: доказать, что в программе могут возникать ошибки типа
2: докажите, что они не будут происходить в программе
. Может показаться, что я противоречу самому себе. Но то, что делает средство проверки типов C или Java, - это отклонение программы как «неграмматической» или, как он называет это, «ошибка типа», если она не может преуспеть в 2. Она не может доказать, что они не правы. не произойдет, это не значит, что они не произойдут, это просто означает, что он не может этого доказать.Вполне возможно, что программа, в которой не будет ошибки типа, будет отклонена просто потому, что компилятор не может ее доказать. Простой пример: if (1) a = 3; else a = "string"; , разумеется, поскольку оно всегда истинно, ветвь else никогда не будет выполняться в программе, и ошибки типа не произойдет. Но он не может доказать эти случаи в общих чертах, поэтому отклоняется. Это основная слабость многих языков со статической типизацией, поскольку они защищают вас от самих себя, вы также обязательно защищены в тех случаях, когда вам это не нужно.
Но, вопреки распространенному мнению, существуют также языки со статической типизацией, которые работают по принципу 1. Они просто отклоняют все программы, которые, как они могут доказать, вызывают ошибку типа, и пропускают все программы, которые они не могут использовать. . Так что, возможно, они разрешают программы, в которых есть ошибки типа, хорошим примером является Typed Racket, гибрид между динамической и статической типизацией. Некоторые утверждают, что в этой системе вы получаете лучшее из обоих миров.
Еще одно преимущество статической типизации состоит в том, что типы известны во время компиляции, и поэтому компилятор может это использовать. Если мы в Java выполняем «строка» + «строка» или 3 + 3 , оба токена + в тексте в конце представляют собой совершенно другую операцию и данные , компилятор знает, какой из типов выбрать.
Теперь я собираюсь сделать здесь очень спорное заявление, но будьте терпеливы: «динамической типизации» не существует .
Звучит очень спорно, но это правда, что языки с динамической типизацией с теоретической точки зрения нетипизированы . Это просто статически типизированные языки только с одним типом. Или, проще говоря, это языки, которые на практике грамматически порождаются контекстно-свободной грамматикой.
Почему у них нет типов? Поскольку каждая операция определена и разрешена для каждого операнта,что именно такое «ошибка типа выполнения»? Это чисто теоретический пример побочный эффект . Если выполнение print ("string") , которое печатает строку, является операцией, то также и length (3) , первое имеет побочный эффект записи string ] в стандартный вывод, последняя просто ошибка : функция 'length' ожидает в качестве аргумента массив. , вот и все. С теоретической точки зрения не существует такой вещи, как язык с динамической типизацией. Они нетипизированы
Хорошо, очевидное преимущество «динамически типизированного» языка - выразительная сила, система шрифтов - не что иное, как ограничение выразительной силы. И вообще, языки с системой типов действительно имели бы определенный результат для всех тех операций, которые недопустимы, если бы система типов просто игнорировалась, результаты просто не имели бы смысла для людей. Многие языки теряют свою полноту по Тьюрингу после применения системы типов.
Очевидным недостатком является то, что могут происходить операции, которые могут привести к результатам, бессмысленным для человека. Чтобы защититься от этого, языки с динамической типизацией обычно переопределяют эти операции, вместо того, чтобы производить этот бессмысленный результат, они переопределяют его, чтобы иметь побочный эффект в виде записи ошибки и, возможно, полной остановки программы. Это вовсе не «ошибка», фактически, спецификация языка обычно подразумевает это, это такое же поведение языка, как печать строки с теоретической точки зрения.Таким образом, системы типов заставляют программиста размышлять о потоке кода, чтобы убедиться, что этого не происходит. Или, действительно, причина, по которой это происходит , также может быть полезна в некоторых случаях для отладки, показывая, что это вовсе не «ошибка», а четко определенное свойство языка. По сути, единственный остаток «динамической типизации», который есть в большинстве языков, - это защита от деления на ноль. Вот что такое динамическая типизация: типов нет, типов не больше, чем этот ноль - это другой тип, чем все другие числа. То, что люди называют «типом», - это просто еще одно свойство данных, такое как длина массива или первый символ строки. Многие языки с динамической типизацией также позволяют записывать такие вещи, как «ошибка: первым символом этой строки должна быть буква« z »» .
Другое дело, что языки с динамической типизацией имеют тип, доступный во время выполнения, и обычно могут его проверять, обрабатывать и принимать решения. Конечно, теоретически это ничем не отличается от доступа к первому символу массива и просмотра того, что это такое. Фактически, вы можете создать свой собственный динамический C, просто используйте только один тип, например long long int, и используйте его первые 8 бит, чтобы сохранить свой «тип» и написать соответствующие функции, которые проверяют его и выполняют сложение чисел с плавающей запятой или целых чисел. У вас есть статически типизированный язык с одним типом или динамический язык.
На практике все это показывает, что языки со статической типизацией обычно используются в контексте написания коммерческого программного обеспечения, тогда как языки с динамической типизацией обычно используются в контексте решения некоторых проблем и автоматизации некоторых задач. Написание кода на статически типизированных языках просто занимает много времени и является громоздким, потому что вы не можете делать то, что, как вы знаете, будет хорошо, но система типов по-прежнему защищает вас от самих себя от ошибок, которых вы не делаете. Многие программисты даже не осознают, что они делают это, потому что это в их системе, но когда вы кодируете на статических языках, вы часто обходите тот факт, что система типов не позволит вам делать вещи, которые не могут пойти не так, потому что это не могу доказать, что это не пойдет не так.
Как я уже отмечал, «статически типизированный» в целом означает случай 2, виновен до тех пор, пока не будет доказана невиновность. Но некоторые языки, которые вообще не выводят свою систему типов из теории типов, используют правило 1: невиновен, пока виновность не доказана, что может быть идеальным гибридом. Так что, возможно, Typed Racket для вас.
Также, что ж, в качестве более абсурдного и крайнего примера, я в настоящее время реализую язык, в котором «типы» действительно являются первым символом массива, это данные, данные типа «тип», «тип», который сам по себе является типом и данным, единственным данным, имеющим себя как тип. Типы не являются конечными или ограниченными статически, но новые типы могут быть сгенерированы на основе информации времени выполнения.