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

Здравствуйте, mkizub, Вы писали:

M>А как это сделать в динамических языках — я себе не могу представить.
M>Есть ли подобные средства для них и как они работают?

pylint?

Здравствуйте, mkizub, Вы писали:

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

Erlang? Python3k? (с последним почти не знаком)

Здравствуйте, mkizub, Вы писали:

M>А как это сделать в динамических языках — я себе не могу представить.

Очень просто. Заменяем проверки компилятора юнит-тестами.

Здравствуйте, AndrewVK, Вы писали:

M>>А как это сделать в динамических языках — я себе не могу представить.

AVK>Очень просто. Заменяем проверки компилятора юнит-тестами.

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

Здравствуйте, mkizub, Вы писали:

M>>>А как это сделать в динамических языках — я себе не могу представить.

AVK>>Очень просто. Заменяем проверки компилятора юнит-тестами.

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

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

Здравствуйте, Гест, Вы писали:

Г>На уровне отдельной функции можно протестировать, что:
Г>а) приняв на вход корректные данные, она отработает
Г>б) приняв на вход некорректные данные, она обязательно вылетит (если это необходимо); с разумным предупреждением (если это необходимо); оставит окружающую среду в констинентом состоянии (если это необходимо)

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

Здравствуйте, mkizub, Вы писали:

M>Нельзя. Потому как эта функция вызывает другие функции, в зависимости от входящих аргументов

Юнит тестирование как раз таки и характеризуется тем, что тестируется не программа целиком, а ее маленькие модули.

M> и глобального состояния программы.

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

M> Все возможные состояния программы проверить тестами невозможно, их слишком много.

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

M>И потом, даже если крыть всё тестами, то это на порядок больше работы (если не на два)

Не на порядок, и не на два, а процентов на 30-50 по оценкам. И не стоит забывать, что статическим языкам тесты тоже небесполезны.

Здравствуйте, mkizub, Вы писали:

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

А что тут неочевидного? Передать не тот тип аргументов и убедится, что это приводит к ошибке.

Здравствуйте, mkizub, Вы писали:

AVK>>Очень просто. Заменяем проверки компилятора юнит-тестами.

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

Python: isinstance, hasattr — как раз для такого рода проверок.

Здравствуйте, Nuald, Вы писали:

AVK>>>Очень просто. Заменяем проверки компилятора юнит-тестами.

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

N>Python: isinstance, hasattr — как раз для такого рода проверок.

Ясно. Полное непонимание сторон
Я спрашиваю — как юнит-тестом можно гарантировать/протестировать, что функция в ран-тайме получит на вход только аргументы определённого типа?
Не то, что она кинет ошибку, а то, что она не получит неправильных данных — как?

Здравствуйте, mkizub, Вы писали:

M>Я спрашиваю — как юнит-тестом можно гарантировать/протестировать, что функция в ран-тайме получит на вход только аргументы определённого типа?
M>Не то, что она кинет ошибку, а то, что она не получит неправильных данных — как?

Покрыть юнит-тестами все точки входа в функцию. При стопроцентном code coverage (хе-хе) все будет ровно. Вопрос тока как его получить?

Если интересует супер-крутое верифицируемое программирование, советую ознакомиться с Praxis’ Correctness by Construction development process. Вот это реально круто, хотел бы я в таком поучаствовать и поплевать во всякие питоны и руби с большой колокольни

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, Nuald, Вы писали:

AVK>>>>Очень просто. Заменяем проверки компилятора юнит-тестами.

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

N>>Python: isinstance, hasattr — как раз для такого рода проверок.

M>Ясно. Полное непонимание сторон
M>Я спрашиваю — как юнит-тестом можно гарантировать/протестировать, что функция в ран-тайме получит на вход только аргументы определённого типа?
M>Не то, что она кинет ошибку, а то, что она не получит неправильных данных — как?

