Динамически против статически типизированных языков изучения [закрыто]

69

Существуют ли исследования эффективности языков со статической и динамической типизацией?

В частности:

  • Измерения производительности программиста
  • Коэффициент дефектности

Также включая эффекты от того, используется ли юнит-тестирование.

Я видел много дискуссий о достоинствах любой из сторон, но мне интересно, проводил ли кто-нибудь исследование по этому вопросу.

productivity comparison type-systems dynamic-typing static-typing Уинстон Эверт
источник
8
@bigown, мне не кажется, что проблемы производительности и дефекты связаны с теорией информатики
Уинстон Эверт
2
@Winston: изучение подобных проблем - дело программистов, а не программистов.
Маньеро
9
@bigown, да, это проблема информатики, но не проблема теории информатики. Теория CS по существу имеет дело с тем, что мы можем математически доказать о программах и вычислениях. Вопросы производительности программиста не являются теоретическими вопросами. Здесь обсуждались вопросы динамической типизации как здесь, так и на stackoverflow. Там не было ничего по истории.
Уинстон Эверт
8
Вопрос совершенно по теме. Этот вопрос обсуждает одно из самых важных свойств инструментов, которые мы используем для программирования.
Фрэнк Шиарар
4
@Winston: Системы типирования принадлежат теории CS, а практические исследования - нет.
Дэвид Торнли

Ответы:

42

Некоторые предложили прочитать:

Не совсем на статической типизации, но связано:

Некоторые интересные статьи или очерки по теме или по статическому анализу программ в целом:

И для тех, кто хотел бы знать, что это такое:

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

ЛичноЯ твердо считаю, что статическая типизация поверх динамической типизации облегчает обнаружение ошибок. Я слишком много трачу на поиски опечаток и мелких ошибок, подобных этим, в JavaScript или даже в Ruby-коде. И когда дело доходит до мнения, что динамическая типизация дает вам повышение производительности, я думаю, что в основном сводится к инструментам. Если в статически типизированных языках есть нужные инструменты, позволяющие выполнять фоновую перекомпиляцию и обеспечивающие интерфейс REPL, то вы получаете преимущества обоих миров. Например, в Scala это позволяет легко учиться и создавать прототипы в интерактивной консоли, но дает вам преимущества статической типизации (и более сильной системы типов, чем многие другие языки, за исключением ML-языков). Точно так же я не думаю, что у меня потеря производительности при использовании Java или C ++ (из-за статической типизации), до тех пор, пока я использую IDE, которая помогает мне в этом. Когда я возвращаюсь к кодированию только с простыми конфигурациями (редактор + компилятор / интерпретатор), то мне кажется, что более громоздкие и динамические языки кажутся более простыми в использовании. Но вы все еще охотитесь за ошибками. Я предполагаю, что люди скажут, что проблема с инструментами является обратимым аргументом, так как если бы инструменты были лучше для динамических языков, тогда большинство ошибок и опечаток были бы указаны во время кодирования, но это отражает недостаток в системе, по моему мнению. Тем не менее, я обычно создаю прототипы на JRuby и буду писать код на Java позже, большинство вещей, которые я делаю. как если бы инструментальные средства были лучше для динамических языков, тогда большинство ошибок и опечаток были бы указаны во время кодирования, но это, на мой взгляд, отражает недостаток системы. Тем не менее, я обычно создаю прототипы на JRuby и буду писать код на Java позже, большинство вещей, которые я делаю. как если бы инструментальные средства были лучше для динамических языков, тогда большинство ошибок и опечаток были бы указаны во время кодирования, но это, на мой взгляд, отражает недостаток системы. Тем не менее, я обычно создаю прототипы на JRuby и буду писать код на Java позже, большинство вещей, которые я делаю.

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

haylem
источник
Это обнаружение ошибок - это в основном из-за неправильно написанных имен переменных или имен методов или где-то посередине? (Я ненавижу неявное объявление переменных именно по этой причине: в Smalltalk вы объявляете все свои переменные сверху, так что вы сразу же знаете, когда набрали неверное имя переменной. (Опечатки имени метода иногда тоже обнаруживаются, если имя метода никогда был использован в изображении раньше.))
Фрэнк Шиарар
Что касается инструментов, я должен сказать, что это зависит от вашего языка - у Smalltalk есть отличные инструменты, в том числе Refactoring Browser, который Eclipse имеет (как мне сказали), который еще предстоит наверстать.
Фрэнк Ширар
@Frank Shearar, так как я начал с Ruby (с Java), я понял, что то, что говорит @ haylem, вероятно, не относится к Smalltalk. Моя мантра об автоматическом рефакторинге не может быть невозможной и в динамически набираемых языках. Я полностью согласен с разделом «лично» Хейлема… игнорируя, конечно, SmallTalk :) Это справедливо, в некоторой степени, поскольку SmallTalk, хотя и не умер, определенно не пользуется популярностью, которую имеют Python или Ruby (сейчас в октябре 2010 г.) ).
Дэн Розенстарк
3
@haylem, лично я благодарю вас за то, что вы почувствовали, что я не единственный человек в мире, который работает на динамических языках, но, когда ему предоставляется выбор, много раз ВЫБИРАЕТ языки со статической типизацией (один и тот же случай, Java против JRuby или Groovy).
Дэн Розенстарк
4
Это интересно, потому что я предпочитаю динамическую типизацию по разным причинам. Я имею в виду, что быстрая компиляция и интерактивный интерпретатор полезны, но не потому, что мне нравится динамическая типизация. Мне нравится динамическая типизация, потому что я нахожу много ситуаций, в которых языки статической типизации просто затрудняют или не описывают конкретную концепцию.
Уинстон Эверт
19

