Модульного тестирования недостаточно...

[Geniepro]

Модульного тестирования недостаточно. Вам также нужна статическая типизация
http://it-talk.org/post79170.html
Перевод записи в блоге: «Unit testing isn't enough. You need static typing too». (Evan Farrer)

"Заключение

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

[vlad]

Заключение

Ну да, статическая типизация отлавливает ошибки, которые пропускает тестирование. Сделали открытие. Ну и что? Все упирается только в "значительное перепроектирование программ", с которым как раз все не так однозначно. И вот тут спорить можно долго и упорно.

[vlad]

и это не потребует значительного перепроектирования программ."

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

[Geniepro]

А статью прочитать слабо?
Автор статьи провёл исследование, в котором взял 4 проекта на Питоне и построчно перевёл их на Хаскель. При этом обнаружил кучу ошибок в Питоновских вариантах, которые были бы отловлены компилятором, если бы эти проекты с самого начала были написаны на Хаскеле.
И переписывание этих проектов не имело серьёзных проблем, связанных с динамической типизацией Питона -- это означает ошибочность утверждения динамистов, что статическая типизация ограничивает их свободу (не любая программа компилируется из-за ограничений статической типизации).

[vlad]

А статью прочитать слабо?

Я читал по диагонали. Большего оно не заслуживает - тема пережевана неоднократно.

Автор статьи провёл исследование, в котором взял 4 проекта на Питоне и построчно перевёл их на Хаскель. При этом обнаружил кучу ошибок в Питоновских вариантах, которые были бы отловлены компилятором, если бы эти проекты с самого начала были написаны на Хаскеле.

Ну и что? Они не были с самого начала написаны на хаскеле. И есть большая разница между переписыванием и проектированием с 0. Это как с легендарной символьной алгеброй info21 - она напиасана на ББ и может быть переписана на что угодно (ну почти на что угодно). Но написал он ее на ББ и ты никогода не докажешь, что это можно было сделать на чем-то другом с тем же успехом

P.S. PROFIT был бы, только если бы "переписывал" не человек, а машина.

[vlad]

А статью прочитать слабо?

В защиту своего диагонального чтения Посмотрел первый "переписанный" проект: https://code.google.com/p/python-gpsd/
Там нечего переписывать. В смысле это простой линейный скрипт, без архитектурных изысков. Я не против, я даже за - именно так и надо решать решаемую им задачу, нечего там огород городить. Но вот в качестве объекта "исследования" - извините, вообще не показательно.

P.S. И да, там нет юнит тестов.
P.S.S. Понятно, что переписать реальный проект крайне трудоемко. Но ценность вот такого "исследования" стремится к нулю.

[Geniepro]

Посмотрел первый "переписанный" проект: https://code.google.com/p/python-gpsd/
Там нечего переписывать. В смысле это простой линейный скрипт, без архитектурных изысков. Я не против, я даже за - именно так и надо решать решаемую им задачу, нечего там огород городить. Но вот в качестве объекта "исследования" - извините, вообще не показательно.

Хоть и нечего переписывать, а однако несколько ошибок там нашлось:

Python NMEA Toolkit

Трансляция Python NMEA Toolkit из языка Python в язык Haskell привела к обнаружению девяти ошибок, связанных с типизацией. Три из них могут обнаружить себя при неправильном вводе данных, а шесть других — из-за некорректного использования API. Только одна из этих ошибок типизации была бы гарантированно найдена при полном покрытии исходных кодов модульными тестами. Кроме того, ещё была одна ошибка времени исполнения, которая могла бы быть устранена при применении статической модели типизации. Два модульных теста можно было бы устранить, поскольку их единственной задачей является проверка типов. Ни одной такой динамической конструкции, которую было бы невозможно транслировать на язык Haskell, не было использовано.

[vlad]

Хоть и нечего переписывать, а однако несколько ошибок там нашлось:

Это не ошибки Серьезно. Ну упадет оно на некорректных данных. Запустится заново. Не ошибка, а так - невнятная диагностика. Это ж даже не С/С++, который забетонирован в сервер 24/7 и крэшится, роняя весь сервер. Практическая ценность нахождения таких ошибок стремится к нулю.

Python NMEA Toolkit
Два модульных теста можно было бы устранить, поскольку их единственной задачей является проверка типов.

Еще раз - там нет модульных тестов. Если есть - покажи где. Там есть один чисто функционалый тест - прогон на тестовых входных данных.

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

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

[Geniepro]

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

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

[vlad]

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

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

[Илья Ермаков]

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

[vlad]

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

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

[Geniepro]

Тем не менее, преимущества не избавляют от недостатков.

А какие недостатки у статической типизации? Какие преимущества даёт динамическая?

[Geniepro]

Кстати, на днях же проходило трёхдневное соревнование ICFPC'12, так вот:

Python and Haskell are the most used languages in the ICFP 2011 contest

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

[Geniepro]

Кстати, на днях же проходило трёхдневное соревнование ICFPC'12, так вот:

Python and Haskell are the most used languages in the ICFP 2011 contest

Блин, на годы не посмотрел -- речь о разных соревнованиях ))) Но всё равно ))