OrderByDescending () на MSDN, что же, спрашивается, это означает?

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

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

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

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

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

Заключительное примечание: не волнуйтесь о производительности при сравнении статичный динамическому контролю типов. Современные МОНЕТЫ В ПЯТЬ ЦЕНТОВ как V8 и TraceMonkey прибывают опасно - близко к статической производительности языка. Кроме того, то, что Java на самом деле компилирует вниз в по сути динамический промежуточный язык, должно быть подсказкой, что для большинства случаев, динамический контроль типов не является огромной производительностью уничтожителем, которой некоторые люди разбирают его, чтобы быть.