Каков предполагаемый прирост производительности динамической типизации? [закрыто]

82

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

Итак: что можно сказать о производительности с динамической типизацией, которая действительно является преимуществом самой модели типов?

Пояснение: меня больше интересуют большие / средние проекты, чем быстрые хаки. :-)

Ханс-Петер Стёрр
источник
10
Вы ожидаете, что «статический дуэт» будет быстрее или продуктивнее, чем «динамический дуэт»?
Steve314
Что вы имеете в виду с дуэтом? В любом случае: я могу вспомнить пару причин, по которым статическая типизация более продуктивна, чем динамическая типизация: больше проверок компилятором на наличие ошибок, завершение кода, больше информации о намерениях программиста в коде. Вот почему я спрашиваю об обратном.
Ганс-Петер Стёрр
11
Это была шутка с точкой. «Динамичный дуэт» - это Бэтмен и Робин. Они бы не вселили столько страха в преступный мир Готэм-сити, если бы их назвали «статическим дуэтом». Поскольку разработчики - люди, поверхностные вещи могут иметь значение независимо от того, что означают термины.
Steve314
Мой первый вопрос: знаю ли я, что делаю или нет. Если я это сделаю, то я могу разрабатывать вещи заранее, и статическая типизация имеет смысл. Если я этого не сделаю, то мне придется много чего менять на лету, и динамическая типизация будет проще. Common Lisp - лучший язык, который я нашел, когда не знаю, что делаю. (Предостережение: я только поцарапал Haskell, и поэтому у меня нет хорошего восприятия статической типизации.)
Дэвид Торнли
2
Я полностью согласен с Джоном Скитом msmvps.com/blogs/jon_skeet/archive/2009/11/17/…
пользователь

Ответы:

99

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

Причины более продуктивной динамической типизации:

  • Это более кратко - много постороннего шаблонного кода можно удалить, если все динамически типизировано - объявления типов, логика типов и т. Д. При прочих равных условиях более короткий код записывается незначительно быстрее, но, что более важно, его можно быстрее читать и поддерживать (поскольку вам не нужно пробираться по множеству страниц кода, чтобы понять, что происходит)
  • Более простые методы «взлома» , такие как «Утиная печать» и «Обезьяны-патчи», могут очень быстро принести вам результаты (хотя впоследствии они могут сбить вас с толку ...)
  • Более интерактивный - динамическая типизация, возможно, больше подходит для интерактивного, REPL-подобного программирования для быстрого прототипирования, отладки в реальном времени запущенных экземпляров программы или даже живого кодирования.
  • Тестовые случаи могут улавливать ошибки времени выполнения - при условии, что вы используете TDD или, по крайней мере, имеете хороший набор тестов, это должно устранить любые проблемы с типизацией в вашем коде.
  • Лучший полиморфизм - динамические языки потенциально могут стимулировать создание полиморфных функций и абстракций, которые могут повысить производительность и повторное использование кода. Например, Clojure широко использует динамический полиморфизм во многих своих абстракциях .
  • Прототипы - модели данных / объектов на основе прототипов, на мой взгляд, более мощные и гибкие, чем статически типизированные наследственные наследники. Динамические языки с большей вероятностью допускают или поощряют подход, основанный на прототипах, Javascript является отличным примером.

Причины более продуктивной статической типизации:

  • Лучший дизайн - необходимость заранее продумывать типы ценностей в вашем программном обеспечении может подтолкнуть вас к более чистым, более логичным решениям. (Я говорю могу - это все-таки можно спроектировать действительно плохой код ...)
  • Лучшая проверка времени компиляции - статическая типизация может позволить обнаруживать больше ошибок во время компиляции. Это огромное преимущество и, пожалуй, лучшая вещь в статически типизированных языках в целом.
  • Автозаполнение - статическая типизация также может дать больше информации в IDE, так что автоматическое завершение поиска кода или документации более эффективно.
  • Препятствует взлому - вы должны сохранять дисциплину типов в своем коде, что, вероятно, будет преимуществом для долгосрочной ремонтопригодности.
  • Вывод типов - в некоторых языках (например, Scala) это может дать вам много преимуществ краткости динамических языков, сохраняя дисциплину типов.

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

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