Буквально вчера я нашел это исследование: модульного тестирования недостаточно. Вам тоже нужна статическая типизация.

По сути, автор использовал инструмент, способный автоматически преобразовывать проект из нестатического языка типизации в язык статического ввода (от python до haskell)

Затем он выбрал несколько проектов Python с открытым исходным кодом, которые также включали разумное количество тестовых модулей, и автоматически преобразовал их в haskell.

Перевод на Haskell выявил серию ошибок, связанных с типом переменных: ошибки не были обнаружены тестовыми блоками.

PBrando
источник
4
Неудобная правда динамического набора текста.
Ден
6
«Перевод на Haskell выявил серию ошибок, связанных с типом переменных: ошибки не были обнаружены тестовыми блоками.»: При использовании языка с динамической типизацией вы должны вручную тестировать свойства своего кода, которые статически Тип языка автоматически проверяется компилятором. Это более трудоемко и подвержено ошибкам. +1
Джорджио
4
Я ответил на публикацию по этой ссылке в Reddit. Я не думаю, что выводы, сделанные из бумаги, являются разумными.
Veedrac
Обе системы печати имеют свои плюсы и минусы и их использование. Это все равно, что обсуждать вопрос о привлечении пулемета к рукопашному бою. Это религиозная война далеко от конца. Тем не менее, я согласен с Veedrac. Нестатические языки нуждаются в большем количестве тестовых случаев для выявления ошибок, вызванных типами. Это их характер и мошенничество. Но программист должен написать тест, который улавливает ошибку в коде, вызванную неожиданным состоянием ввода, а не обязательно исчерпывающим тестированием типа ввода.
Андре Фигейредо
10
  • Ссылка на обсуждение статьи ACM « Эксперимент о статических и динамических системах типов » (2010 г.) статьи Стефана Ханенберга (ссылка на которую Лорин Хохштейн в предыдущем посте).
  • Вывод: производительность для аналогичного качества была выше в динамическом языке.
  • Потенциальные отклонения / вопросы достоверности: все экспериментальные предметы были студентами. Также ограничено разнообразие задач программирования (испытуемым предлагалось реализовать сканер и парсер).
  • Статья ACM « Влияют ли языки программирования на производительность? » (2007 г.) Делори, Кнудсона и Чуна.
  • Вывод: JavaScript, Tcl, Perl более производительны, чем C # C ++ и Java. Python и PHP находятся посередине.
  • Потенциальные отклонения / проблемы с достоверностью: Отсутствие показателя качества (например, ошибки, обнаруженные после выпуска). Никакой меры надежности (программное обеспечение, написанное на статически типизированных языках, более надежно?). Пример смещения - все проекты были открыты, взятые из открытых репозиториев CVS. Кроме того, нет различия между слабо и строго типизированными языками (например, указатели).
  • Дипломная работа Майкла Ф. Сиока " Эмпирическое исследование производительности и качества программного обеспечения " (2008)
  • Вывод: выбор языка программирования не оказывает существенного влияния на производительность или качество. Тем не менее, это влияет на стоимость рабочей силы и «качество в общем портфеле программных проектов».
  • Потенциальные ошибки / проблемы с действительностью: ограничено доменом авионики. Все языки программирования могли быть статически типизированы. Я не читал тезис, поэтому не могу оценить его строгость.
    Мое мнение. Хотя есть слабые доказательства того, что динамически типизированные языки более продуктивны, это не является окончательным. (1) Есть много факторов, которые не контролировались, (2) слишком мало исследований, (3) было мало или вообще не было дискуссий о том, что представляет собой подходящий метод испытаний.
ahoffer
источник
6

Вот отправная точка:

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

Piet Delport
источник
5
Для не-IEEE людей, каково основное резюме?
Фрэнк Ширар
1
@Frank Shearar, вывод, который они делают, заключается в том, что язык программирования влияет на производительность. Они измеряют количество строк кода на программиста на язык в год, я не уверен, что это хороший показатель производительности.
Уинстон Эверт
3
@Winston: Это определенно некорректная метрика. Вы можете найти COBOL очень продуктивным языком, потому что для того, чтобы сделать что-то полезное, нужно много строк, но их довольно легко написать.
Дэвид Торнли
Уинстон, Дэвид: Я почти уверен, что авторы не предполагают, что производительность строк кода является мерой функциональной производительности. Скорее, статья ставит под сомнение общепринятую мысль, что при прочих равных условиях программисты пишут одинаковое количество строк кода за раз, независимо от языка. Другими словами, этот документ должен служить эмпирическим подтверждением того, что механическая производительность (написанные строки кода) не является хорошей мерой функциональной производительности и должна, по крайней мере, быть нормализована языком.
Пи Дельпорт
Я согласен с этим. Но это не служит для ответа на мой первоначальный вопрос.
Уинстон Эверт
1

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