— Здравствуйте, это молоток, им забивают гвозди
— Нет-нет, вы мне объясните, как этим молотком шуруп закрутить?

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

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

Здравствуйте, mkizub, Вы писали:

M>Ясно. Полное непонимание сторон
M>Я спрашиваю — как юнит-тестом можно гарантировать/протестировать, что функция в ран-тайме получит на вход только аргументы определённого типа?
M>Не то, что она кинет ошибку, а то, что она не получит неправильных данных — как?
Никак. Только на всякий случай уточню, что принадлежность к какому-либо типу не столь уж сильный контракт, а вот как можно гарантировать, что функция в ран-тайме получит на вход только int x такой, что x > 6 и list<int> l такой, что l.length() < x?

Здравствуйте, VoidEx, Вы писали:

M>>Не то, что она кинет ошибку, а то, что она не получит неправильных данных — как?
VE>Никак. Только на всякий случай уточню, что принадлежность к какому-либо типу не столь уж сильный контракт, а вот как можно гарантировать, что функция в ран-тайме получит на вход только int x такой, что x > 6 и list<int> l такой, что l.length() < x?

Ну, типы — это наиболее частый контракт. Если есть варианты проверить и другие — тоже хорошо.
Как доказать? Очевидно, аннотациями и соответствующими верификаторами (в том числе и умеющими выводить нужную информацию из control/data flow).
Ясно, что проверить всё на свете не получится, да это и не надо. Просто хотелось-бы потерять ощущение ходьбы по минному полю.
Пока программа (на javascript, кстати) была не очень большой — она обозревалась легко. А теперь хотелось бы, чтоб компьютер мне мог помочь в ходьбе по этому минному полю.
Давали ссылки на erlang — прошерстил и нигде не нашёл ничего соответствующего.
На python3k — тоже только планы по введению опциональной аннотации типами, а в доке на него ничего не нашёл.

У меня же на руках есть SymADE, я думал — если нет ничего вообще из подобных верификаторов, то может имеет смысл загнать в него онтологию javascript-а, и написать свой верификатор. Но только я ума не приложу как это вообще верифицировать, если в любом момент можно загнать в объект новое поле или метод или поменять им тип... Я думал, посмотрю на эти существующие верификаторы и возьму у них идею как они это делают. Для того и спрашиваю.

M>Я спрашиваю — как юнит-тестом можно гарантировать/протестировать, что функция в ран-тайме получит на вход только аргументы определённого типа?

Некриворуким программированием.

Грубо говоря:

точка входа в программу
    |
    |
     - func1(string)
           |
           |
            - func2(int)

в момент входа в func2 мы должны уже знать, что входящий параметр — int. И не париться Это не так сложно, как кажется


ЗЫ. Также не надо ассоциировать статическую типизацию со строгой, а динамическую — со слабой

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

Возможно использование декораторов и (в Python 3.0) аннотаций:
http://code.activestate.com/recipes/572161/

Для Python 2.x аналогичный декоратор выглядит менее красиво, но работает примерно так же:
http://code.activestate.com/recipes/426123/

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

M>Ясно. Полное непонимание сторон
M>Я спрашиваю — как юнит-тестом можно гарантировать/протестировать, что функция в ран-тайме получит на вход только аргументы определённого типа?
M>Не то, что она кинет ошибку, а то, что она не получит неправильных данных — как?

Так и в языке со статической типизацией, гарантировать, вообще говоря — никак. Ибо зачастую в нем присутствуют способы принудительного приведения типов, которые позволяют успешно прострелить себе ногу, несмотря на старания компилятора.
Например:

void foo(Bar*);
Biz* biz = new Biz();
foo((Bar*)biz);

и т.п. Так что, как говорил Остап Бендер, гарантию дать может только страховой полис.
А насчет "как протестировать" уже было сказано.

Здравствуйте, targeted, Вы писали:

T>Например:

T>void foo(Bar*);
T>Biz* biz = new Biz();
T>foo((Bar*)biz);

А на Хаскеле такое же прокатит?

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, targeted, Вы писали:

T>>Например:

T>>void foo(Bar*);
T>>Biz* biz = new Biz();
T>>foo((Bar*)biz);

VE>А на Хаскеле такое же прокатит?

unsafeCoerce?

Курилка,

T>>>void foo(Bar*);
T>>>Biz* biz = new Biz();
T>>>foo((Bar*)biz);

VE>>А на Хаскеле такое же прокатит?

К>unsafeCoerce?

Э, не. "Simple things should be simple, complex things should be possible."

Это средство из разряда "последняя пуля — для себя", её стараются не применить до самого последнего момента (в Окамл тоже есть аналог с говорящим названием Obj.magic), а даункастинг — совершенно штатная штука. Даже сейчас, с дженериками, в Джаве дауна Кастинга не избежать, скажем, тут:

ArrayList<MimeMessage> messages = new ArrayList<MimeMessage>(20);
messages.add(thisMessage);
messages.add(thatMessage);
return messages.toArray(); // сюрприз!!! возвращает Object[]

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Курилка,

T>>>>void foo(Bar*);
T>>>>Biz* biz = new Biz();
T>>>>foo((Bar*)biz);

VE>>>А на Хаскеле такое же прокатит?

К>>unsafeCoerce?

LCR>Э, не. "Simple things should be simple, complex things should be possible."

Ну типа ты смайла не заметил?

Курилка,

К>Ну типа ты смайла не заметил?

Дай мне стену!

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, VoidEx, Вы писали:

VE>>Здравствуйте, targeted, Вы писали:

T>>>Например:

T>>>void foo(Bar*);
T>>>Biz* biz = new Biz();
T>>>foo((Bar*)biz);

VE>>А на Хаскеле такое же прокатит?

К>unsafeCoerce?

Ух ты, и правда. Но пойнт не в этом. В динамически типизированном языке можно написать foo x и получить ошибку времени исполнения, в статически типизированном случайно так не сделать, а когда человек пишет reinterpret_cast/unsafeCoerce#, то он осознанно стреляет себе в ногу, при этом он всё равно обязан гарантировать, что принимающая функция не заметит обмана, т.е. в памяти лежит нечто, что может быть представлено данным типом.

VE> человек [...] всё равно обязан гарантировать

А если человек все равно обязан гарантировать, то зачем платить больше ? (c)

Правильно выше написал Гест — не надо заворачивать шурупы молотком. В динамических
языках другая культура разработки. Я когда на Python переходил, первый год
его использовал как C++ и никакого удовольствия не ощущал. Только потом, когда
прочувствовал, как на этом языке надо писать — работа пошла.

Здравствуйте, targeted, Вы писали:

VE>> человек [...] всё равно обязан гарантировать

T>А если человек все равно обязан гарантировать, то зачем платить больше ? (c)
Не вырывайте фразы из контекста.
Он обязан, если пытается обмануть компилятор. В противном случае за него это делает сам компилятор.

Здравствуйте, VoidEx, Вы писали:

VE>Не вырывайте фразы из контекста.
VE>Он обязан, если пытается обмануть компилятор. В противном случае за него это делает сам компилятор.

Спор опять перешел в чисто теоретический. Но единственно правильный критерий это все-таки практика, а она показывает что на динамических Lisp, Smalltalk, Erlang и теперь даже питон и руби писались и пишутся весьма крупные проекты и динамика этому нисколько ни является помехой. В тоже время на очень жестко и статически типизированных Standard ML, Ocaml и Haskell почему-то таких проектов практически нет

Здравствуйте, mkizub, Вы писали:

Не понимаю, за что исходному письму минус поставили — поставил плюс в ответ.:)) Проблема таки есть, и её имеет смысл обсуждать.

