Курилка,

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'ом нас напаривают значит? Вот тебе раз!