mikera
источник
14
+1, очень подробный ответ. Значение пункта «Лучшая проверка времени компиляции» не может быть подчеркнуто достаточно.
NoChance
8
Наряду с выводом типов, есть также перегрузка в стиле Haskell, шаблоны C ++, обобщения и, возможно, некоторые другие языковые функции, которые обеспечивают некоторые преимущества Duck-типирования в рамках статической типизации - при условии, что объект обеспечивает необходимый интерфейс (он «крякает, как утка») вы можете использовать его, практически независимо от того, какой объект номинального типа. «Почти» заключается в том, что некоторые подходы требуют некоторого вида «этого типа кряка, такого как объявление соответствующего типа утки» - например, объявление «класса» в Haskell.
Steve314
45
Я должен категорически не согласиться с вашим утверждением, что «более короткий код ... быстрее читать и поддерживать». Есть промежуточный шаг, понимание кода. Мне приходилось поддерживать код других людей как в Delphi, так и в JavaScript, и код Delphi гораздо проще понять, потому что он более многословен. И особенно потому, что в коде Delphi есть объявления типов, а в JavaScript нет. При работе с чем-то более сложным, чем примитивы, объявления типов делают тривиальным, чтобы увидеть, что ваши переменные и что они могут делать, что является важным знанием для работы по обслуживанию.
Мейсон Уилер
21
Я прошу не согласиться с большинством причин, приведенных здесь. Возьмите Haskell, который, вероятно, имеет самую строгую систему типов. У него есть REPL (на самом деле, по крайней мере, два), он обладает очень мощным полиморфизмом, выполняя сопоставление с образцом на конструкторах, и он настолько лаконичен, насколько можно надеяться - гораздо больше, чем Javascript или Python. Так что я полагаю, что некоторые из причин, о которых вы упомянули, являются случайными, а не свойственными слабо типизированным языкам.
Андреа
15
Я бы не стал слишком доверять «контрольным случаям». Вы не можете сравнить их с хорошей системой типов. Система типов обеспечивает доказательство того, что ваша функция будет вызываться по крайней мере с правильными параметрами типа, в то время как контрольные примеры могут предоставить только эмпирические доказательства. Тем не менее, даже это доказательство собрано в искусственной обстановке.
Инго
56

С динамическими языками вы можете писать дрянной код быстрее, чем при использовании типизированного языка.

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

Это увеличение производительности :)

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

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

Гийом
источник
11
Да, мой опыт такой же. Скрипт на 100 строк в порядке, и без таких замечательных инструментов мы были бы потеряны. Но проект Perl на 100 000 строк, скорее всего, станет кошмаром.
Инго
3
... и тогда у вас есть JavaScript (не только динамический, но и слабо типизированный).
День
16

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

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

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

Патрик
источник
18
И наоборот, если вы ошибочно ввели неверную программу, компилятор немедленно сообщит вам и выделит неверную строку. это повышает вашу производительность по сравнению с замечением неудачного запуска теста и отладкой для обнаружения ошибки.
MarkJ
5
универсальные контейнеры и явная совместная / контравариантность призваны «встать на вашем пути», если вы сделаете это неправильно. В чем выгода компиляции кода, который не будет работать во время выполнения?
М.Страмм
Обычно считается, что задание выполнено на 0%, пока все тесты не пройдут успешно. Только тогда ваш прогресс можно считать более чем ничего. Имея это в виду, я не думаю, что стоит измерять вашу производительность на чем-то, что еще не закончено.
Pijusn
-1 Не отвечает на реальный вопрос («повышение производительности», помните?) Кроме того, вы, вероятно, даже не хотите писать эти «действительные программы, которые система типов отклоняет». То, что ты можешь, не означает, что ты должен. И почему у вас даже есть «действительная программа», которую проверяет типограф? Что, вы кодировали программу на Javascript и вдруг попытались скомпилировать ее на Java?
Андрес Ф.
Те действительные программы, которые отклоняет система типов, могут помочь сократить ваш код, что приведет к меньшему количеству ошибок, которые система типов не может обнаружить (меньше кода = меньше ошибок). Компилятор / IDE, выделяющий строку, может быть выполнен на динамических языках с тестовыми значениями (т. Е. Разработкой, управляемой REPL), так что вы можете видеть промежуточные значения, и они могут обнаруживать ошибки, которые не может ваша система типов, а также ошибки типов. Вы также можете использовать статический вывод типа для выдачи предупреждений о типе.
aoeu256
15

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