M>При написании большого проекта на динамическом языке встаёт вопрос о надёжности кода.
M>Особенно когда проект начинался как небольшой по размеру, и вполне себе справлялся с работой по автоматизации внутренних нужд, но перерос в большой публичный код, используемый сторонними пользователями. Которые, разумеется, жаждут стабильности и минимума багов.
M>Конечно, все ошибки автоматически найти не получится, и в программах на статически типизированных языках тоже есть ран-тайм проверки и ошибки. Но их там намного меньше, или, по крайней мере, можно изменить программу так, что большинство из них будут отловлены на стадии компиляции.

Фактор этот действительно есть. При переходе на динамический язык возникает большое число ошибок, которые были невозможны в случае статики. Из моих последних "достижений" такого рода: называние вызываемого метода recvUasRequest вместо uasRecvRequest, отловленное только при запуске. (Для критиков — юнит-тестам мешает ряд объективных причин, не надо про них вспоминать.) В случае компиляции, было бы известно, какого типа объект и как у него зовутся методы.

Тем не менее, по сравнению с типичными статическими языками вроде C++, большое количество ошибок, наоборот, исчезает за счёт более ясной логически модели работы с данными. Сравнивать, больше этих исчезнувших ошибок или больше добавленных, я не возьмусь — не было опыта делать одну и ту же задачу средствами разного плана наперегонки.

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

M>А как это сделать в динамических языках — я себе не могу представить.
M>Есть ли подобные средства для них и как они работают?
M>Насколько у вас возрастают затраты времени на сопровождение при росте размера проекта и публичном использовании?

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

VE>Ух ты, и правда. Но пойнт не в этом. В динамически типизированном языке можно написать foo x и получить ошибку времени исполнения,

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

VE>в статически типизированном случайно так не сделать, а когда человек пишет reinterpret_cast/unsafeCoerce#, то он осознанно стреляет себе в ногу, при этом он всё равно обязан гарантировать, что принимающая функция не заметит обмана, т.е. в памяти лежит нечто, что может быть представлено данным типом.

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

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, VoidEx, Вы писали:

M>>>Не то, что она кинет ошибку, а то, что она не получит неправильных данных — как?
VE>>Никак. Только на всякий случай уточню, что принадлежность к какому-либо типу не столь уж сильный контракт, а вот как можно гарантировать, что функция в ран-тайме получит на вход только int x такой, что x > 6 и list<int> l такой, что l.length() < x?

M>Ну, типы — это наиболее частый контракт. Если есть варианты проверить и другие — тоже хорошо.
M>Как доказать? Очевидно, аннотациями и соответствующими верификаторами (в том числе и умеющими выводить нужную информацию из control/data flow).
M>Ясно, что проверить всё на свете не получится, да это и не надо. Просто хотелось-бы потерять ощущение ходьбы по минному полю.

пишите тесты. на мелкие модули и т.п.
и пишите программу "устойчивую к ошибкам" (только логать не забывайте, а то потом: вроде все работает, но что-то не то)

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

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

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

M>Пока программа (на javascript, кстати) была не очень большой — она обозревалась легко. А теперь хотелось бы, чтоб компьютер мне мог помочь в ходьбе по этому минному полю.

M>У меня же на руках есть SymADE, я думал — если нет ничего вообще из подобных верификаторов, то может имеет смысл загнать в него онтологию javascript-а, и написать свой верификатор. Но только я ума не приложу как это вообще верифицировать, если в любом момент можно загнать в объект новое поле или метод или поменять им тип... Я думал, посмотрю на эти существующие верификаторы и возьму у них идею как они это делают. Для того и спрашиваю.

Тесты — лучший верификатор. только он может проверить семаническую корректность.

Здравствуйте, Andrey_Pilya, Вы писали:

A_P>Тесты — лучший верификатор. только он может проверить семаническую корректность.

Так с Coq'ом нас напаривают значит? Вот тебе раз!