Вот резюме:

Из контролируемых экспериментов только три показывают эффект, достаточно большой, чтобы иметь какое-либо практическое значение. Исследование Prechelt, в котором сравниваются C, C ++, Java, Perl, Python, Rexx и Tcl; исследование Endrikat, сравнивающее Java и Dart; и эксперимент Кули с VHDL и Verilog. К сожалению, у всех них есть проблемы, из-за которых трудно сделать действительно сильный вывод.

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

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

Эксперимент Кули был одним из немногих, который привлек людей из не студенческого населения, и это здорово. Но, как и во всех других экспериментах, задача была тривиальной игрушечной задачей. Хотя кажется ужасным, что ни один из участников VHDL (статический язык) не смог выполнить задачу вовремя, крайне необычно хотеть завершить проектирование оборудования за 1,5 часа где-нибудь за пределами школьного проекта. Вы можете утверждать, что большая задача может быть разбита на множество мелких задач, но вероятным контраргументом является то, что при использовании VHDL существуют фиксированные затраты, которые можно амортизировать для многих задач.

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

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

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

Я обнаружил, что пример 0install (который сравнивал различные языки с Python и в конечном итоге остановился на Ocaml) был одной из самых интересных вещей, с которыми я столкнулся, но это субъективная вещь, которую все будут интерпретировать по-разному, что можно увидеть, посмотрев ,

Это соответствует моему впечатлению (в моем маленьком уголке мира ACL2, Isabelle / HOL и PVS являются наиболее часто используемыми проверяющими, и есть смысл, что люди предпочитают больше автоматизации при решении проблем в промышленности), но это тоже субъективно.

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

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

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

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

Mr.WorshipMe
источник
0

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

Я думаю, что есть два параметра, которые должны стоять на первом месте:

  • уровень знания языка: чем больше у вас опыта, тем больше вы знаете о «хитах» и тем больше у вас шансов избежать их / легко выследить. Это также верно в отношении конкретного приложения / программы, над которой вы работаете
  • тестирование: я люблю статическую типизацию (черт возьми, мне нравится программирование на C ++: p), но есть так много, что компилятор / статический анализатор может сделать для вас. Просто невозможно быть уверенным в программе, не протестировав ее. И я полностью за нечеткое тестирование (когда применимо), потому что вы просто не можете думать обо всех возможных комбинациях ввода.

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

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

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

Матье М.
источник
2
Если это встречный вопрос, то где этот вопрос? :) Я согласен, что другие факторы более важны, чем статическая или динамическая типизация. Однако сторонники динамической типизации заявляют о большей производительности, а сторонники статической типизации заявляют о более высоком качестве кода. Мне было интересно, есть ли у кого-либо фактические доказательства в поддержку своих требований.
Уинстон Эверт
@Winston: я удалил бит счетчика: p Как вы уже упоминали, это в основном претензии. Я думаю, что большинство сторонников динамической типизации смешивают простоту использования с динамической типизацией, в то время как простота использования - в основном инструменты Я согласен с тем, что возможность писать быстрые одноразовые прототипы и экспериментировать с короткими командами с использованием интерпретатора - это повышение производительности, но даже у Haskell (возможно, языка с самой впечатляющей на данный момент системой типов) есть интерпретатор для быстрого экспериментирования: )
Матье М.
Но до тех пор, пока кто-то действительно не проведет исследование, в котором рассматривается этот вопрос - оказывают ли методология, инструменты большее влияние, чем язык, на уровень брака, производительность - мы просто заканчиваем сравнением анекдотов.
Фрэнк Шиарар
0

Вот несколько из них:

  • Стефан Ханенберг. 2010. Эксперимент о статических и динамических системах типов: сомнения в положительном влиянии систем статических типов на время разработки. В материалах Международной конференции ACM по языкам и приложениям систем объектно-ориентированного программирования (OOPSLA '10). ACM, Нью-Йорк, Нью-Йорк, США, 22-35. DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Дэниел П. Делорей, Чарльз Д. Кнутсон, Скотт Чун, «Влияют ли языки программирования на производительность? Учебный пример с использованием данных из проектов с открытым исходным кодом», floss, стр. 8, Первый международный семинар по новым тенденциям в исследованиях и разработках FLOSS (FLOSS '07: семинары ICSE 2007), 2007

  • Дейли, М .; Сазавал, В., Фостер, Дж .: Работа в процессе: эмпирическое исследование статической типизации в Ruby, семинар по оценке и удобству использования языков программирования и инструментов (PLATEAU) на ON-WARD 2009.

  • Лутц Пречелт и Вальтер Ф. Тичи. 1998. Контролируемый эксперимент по оценке преимуществ процедуры проверки типа аргумента. IEEE Trans. Softw. Eng. 24, 4 (апрель 1998 г.), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

Лорин Хохштайн
источник