Вам не нужно слишком много думать об этом - писать код, который делает что-то нетривиальное с любым объектом в Java, сложно и, вероятно, требует отражения, которое в основном динамически типизировано; с чем-то вроде JavaScript написание функции, которая делает что-то интересное для всех объектов, является второй натурой. Прекрасным примером была бы функция, которую я недавно написал, которая берет объект и заменяет все его методы на те, которые делают то же самое, но также запускают событие. Я понятия не имею, как приблизиться к чему-то подобному в Java. Однако я не уверен, насколько это связано с системами типов, а сколько из-за других языковых различий.

Тем не менее, я недавно начал использовать Haskell. Haskell позволяет мне писать абстрактный, универсальный код так же легко, как и любой другой язык с динамической типизацией, который я использовал. Мой пример на Java / JavaScript выше не имеет смысла в Haskell, потому что в нем нет объектов, методов, событий или даже большого количества мутаций, но другие виды универсального кода действительно легко написать.

Фактически, Haskell может написать некоторый общий код, который не могут динамически типизированные языки; Прекрасным примером является readфункция, которая в основном противоположна toString. Вы можете получить Intили, Doubleили любой другой тип, который вы хотите (если он находится в определенном классе типов). Вы даже можете иметь полиморфные константы , поэтому maxBoundмогут быть максимумом Int, Double, Char... и т.д.., Все зависит от того, какого типа он должен быть.

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

Однако даже в системе типов Haskell есть некоторые досадные проблемы, которых у вас не было бы в динамически типизированном языке. Самое большое, что меня раздражало, это способ обработки чисел; например, вы должны возиться с системой типов, которая будет использоваться length(из списка) как double, с чем у вас не было бы проблем без системы типов. Еще одна досадная вещь, с которой я столкнулся, - это работа с Word8типом int без знака и ожидаемые функции Int.

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

Тихон Джелвис
источник
1
Да, по некоторым причинам системы счисления трудно понять правильно. В скале это тоже беспорядок. Я думаю, что системы динамических типов побеждают руки над простыми статическими системами типов с точки зрения простоты работы с ней, но проигрывают от более продвинутых (таких как Scala, Haskell, ML и т. Д., Которые все используют варианты system-F ).
Эдгар Клеркс,
3
Ваш ответ имеет хорошие намерения, но содержит ошибки. Во-первых, неверно, что динамические языки «не имеют системы типов», поэтому это не может быть причиной, по которой они «облегчают написание универсального кода». Они не облегчают ситуацию, как показывает ваш собственный контрпример с Haskell (вы опровергаете свое собственное утверждение!). «Вам никогда не придется сражаться с системой типов» - это ложь: вы сражаетесь с ней каждый раз, когда должны исправить ошибку, вызванную недостаточной статической проверкой типов. Наконец, явное приведение Intвозвращаемого списком тривиально; пример: 1.0 + fromIntegral (length myList)т.е. просто использовать fromIntegral.
Андрес Ф.
2
Наконец, «писать код быстро»! = «Быть ​​более продуктивным». Ваш код должен работать! Если вы пишете программное обеспечение с ошибками, которое вы позже должны будете потратить на отладку и исправление, вы не будете продуктивными.
Андрес Ф.
«не думая слишком много», красный флаг для того, что означает большинство людей, когда они говорят о том, что динамически типизированные языки «более продуктивны»
Ataraxia
Если системы типов действительно улучшили производительность, где все полезные приложения в Haskell или Idris? Я думаю, что такие вещи, как простота понимания ошибки типа, «возможность внесения исправлений» (способность редактировать ваше приложение непредсказуемым образом) и 90% -ная проверка ошибок на doctests и вывод типа, могут быть более важными.
aoeu256
7

