Ответ на »сообщение 1143« (AVC)
___________________________
>>>теперь неплохо бы выработать методику количественной оценки
Соотношение ошибок разного типа у разных программистов может принципиально отличаться. Я знаю отличного программиста, который практически всегда неправильно ставит границы цикла For. Он сам это знает и написав For спрашивает у ближайшего коллеги, нужно ли в этом случае вычитать из count единицу.
Если бы в языке был итератор "для всех элементов массива", количество ошибок у конкретного программиста резко сократилось бы. А как часто такая ошибка возникает у "среднестатистического программиста"?

Ответ на »сообщение 1140« (Андрей Хохлов)
___________________________
>>>Перепутать 0.01 и 0.00625 даже на самой плохой распечатке невозможно
А не увидеть опечатку в программе (N=160 вместо N=100) запросто :)
Сколько таких ошибок приходилось находить.
Был даже такой способ отладки: сдвинуть весь текст программы на одну позицию и распечатать заново.
Типов в ПЛ1 действительно море, но ни одного разумного объяснения, как неявное преобразование позволит воспринять "100" как 160 я придумать не могу. Все таки ни один тип не позволял часть разрядов считать в десятичной системе, а часть в шестнадцатиричной.

Ответ на »сообщение 1138« (Непомнящий Евгений)
___________________________

Но насчет "Ваших" ошибок - позвольте не согласиться. Далеко не все логические ошибки выявляются после пары тестов. Они тоже часто бывают непредсказуемыми и могут возникать только в редких ситуациях...

Я имел в виду неконтролируемые компилятором "опечатки" вроде:
1) a вместо (-a);
2) b/a вместо a/b;
3) foo(b,a) вместо foo(a,b);
4) bar(a) вместо foo(a);
5) и т.д.
т.е. перечисленные гостем ошибки в знаке, порядке аргументов, перепутанных переменных и функциях.
Согласен, что с логическими ошибками (разбиением вычислений на разные ветки?) дело обстоит хуже: веток много, на каждую потребуется тест.
Надо еще раз это обдумать.

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

Мы с Вами практически коллеги! :)

P.S. Мне нравится, что народ откликнулся.
Чем повторять слово "надежность" ("халва" :) ), лучше самим провести небольшое исследование.
Начали создавать типологию ошибок, теперь неплохо бы выработать методику количественной оценки (как -- примерно -- мерять проценты).

Ответ на »сообщение 1141« (Img)
___________________________
Добавлю группу ошибок в ООП-иерархиях, которые могут быть в языках типа С++ или Дельфи. Модифицируем базовый класс, вводим новый метод, его имя случайно совпадает с уже существующим в потомках - компилятор молчит. Забываем слово virtual - компилятор молчит, и т.п. А Компонентный Паскаль не молчит, а бьет больно по рукам :-)

Попытался выделить наиболее характерные типы ошибок формального типа, которые может отслеживать компилятор или среда исполнения (смысловые ошибки, типа "зацикливания", не позволяет контролировать теорема Геделя).
Пока вот что получилось.
1) Ошибка синтаксиса;
2) Необъявленный ресурс программы (ошибка типа "неизвестное имя");
3) Несогласованные типы (ситуация вида: INTEGER:=REAL или Sqrt(String));
4) Выход индекса массива за границы диапазона (no comment);
5) Висячая ссылка или некорректное значение указателя - обращение к объекту по указателю, который уже равен NIL или указывает на другой объект в памяти;
6) Мусор (неосвобожденная память, на которую нет ни одной ссылки);
7) ?
...

Ответ на »сообщение 1139« (Андрей Хохлов)
___________________________

Я невнимательно прочел ответ. Перепутать 0.01 и 0.00625 даже на самой плохой распечатке невозможно

Ответ на »сообщение 1136« (Сергей Перовский)
___________________________

Скорее все-таки к языку. Fortran-программа на той же аппаратуре вела себя совершенно нормально, REAL(1.0)/INTEGER(100) было столько, сколько должно было быть. Обнаружив странность я обратился к сотруднику ВЦ, но он сказал, что так и должно быть и попытался это объяснить (что-то связанное с неявными преобразованими типов, которых в PL/1 много). Смысла объяснения я не понял  и PL/1 больше не использовал (вернулся к Fortran)

TO AVC
Есть существенная разница между названными Вами типами ошибок и неконтролируемыми компиляторами "ненадежных" языков ошибками доступа к памяти.
Повторю, что для выявления "Ваших" :) ошибок достаточно пары тестов, причем возможно каждую функцию тестировать отдельно (что просто).
Ошибки доступа к памяти возникают при особых обстоятельствах, которые еще надо суметь воспроизвести.
Т.е. эти две категории ошибок очень различны по "весу" и "значимости".

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

Ответ на »сообщение 1113« (гость)
___________________________


И кстати: вообще-то разговор шёл о сравнении Oberon с Java и C#, где 90% аргументов за Оберон просто теряют всякий смысл.

Уже упоминалось, что существуют ошибки, возможные на C#, но невозможные на Обероне.
Так что смысл все-таки есть. :)
Кроме того, компиляторы Оберона способны порождать эффективный нативный код (в принципе, на уровне Си), в отличие от Java и C#.
Поэтому я и говорил о том, что Оберон особенно хорош там, где требуется "сочетание надежности и эффективности".

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

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

В идеальном мире - да. В реальном - трудно предусмотреть в тестах все возможности, особенно когда проект некритичен, а сроки поджимают.
Как вы полагаете, АСУ Миража не тестировали? :) Уж казалось бы...

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

ИМХО, дальнейшее продолжение разговора о влиянии языка на надежность имеет смысл, если мы:
1) выделим основные причины ненадежности и основные типы ошибок,
2) определим (хотя бы оценочно) вероятность их появления и трудность обнаружения,
3) выделим из них те типы ошибок, которые контролируются надежными языками и не контролируются ненадежными, и определим их долю в общей массе ошибок.

Мне очень понравилась мысль Ильи Ермакова о "совокупном эффекте" языка.
Полезно также знать о данных, приведенных Брегой (на которого ссылается info21).
Единственное, в последнем случае мне лично не вполне ясна методика оценки.