E>>>Не совсем понял... Из этого следует, что уже 40 лет есть способ писать безошибочные программы?
R>>Да.
E>
E>А мужики-то и не знают...
счастье — в неведении.
E>Лично со мной на эту тему спорить бесполезно. Разве что опубликовать этот способ.
Все значимые публикации по теории типов, лямбда-исчислению, комбинаторной логике, SKI-исчислению, изоморфизму Карри-Говарда и теории категорий лежат в свободном доступе и находятся через любой поисковик.
E>Чей-то мне она вспомнилась. :xz:
Замечательный и важный для темы случай.
Очень интересная, наверное, конференция была. И очень научная.
На этом позвольте прекратить свое участие в этой теме.
Здравствуйте, reductor, Вы писали:
R>счастье — в неведении.
Причем неведают все. Ладно сообщество Linux-оидов никак баги из ядра вычистить не могут. Но вот MS-то чего глюкавый софт пишет? Уж они-то могли себе позволить лучшие наработки в этой области на службу поставить.
R>Замечательный и важный для темы случай. R>Очень интересная, наверное, конференция была. И очень научная.
Конференция-то нормальная была. Просто на открытии в президиуме сидел какой-то мужик, замминистра какого-то, вот он ее и выдвинул на трибуну, вместо какого-то профессора, который должен был свой доклад прочитать. Любят во власти такого рода шарлатанов.
А в науке, похоже, верят, что программы можно писать без ошибок.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Не совсем понял... Из этого следует, что уже 40 лет есть способ писать безошибочные программы?
Вообще-то reductor в отношении функциональных языков прав. С помощью редуцирования лямбда функций можно построить глобальную мат. модель вычислений и математически проверить ее на соответвие. В отношении императивных языков, в большинстве случаев, такое не пройдет. Слишком сложная структура чтобы ее можно было автоматически описать. До некоторой степени можно проверить простейшие случаи опытным путем с помощью unit-тестов. Но тут есть одна проблемка. Все это работает до тех пор, пока мы можем доказанно описать входные и выходные параметры. Ну например, у нас на входе есть некоторая грамматика, допустим состоящая из 20 лексем. Тогда всего количество цепочек лексем у нас будет 20^20, считай что неисчеслимо. В результате, проверить все мы физически не сможем. Если мы сможем из этих лексем построить вполне понятную мат. модель соответсвия к результатам, то добавив полученную мат. модель вычислений из функционального языка вполне возможно.
Для доведения до некоторого уровня надежности, обычно применяют свои методики(коих дост. много). Ну например, у нас входной параметр находится на некоторой числовой прямой. Мы берем минимальное значение, максимальное значение и некоторое значение из середины. После unit теста с некоторой эвристической вероятностью мы можем утверждать что функция работает.
So why are they so bad? If they are handled and the end users don’t see them are they really harmful?
I can think of 3 reasons off the top of my head.
Exceptions are expensive.
Exceptions can take you into unnecessary code paths.
Exceptions are generally thrown when something went wrong.
Здравствуйте, GlebZ, Вы писали:
E>>Не совсем понял... Из этого следует, что уже 40 лет есть способ писать безошибочные программы? GZ>Вообще-то reductor в отношении функциональных языков прав. С помощью редуцирования лямбда функций можно построить глобальную мат. модель вычислений и математически проверить ее на соответвие. В отношении императивных языков, в большинстве случаев, такое не пройдет. Слишком сложная структура чтобы ее можно было автоматически описать.
Ребята, ни в моем вопросе, ни в утверждениях Губанова или reductor-а не было ограничений на функциональные языки или объемы программ.
Поэтому все это отговорки, мол где-то когда-то и пр...
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
R>>>Но конечно основной смысл в том, что если у нас есть R>>>
R>>>// некий абстрактный код
R>>>int y = 5;
R>>>if (x == 1) return y;
R>>>y++;
R>>>if (x == 2) return y;
R>>>return y + 5
R>>>
R>>>То понять что здесь происходит невозможно ни компилятору (та самая проблема с автоматами) ни человеку.
V>>Я в очередной раз ловлю себя на ступоре после прочтения подобной фразы. Может я чего-то не понимаю? Откуда у компилятора или у человека сложности с прочтением? Насчет обязательности соответствия y<=f(x) мне понятно, насчет каких-то затруднений компиляции — нет. Хочешь, прямо здесь и сейчас граф детерминриованного автомата нарисую по этому куску кода? Не знаю, как другие программисты трассируют исходники в голове, но я, когда трассирую куски алгоритмов именно думаю как автомат — т.е. перехожу из состояние в состояние (состояние — множество значений всех локальных/глобальных переменных и проч. ячеек данных быстрой и медленной памяти, прямо или коссвено принимающих участие в алгоритме) в ответ на некие действия над этими переменными.
R>http://en.wikipedia.org/wiki/Halting_problem
[]
Конкретно с этим постом я согласен.
Но насколько я понял, этот текст должен был "доказать" вред множественного return, и с этим я совершенно не согласен. Произошла подмена понятий — вместо мифических сложностей верификации кода с множественным return, ты говорил о невозможности верификации в общем случае.
Сорри, если я чего не так понял.
Здравствуйте, reductor, Вы писали:
R>Вам, совершенно очевидно, просто необходимо познакомиться с язками, произведенными от ML и ISWIM — Haskell или на худой конец SML
Здравствуйте, IT, Вы писали:
IT>Может посчитать количество строчек. Выигрышь более чем в два раза при гораздо более высокой наглядности (если слово наглядность вообще уместно при таком стиле).
Фигнёй страдаете, однако .
---------
Кстати, символ "~" в Modula/Oberon-ах обозначает инструкцию логического отрицания, т.е. то же что в Си-образных языках обозначается символом "!".
GlebZ wrote:
> E>Не совсем понял... Из этого следует, что уже 40 лет есть способ > писать безошибочные программы? > Вообще-то reductor <http://rsdn.ru/Users/Profile.aspx?uid=48135> в > отношении функциональных языков прав. С помощью редуцирования лямбда > функций можно построить глобальную мат. модель вычислений и > математически проверить ее на соответвие.
На соответствие ЧЕМУ? Как вы будете составлять reference model?
У вас просто сместится сложность с проверки программного кода на
соответствие с требованиями задачи на проверку мат. модели на
соответствие требованиям задачи.
Иногда это имеет смысл, например, была доказана "правильность" софта
управления парижским метрополитеном. Под "правильностью" понимается
невозможность такой ситуации, при которой два поезда столкнутся.
Здравствуйте, Cyberax, Вы писали:
C>У вас просто сместится сложность с проверки программного кода на C>соответствие с требованиями задачи на проверку мат. модели на C>соответствие требованиям задачи.
Кстати, о птичках:
Формальная верификация — конструирование некорректного доказательства, изоморфного по отношению к некорректной программе.
C>На соответствие ЧЕМУ? Как вы будете составлять reference model?
А что такое reference model в терминах функционального языка?
C>У вас просто сместится сложность с проверки программного кода на C>соответствие с требованиями задачи на проверку мат. модели на C>соответствие требованиям задачи.
Нет. Сложность получения модели можно автоматизировать. Если не иметь императива, можно получить и даже одно уравнение. Единственная проблема — это выявление мат. модели между входными и выходными параметрами.
C>Иногда это имеет смысл, например, была доказана "правильность" софта C>управления парижским метрополитеном. Под "правильностью" понимается C>невозможность такой ситуации, при которой два поезда столкнутся.
+1
С уважением, Gleb.
PS никогда не думал что буду защищать функциональные языки
Здравствуйте, eao197, Вы писали:
GZ>>Вообще-то reductor в отношении функциональных языков прав. С помощью редуцирования лямбда функций можно построить глобальную мат. модель вычислений и математически проверить ее на соответвие. В отношении императивных языков, в большинстве случаев, такое не пройдет. Слишком сложная структура чтобы ее можно было автоматически описать.
E>Ребята, ни в моем вопросе, ни в утверждениях Губанова или reductor-а не было ограничений на функциональные языки или объемы программ.
Поэтому я и развернул ответ на всякий случай. То есть говорить что можно или нельзя сразу для всех стилей, невозможно. А reductor привел в пример именно функциональные языки.
Здравствуйте, Cyberax, Вы писали:
C>Нет, это уже религия. Все нормальные программисты уже давно перестали C>флеймить по поводу GOTO и структурного программирования, так как по C>нынешним меркам это уже далеко не самый главный вопрос. Все C>программисты, которых я знаю, думают примерно так: "GOTO это плохо?" — C>"Плохо". "Структурное программирование хорошо?" — "Да". "Единый return, C>выход из вложенных циклов по флагам, отсутствие break — оно надо?" — "А C>нафига?"
МОЩНО, но есть и ещё одно, единственный ретурн заставляет писать очень маленькие по функционалц функции, в противном случае страдает читабельность, каждое ветвление, — это отступ в программе, чем больше отступ — тем больше нужна диагональ монитора. А я уже высказывал свой ИМХО: зависимость от диагонали монитора не есть гуд.
А если ещё и н епользоваться исключениями — то производители мониторов перестанут успевать за потребностями програмистов.
Пример навскидку, не жизненный, просто для демонстации того, о чем грю:
int foo()
{
bool RetVal = S_ERROR; // из-за единственной точки выхода
CXXRecordset* pRs = new( nothrow ) CXXRecordset;
if( pRs )
{
if ( pRS->Open() )
{
if ( !pRS->Eof() )
{
pRs->MoveFirst();
while( !pRs->Eof() )
{
...
if ( pRs->Next() )
{
RetVal = RSNEXT_ERROR;
break;
}
}
RetVal = S_OK; // ГЛАВНОЕ не забыть, а где именно у нас успешно выполнилась функция ;)
}
}
}
return bRetVal
}
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Фигнёй страдаете, однако .
Да я уже понял. Тем, для кого простота и наглядность кода является пустым звуком, доказывать что-либо бесполезно.
СГ>Кстати, символ "~" в Modula/Oberon-ах обозначает инструкцию логического отрицания
Мне как-то всё равно. После того, что я увидел в твоём исполнении, я уже вряд ли когда-нибудь буду интересоваться этими языками.
Если нам не помогут, то мы тоже никого не пощадим.
Я бы поверил, если бы видел в жизни хоть один RollBack, который не кидает исключениями при применении его к отсутствующей транзакции (метке транзакции)
_W>Ну хорошо. _W>То, что это на С, это я выпендрился.
Почему обязательно на С? На С++ тоже достаточно мест, где лучше и правильней использовать коды возврата, а не исключения. Там выше давались факторы, влияющие на конкретное решение. Поэтому я как бы считал что это С++. Разумеется, если написано на С, и если операция rollback ничего фатального не сделает в случае невалидных аргументов (я никакие неупомянутые сразу "если" не забыл?), то ты почти отмазался
_W>Мда. Всё-таки с исключениями проще... _W>Придётся согласиться.
Да, но в С++ свои сложности с исключениями. Навскидку:
— нет единого стандартного базового исключения, соответственно зачастую или непонятно что ловить, или ловить приходится много несвязанных типов
— безопасно можно использовать только семантику по значению, ввиду этого:
— сложно вкладывать исключения друг в друга (как в Java/C#), из-за этого невозможно получить цепочку на некоем верхнем уровне после серии фильтраций на нижних
— если взять иерархию от STL-ексепшена, то возникают вопросы по формированию char* what() динамически. Нам же надо обеспечить конструкторы копирования, т.е. приходится возиться со смарт-поинтерами для строки сообщения — накладные расходы, и в этом случае ситуацию нехватки памяти приходится обрабатывать сквозняком через все уровни отдельно, без фильтрации и динамических выделений.
В общем, я неоднократно строил свои иерархии ексепшенов, и боком и раком, но никогда не получалось сделать так, чтобы остался полностью доволен. Ввиду этого, наборы исключений и их фильтрацию в разных сценариях необходимо проектировать вместе с системой. Но при эттом теряется весьма удобное св-во ексепшенов — расширения множества оных "по мере надобности".
Здравствуйте, Дарней, Вы писали:
ПК>>Несложно и недолго начиная с VC++ 6 SP4 или GCC 2.95. Вы используете что-нибудь более старое?
Д>это давно уже было, да и компилятор — специально заточенная под девайс версия GCC Д>в общем, с шаблонами там проблематично было
Ну... можно еще макросами генерить код, не только шаблонами