Q: Я часто слышал утверждение, что динамически типизированные языки более производительны, чем статически типизированные. Каковы причины этого требования? "

Это имеет исторические причины. Если вы вернетесь на несколько десятилетий назад, динамические языки были, несомненно, значительно более продуктивными, чем статические (хотя и значительно медленнее). Очевидно, что Perl гораздо более продуктивен, чем C, если вы знаете и то, и другое, и задача под рукой позволяет либо. Но со временем языки многое позаимствовали друг у друга, и новые языки сокращают разрыв (как в производительности, так и в производительности).

Вот некоторые моменты для рассмотрения:

Сборка мусора : Сборка мусора - огромный прирост производительности. Я считаю, что Java был первым основным статическим языком с GC. До этого статическое в основном означало ручное управление памятью. (Примечание: здесь и далее я рассматриваю только основные языки. Существует множество экспериментальных и нишевых языков, которые предоставят контрпримеры к любому пункту, который я сделаю.)

Безопасность памяти : это повышение производительности, при котором вам не нужно беспокоиться о том, чтобы выстрелить себе в ногу. До «управляемых» статических языков, таких как Java, статический обычно подразумевал прямой доступ к памяти. Отладка также является частью производительности, и небезопасный доступ к памяти может привести к действительно неясным ошибкам.

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

Большая стандартная библиотека. Известно, что Python рекламировался как «включенные батареи» из-за большой стандартной библиотеки. Это по сравнению с C, которые имеют очень минималистскую стандартную библиотеку. Но с такими платформами, как Java и .net, обширная стандартная библиотека становится стандартной, и новые языки, такие как Scala и F #, наследуют это «бесплатно».

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

Замыкания и лямбда-синтаксис - динамические языки обычно имели это с самого начала, но статические языки приняли это, совсем недавно Java.

REPL Возможность быстро тестировать фрагменты кода в интерактивном режиме - огромное преимущество. Но хотя инструменты IDE, такие как «немедленное» окно в Visual Studio, статические языки могут до некоторой степени эмулировать это.

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

Итог: Исторически это было правдой, но сегодня ответ менее ясен.


Q: Итак: что можно сказать о производительности с динамической типизацией, которая действительно является преимуществом самой модели типов?

Довольно сложно отделить модель динамической типизации от динамических языков, но в качестве примера C # принял более динамические функции с течением времени, даже несмотря на то, что его ядром является статический язык. Это действительно доказательство преимуществ модели динамического типа. Примеры:

Отражение Отражение - это, по сути, функция динамического набора текста. Вы проверяете типы объектов во время выполнения, а не во время компиляции. Когда это было введено, это было своего рода неодобрение, но в C # использование отражения становится все более и более повсеместным, например, ASP.Net MVC интенсивно использует отражение.

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

Linq to SQL, EF mv. Различные преобразователи Linq проверяют запросы как объекты времени выполнения и генерируют sql на лету. Он не становится более динамичным, чем проверка кода во время выполнения. CodeDom - это другая сторона медали, где код может быть сгенерирован во время выполнения.

Roslyn Roslyn в основном реализует eval, что когда-то считалось определяющей чертой действительно динамичного языка.

Динамическийdynamic -тип наиболее явно динамическая функция в C #, и рекламируется на обеспечение взаимодействия с внешними объектами и языками более простыми и производительными. Но он также используется в Asp.net MVC для удобства.

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

JacquesB
источник
Мне действительно не нравится этот ответ, потому что почти все вопросы не касаются основного вопроса: «Каков предполагаемый прирост производительности динамической типизациине динамические языки .
няня
@nanny Не могли бы вы уточнить разницу между языками с динамической типизацией и динамическими языками? (это одна из тех нечетких вещей). Не могли бы вы привести пример динамического типизированного языка, который не является динамическим языком, вместе с четкими определениями каждого из них?
@nanny: На самом деле вопрос касается «динамически типизированных языков», а не просто «динамической типизации».
JacquesB
@MichaelT Извините, я не понял. Динамическая типизация является одним из аспектов всех динамических языков. Этот ответ говорит о другом аспекте, который исторически сложился в динамических языках, фактически не затрагивая часть динамической типизации.
няня
1
@nanny: Я в основном отвечаю на это: «Я часто слышал утверждение, что динамически типизированные языки более производительны, чем статически типизированные. Каковы причины этого утверждения?» - Я полагаю, что причины этого утверждения исторические и связаны не только с динамической типизацией, но и с другими функциями динамических языков, повышающими производительность.
JacquesB
6

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

