Madzi писал(а):
Vlad писал(а):
Блин, да поймите вы, программирование - это не только математика. Если бы все так было просто...
Да, это ещё и физика, только вот другие этого понять не могут и удивляются почему это у них программы не работают когда они киллометры с килограммами мешают (образно конечно).
Если компилятор не проверяет сложение килограммов с километрами (что мы и имеем в случае оберона, кстати), то тестирование - единственный
эффективный способ заставить работать такую "физическую" программу.
Madzi писал(а):
Но математике всё-таки больше, в том числе дискретной и мат.логики, просто "программисты" считают достаточным знание языка программирования, и не хотят загружать себя "лишними" знаниями.
Про нежелание загружать себя лишними "знаниями" - это скорее к некоторым оберонщикам, которые ведутся на пропаганду простоты и отказ от всего "лишнего", и думают, что оберон поможет им не учиться всяким сложным вещам типа юнит-тестирования
Madzi писал(а):
У меня понятия о тестировании самые разнообразные, поскольку я участвовал в разных проектах от академических до индустриальных
Не верю (с)
При все уважении. Можно писать без тестов (и пишут, и даже на C), но это неэффективно. Каменный век. И чем сложнее система - тем большее значение имеют автоматические тесты.
Madzi писал(а):
, но лично я предпочитаю тестировать программу на бумаге, до того как она будет реализована в языке на машине, а затем, следует проверка правильности набивки. При этом программа в 99% работает правильно с первого раза, сразу после набивки. и лишь 1% когда требуется некотороая переработка (было когда оказались ошибки в спецификациях в документации).
И вы говорите, что участвовали в каких-то реальных проектах?
Ошибки/недодумки/недосказки в спецификациях - это и есть те самые 99% багов. Или вы действительно думаете, что в юнит тестах на C++ я тестирую выход за границы массивов, нарушение типизации, обращение по невалидному указателю, циклы с break и прочие ужасы С++, от которых (якобы) избавлен оберон?
Вот смотрите. У вас есть замечательная функция: parent_directory(path), которая как и следует из названия возращает директорию одного уровня выше для пути. Замечательна эта функция тем, что она математически доказана на бумажке, закодирована в лучших традициях Дейкстры и даже снабжена комментарием. Такая идиллия продолжается пару лет, пока ваш коллега (который работает совсем над другим проектом, но с которым у вас общая библиотека) не обнаруживает, что функция неправильно работает для случая вот такого пути: "c:\dir1\dir2\". А именно - она возвращает "c:\dir1\dir2". В комментарии такой случай (слэш на конце) не описан, в математическом доказательстве на бумажке (это конечно из области фантастики, но допустим, что ваш коллега эту бумажку умудрился откопать) - такой случай тоже никак не фигурирует. Исполненный уверенности, что он исправляет "багу", ваш коллега исправляет функцию (и прикладывает новую бумажку с новым доказательством) так, что она начинает возвращать "c:\dir1". Через полгода вам звонит клиент и говорит, что ваша !@#$% программа удалила ему папку "Мои документы" с очень важными документами. Вы начинаете разбираться и находите этот "фикс" вашего коллеги (это при условии, что вы пользуетесь какой-нибудь CVS, хотя тут некоторые утверждали, что при использовании оберона она им нафиг не нужна). Вы приходите к коллеге и начинаете ругаться, на что он вам выкатывает "железный" аргумент в пользу своей невиновности: безупречное математическое доказательство на бумажке