Oberon space
General Category => Общий раздел => Тема начата: Geniepro от Июль 11, 2012, 07:57:36 pm
-
Модульного тестирования недостаточно. Вам также нужна статическая типизация
http://it-talk.org/post79170.html
Перевод записи в блоге: «Unit testing isn't enough. You need static typing too» (http://evanfarrer.blogspot.ca/2012/06/unit-testing-isnt-enough-you-need.html). (Evan Farrer)
"Заключение
Результаты этого эксперимента показывают, что для обнаружения дефектов модульное тестирование не является адекватной заменой статической типизации. Несмотря на то, что модульные тесты отлавливают множество ошибок, очень сложно сконструировать модульный тест, который отловит те же самые ошибки, которые отлавливает механизм статической проверки типов. Применение статической проверки типов к многим программам, написанным в динамической модели типизации, позволит обнаружить множество ошибок, которые не могут быть найдены модульным тестированием, и это не потребует значительного перепроектирования программ."
-
Заключение
Ну да, статическая типизация отлавливает ошибки, которые пропускает тестирование. Сделали открытие. Ну и что? Все упирается только в "значительное перепроектирование программ", с которым как раз все не так однозначно. И вот тут спорить можно долго и упорно.
-
и это не потребует значительного перепроектирования программ."
Возможно такое утверждение возникло от простого переписывания статической программы в динамическую. Тут проблем, действительно, нет. А вот обратно это совсем не работает. Если, конечно, динамичаская программа не написана как статическая (на любом языке можно писать как на фортране) - с автоматической потерей всех бонусов динамичноской типизации.
-
А статью прочитать слабо?
Автор статьи провёл исследование, в котором взял 4 проекта на Питоне и построчно перевёл их на Хаскель. При этом обнаружил кучу ошибок в Питоновских вариантах, которые были бы отловлены компилятором, если бы эти проекты с самого начала были написаны на Хаскеле.
И переписывание этих проектов не имело серьёзных проблем, связанных с динамической типизацией Питона -- это означает ошибочность утверждения динамистов, что статическая типизация ограничивает их свободу (не любая программа компилируется из-за ограничений статической типизации).
-
А статью прочитать слабо?
Я читал по диагонали. Большего оно не заслуживает - тема пережевана неоднократно.
Автор статьи провёл исследование, в котором взял 4 проекта на Питоне и построчно перевёл их на Хаскель. При этом обнаружил кучу ошибок в Питоновских вариантах, которые были бы отловлены компилятором, если бы эти проекты с самого начала были написаны на Хаскеле.
Ну и что? Они не были с самого начала написаны на хаскеле. И есть большая разница между переписыванием и проектированием с 0. Это как с легендарной символьной алгеброй info21 - она напиасана на ББ и может быть переписана на что угодно (ну почти на что угодно). Но написал он ее на ББ и ты никогода не докажешь, что это можно было сделать на чем-то другом с тем же успехом :)
P.S. PROFIT был бы, только если бы "переписывал" не человек, а машина.
-
А статью прочитать слабо?
В защиту своего диагонального чтения :) Посмотрел первый "переписанный" проект: https://code.google.com/p/python-gpsd/
Там нечего переписывать. В смысле это простой линейный скрипт, без архитектурных изысков. Я не против, я даже за - именно так и надо решать решаемую им задачу, нечего там огород городить. Но вот в качестве объекта "исследования" - извините, вообще не показательно.
P.S. И да, там нет юнит тестов.
P.S.S. Понятно, что переписать реальный проект крайне трудоемко. Но ценность вот такого "исследования" стремится к нулю.
-
Посмотрел первый "переписанный" проект: https://code.google.com/p/python-gpsd/
Там нечего переписывать. В смысле это простой линейный скрипт, без архитектурных изысков. Я не против, я даже за - именно так и надо решать решаемую им задачу, нечего там огород городить. Но вот в качестве объекта "исследования" - извините, вообще не показательно.
Хоть и нечего переписывать, а однако несколько ошибок там нашлось:
Python NMEA Toolkit
Трансляция Python NMEA Toolkit из языка Python в язык Haskell привела к обнаружению девяти ошибок, связанных с типизацией. Три из них могут обнаружить себя при неправильном вводе данных, а шесть других — из-за некорректного использования API. Только одна из этих ошибок типизации была бы гарантированно найдена при полном покрытии исходных кодов модульными тестами. Кроме того, ещё была одна ошибка времени исполнения, которая могла бы быть устранена при применении статической модели типизации. Два модульных теста можно было бы устранить, поскольку их единственной задачей является проверка типов. Ни одной такой динамической конструкции, которую было бы невозможно транслировать на язык Haskell, не было использовано.
-
Хоть и нечего переписывать, а однако несколько ошибок там нашлось:
Это не ошибки :) Серьезно. Ну упадет оно на некорректных данных. Запустится заново. Не ошибка, а так - невнятная диагностика. Это ж даже не С/С++, который забетонирован в сервер 24/7 и крэшится, роняя весь сервер. Практическая ценность нахождения таких ошибок стремится к нулю.
Python NMEA Toolkit
Два модульных теста можно было бы устранить, поскольку их единственной задачей является проверка типов.
Еще раз - там нет модульных тестов. Если есть - покажи где. Там есть один чисто функционалый тест - прогон на тестовых входных данных.
Ни одной такой динамической конструкции, которую было бы невозможно транслировать на язык Haskell, не было использовано.
Об чем я и говорил с самого начала. Программа без архитектурных изысков, которая может быть переписана практически на автомате на чем угодно. Выбор питона здесь, очевидно, обусловлен популярностью самого питона и доступностью хороших библиотек, а не динамической природой языка.
-
Программа без архитектурных изысков, которая может быть переписана практически на автомате на чем угодно. Выбор питона здесь, очевидно, обусловлен популярностью самого питона и доступностью хороших библиотек, а не динамической природой языка.
Это одна из четырёх случайно выбранных программ на Питоне, и у меня есть подозрение, что подавляющее большинство питоновских программ такие же -- без архитектурных изысков, а значит и не нуждающиеся в динамической типизации и при этом кишащие ошибками, которые могли бы быть выловлены компилятором языка типа Хаскелла...
-
Это одна из четырёх случайно выбранных программ на Питоне, и у меня есть подозрение, что подавляющее большинство питоновских программ такие же -- без архитектурных изысков, а значит и не нуждающиеся в динамической типизации и при этом кишащие ошибками, которые могли бы быть выловлены компилятором языка типа Хаскелла...
Программы без архитектурных изысков и ошибки в них неинтересны совершенно, потому что цена ошибки в такой программе минимальна. Никто не будет запускать такую программу в космос. Ну или применительно к земным проблемам - предприятие не будет стоять, если в такой программе ошибка. Высокооплачиваемый специалист не будет тратить часы, чтобы найти проблему. Поэтому еще раз: "исследование" ошибок в таких программах никому не нужно :) Можно положить его в копилку к обероновскому исследованию, согласно которому ошибок при использовании оберона в 16 раз меньшем, чем на сях :)
-
Ещё один важный плюс статической типизации - многие мелкие задачи рефакторинга можно делать почти без концентрации внимания, "на автомате", т.к. при опечатке (не то имя, не тот тип...) компилятор поймает. А голова в это время отдыхает...
-
Ещё один важный плюс статической типизации - многие мелкие задачи рефакторинга можно делать почти без концентрации внимания, "на автомате", т.к. при опечатке (не то имя, не тот тип...) компилятор поймает. А голова в это время отдыхает...
Согласен, отдыхает. Тем не менее, преимущества не избавляют от недостатков.
-
Тем не менее, преимущества не избавляют от недостатков.
А какие недостатки у статической типизации? Какие преимущества даёт динамическая?
-
Кстати, на днях же проходило трёхдневное соревнование ICFPC'12, так вот:
Python and Haskell are the most used languages in the ICFP 2011 contest (http://www.reddit.com/r/icfpcontest/comments/i58vy/python_and_haskell_are_the_most_used_languages_in/)
Here's the list with languages that were used more than once:
Python: 36
Haskell: 34
C++: 29
OCaml: 23
Java: 18
C: 12
Ruby: 11
C#: 8
F#: 8
Perl: 7
Scala: 6
Scheme: 6
Common Lisp: 4
Bash: 4
JavaScript: 3
Ссылки на отчёты: http://ru-icfpc.livejournal.com/4112.html
-
Кстати, на днях же проходило трёхдневное соревнование ICFPC'12, так вот:
Python and Haskell are the most used languages in the ICFP 2011 contest (http://www.reddit.com/r/icfpcontest/comments/i58vy/python_and_haskell_are_the_most_used_languages_in/)
Блин, на годы не посмотрел -- речь о разных соревнованиях ))) Но всё равно ))
-
Тем не менее, преимущества не избавляют от недостатков.
А какие недостатки у статической типизации? Какие преимущества даёт динамическая?
Разжевано уже сто раз... Какие конкретно недостатки ты не считаешь недостатками и какие конкретно преимущества ты не считаешь преимуществами?
-
Разжевано уже сто раз... Какие конкретно недостатки ты не считаешь недостатками и какие конкретно преимущества ты не считаешь преимуществами?
Самое главное достоинство статической типизации -- больше проверок делает компилято, а не я. Чем сильнее типизация -- тем меньше мне работы по отлову ошибок. Юнит-тесты мало кто делает -- их ещё уметь делать надо, я не умею, например.
Пока я делал небольшую программу на Эрланге эта чортова динамическая типизация мне все нервы вымотала, а ведь в Эрланге она реализована весьма неплохо по утверждениям эрлангеров...
Так что даже если эта динамическая типизация и даёт какие-то бонусы, статическая типизация их с лихвой перекрывает...
-
Разжевано уже сто раз... Какие конкретно недостатки ты не считаешь недостатками и какие конкретно преимущества ты не считаешь преимуществами?
Самое главное достоинство статической типизации -- больше проверок делает компилято, а не я. Чем сильнее типизация -- тем меньше мне работы по отлову ошибок.
Это все известно. Я спрашивал про недостатки статической типизации про достоинства динамической, с которыми ты не согласен. Иначе мы имеем то, что имеем - определенный паритет в общем случае и преимущество того или иного в зависимости от конкретных обстоятельств.
Юнит-тесты мало кто делает -- их ещё уметь делать надо, я не умею, например.
Юнит тесты надо учится делать. Я про это уже писал (может даже на оборонкоре, давно дело было). Статическая типизация позволяет жить без юнит тестов там, где динамическая уже не живет. Но это не не жизнь ;) Все равно все отваливается и смелый рефакторинг невозможен.
Пока я делал небольшую программу на Эрланге эта чортова динамическая типизация мне все нервы вымотала, а ведь в Эрланге она реализована весьма неплохо по утверждениям эрлангеров...
Так что даже если эта динамическая типизация и даёт какие-то бонусы, статическая типизация их с лихвой перекрывает...
У тебя типичный парадокс Блаба ;) Либо у тебя была задача специфическая (куча разнотипных сущностей в одном месте и нельзя спутать). Но таких задач маленького размера практически не бывает.
-
Либо у тебя была задача специфическая (куча разнотипных сущностей в одном месте и нельзя спутать). Но таких задач маленького размера практически не бывает.
В основном постоянное изменение одних и тех же типов данных, их добавление/удаление.
У меня такое постоянно.
-
Либо у тебя была задача специфическая (куча разнотипных сущностей в одном месте и нельзя спутать). Но таких задач маленького размера практически не бывает.
В основном постоянное изменение одних и тех же типов данных, их добавление/удаление.
У меня такое постоянно.
Возможно, что в случае динамического языка эта же задача может быть выражена не изменением типа, а как-то по-другому.
-
А посоветуйте что нибудь почитать про модульное тестирование. На 1С оно применимо?
-
А посоветуйте что нибудь почитать про модульное тестирование. На 1С оно применимо?
Конкретную литературу не посоветую, сам разбирался не планомерно, а по ходу дела. Но начать стоит с TDD (с идеологии).
P.S. Прикольное обсуждение: http://forum.vingrad.ru/forum/topic-327169.html
-
"Исследование отношения популярных языков программирования к случайным ошибкам" (http://habrahabr.ru/post/161967/)
Группа греческих учёных под руководством Диомидиса Спинеллиса провела интересное исследование чувствительности десяти популярных языков программирования к ошибкам и опечаткам при наборе текста программы.
...
Скрипт на Perl вносил в исходный код тестовых задач ошибки, имитирующие естественные ошибки при наборе программ — случайную замену одних символов, ключевых слов и идентификаторов на другие, увеличение или уменьшение числовых литералов на единицу. Всего было протестировано 136 реализаций тестовых задач, на основе которых было сгенерировано 280 000 программ, содержащих ошибки. 32% из них прошли компиляцию или проверку синтаксиса без ошибок и предупреждений. 23% успешно завершились, при этом 6,5% выдали корректный результат, а 16% — некорректный.
Таким образом, можно сказать, что каждая шестая бессмысленная ошибка или опечатка в коде программы может быть обнаружена только при должном покрытии тестами и инспекции кода — компилятор и среда исполнения не смогут её отловить. Естественно, разные языки проявили себя по-разному.
Языки со статической и/или строгой типизацией, что вполне ожидаемо, проявили себя наилучшим образом — C#, Java, С и C++ показали очень похожие результаты — около 10% не замеченных компилятором, лучший результат (8%) у C++. Немного хуже проявил себя Haskell — около 15%. У динамических языков разброс гораздо больше. Абсолютным антилидером стал PHP — в 36% случаев интерпретатор без возражений запустил некорректную программу. За ним с заметным отрывом идёт Perl с 22%, а строже всех ведут себя Ruby (16%) и Python (15%).
С++ удивил, конечно, Хаскелл тоже, хотя и в обратном смысле.
Питон оказался таким же устойчивым к опечаткам, как и Хаскелл, тоже удивительно...
-
P.S. Прикольное обсуждение: http://forum.vingrad.ru/forum/topic-327169.html
;D ;D ;D