Правило гласит: чем лучше ваш язык, тем короче ваш код. Это довольно просто. Java показывает, как статическая типизация может пойти не так, как надо, что дает оппонентам много пищи. Плохо разработанные языковые функции обычно обходятся дорого, и статическая типизация в Java, во-первых, является обязательной (в противном случае большинство людей даже не использовали бы ее), а во-вторых, плохо выполняется.
Вот почему в сравнении большинство динамических языков блестят, хотя я бы сказал, что PHP не делает вашу жизнь лучше в целом (по крайней мере, до недавнего времени) из-за многих других странностей, не связанных с системами типов.

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

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

Программирование становится намного проще, когда ваш язык не привязывает вас к религиозному выбору парадигм, а пытается просто стать хорошим инструментом. Есть ряд статических и динамических языков и смешанных языков, которые преуспевают в этом. Некоторые из них просты в освоении, наиболее трудны в освоении.
Их сила заключается в том, что их индивидуальные особенности могут быть составлены так, чтобы легко создавать простые решения сложных проблем. Это исключает определенную ортогональность, которая может быть достигнута только посредством тонкого баланса включения или пропуска всех языковых особенностей, изученных до сих пор. Если вы попытаетесь добавить статическую типизацию в Ruby, вы нанесете вред, если вы попытаетесь отнять его у Хаскелла, вы сокрушите его. В противоположность этому: если вы заберете это у C, люди вряд ли заметят, а если вы заберете его у Java, некоторые могут поблагодарить вас.

По своему личному опыту могу сказать следующее: мне нравится Руби. Это расширило мой кругозор и способ, которым я проектирую системы. ИМХО это надо использовать для обучения людей программированию в первую очередь. Это ненавязчиво, мощно, лаконично, весело. Я понимаю, почему кому-то из ортодоксальных языков это понравится.
Однако в долгосрочной перспективе статическая типизация позволяет переносить работу на статический анализатор, а с выводом типа это происходит практически бесплатно. В результате получается код, который проще в обслуживании и часто выполняется быстрее.

Но опять же, статическая типизация сама по себе ничего не может сделать. Это вопрос комбинации. Я думаю, что где-то между F #, Scala, Nemerle, OCaml или haXe вы можете найти свой собственный оптимальный. Но это в конечном итоге зависит от вас, потому что язык должен позволять вам встраивать свои мысли без усилий, вместо того, чтобы заставлять их обвивать их. В конце концов, ничто не дает большего прироста производительности, чем если бы программирование было увлекательным

back2dos
источник
«Правило гласит: чем лучше ваш язык, тем короче код». Это может быть до мнения на каком-то уровне, но я не думаю, что это утверждение является точным. Укороченный код сам по себе не дает слишком много преимуществ, за исключением того, что он требует меньше ввода во время записи и, возможно, занимает меньше места на диске (что в любом случае не учитывается при компиляции языков). Я думаю, что знак хорошего языка передает как можно больше информации о том, что он делает, в максимально сжатой форме. Динамическая типизация не очень самодокументируется и в результате теряет удобство обслуживания
Ataraxia
Вы можете дополнить динамический типизированный код такой информацией, как значения по умолчанию / аргументы ключевых слов, типы, полученные из вывода типа, динамического вывода типа из JIT-компилятора или просто записав все функции в журнал [просмотрите каждую функцию или класс в работающей программе и замените их на версия функции, которая записывает свои аргументы / результаты). Затем вы можете увидеть журнал предыдущих запусков функции. Другая идея состоит в том, чтобы отклонить код, который не имеет аннотаций типов, контрактов во время выполнения или примеров тестов сеансов REPL, но дает разработчику возможность выбрать любой из трех.
aoeu256
3

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

Павел
источник
0

Я думаю, прежде всего вам нужно определить «производительность». Что означает «производительность» и что включает в себя?

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

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

yaobin
источник
В целом, это неправда, что вы можете написать функцию в меньшее количество строк, используя динамический язык. В любом случае, какие языки вы сравниваете?
Андрес Ф.
@AndresF. О, я в основном использую Python и C ++.
Яобин
1
Хорошо, но вы не можете обобщить динамический и статический, когда вы фактически сравниваете Python и C ++. C ++ не является особенно представительным примером языка со статической типизацией. Существуют чрезвычайно лаконичные статически типизированные языки, которые более или менее позволяют писать программы так же кратко, как на Python. Так что, в общем, ваше утверждение неверно.
Андрес Ф.
Да, но что, если вы редактируете свою программу, пока она еще работает? Любые проблемы во время выполнения будут возникать просто, и вы можете исправить их прямо здесь. В Лиспе всякий раз, когда вы получаете сообщение об ошибке, вы можете просто исправить свою программу и затем продолжить ее выполнение ... Да, для более сложных путей хорошо бы использовать аннотации типа [возможно, вы можете использовать постепенную типизацию, например, mypy & lisp], но эти более сложные пути также есть возможность нетипичных ошибок, так что избегание сложных путей на любом языке может быть хорошей идеей.
aoeu256
-1

Большим преимуществом динамического набора текста является производительность.

В Python, Ruby и т. Д. Помимо динамической типизации есть множество других факторов, повышающих производительность (параметры по умолчанию, словари встроенных типов и т. Д.). Совокупное влияние на производительность программиста впечатляет.

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

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

Что (возможно) было бы другим, если бы исследование проводилось сегодня:

  1. Java JVM улучшились до неузнаваемости.
  2. Современные IDE повысили бы производительность C ++ и Java-кодеров, но не имели большого значения для языков сценариев.
  3. C # будет включен и, вероятно, будет в том же парке, что и Java, но немного лучше.

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

Джеймс Андерсон
источник
2
Моя неясность заключается в том, что именно делает динамическая типизация для повышения вашей производительности. Эта статья интересна, однако речь идет об очень маленькой программе, и я не уверен, как она переносится на многие тысячи строк кода в большинстве программ.
Ханс-Петер Стёрр
5
Это исследование использует только C, C ++ и Java в качестве примеров статических языков, а затем пытается применить выводы, сделанные в традиционных языках программирования в целом. Все три языка имеют одинаковый базовый синтаксис с одинаковыми присущими недостатками производительности недостатками, что делает сравнение недопустимым. Дело не в том, что статические языки непродуктивны, а в том, что семейство C непродуктивно. Если бы они включили диалект Паскаля в свои тесты, они, скорее всего, пришли бы к другим выводам.
Мейсон Уилер
@mason - в этой области очень мало реальных объективных исследований. Это одно из немногих реальных исследований с фактическими числами и т. Д. «Образец» программы не тривиален! Он сочетает в себе элементы обработки словаря, сложные алгоритмы и большие объемы данных. Высокий процент неудачных и неудачных попыток подтверждает нетривиальный характер задачи.
Джеймс Андерсон
2
-1 Вы мало говорите о том, что делает языки с динамической типизацией более продуктивными. Параметры и словари по умолчанию можно найти в статических типизированных языках, таких как, например, Scala.
Йонас
1
@JamesAnderson Еще хуже, статья, на которую вы ссылаетесь, даже не поддерживает вашу точку зрения. Он сравнивает «языки сценариев» (часто динамические) с « обычными языками» (часто статическими). Теперь, скажите мне, что именно это «обычные» языки? Как вы думаете, это то же самое, что набор языков со статической типизацией? Еще хуже то , что бумага не что старая. К 2000 году уже существовало множество замечательных языков со статической типизацией, которые, возможно, были более продуктивными, чем динамические языки.
Андрес Ф.