Ответ на »сообщение 1150« (AVC)
___________________________
что в принципе можно сделать в таких обстоятельствах?
В подавляющем % случаев, при подобных обстоятельствах - Н_И_Ч_Е_Г_О !!!

Ответ на »сообщение 1148« (Илья Ермаков)
___________________________
... не сработала бы неправильная логика управления ракетой, выполнение перешло бы на заготовленный обработчик исключений, а там должен же быть какой-либо сценарий аварийный... Хотя, что там особенно предпримешь...
Золотые слова... Правильные... А главное - на злобу дня!
Привет из "дыры"! :о)

Ответ на »сообщение 1151« (AVC)
___________________________
>>>Все же, мне кажется, что она не настолько уж индивидуальна.
>>>Существуют же типовые ошибки, "ошибки начинающего" и т.д.
Я думаю, что для каждого вида ошибок придется вводить некоторую статистическую зависимость ее частоты от опыта программистов: среди начинающих ошибка границы массива встречается у 99%, среди опытных у 1% (но встречается!).
А вот ошибки работы со ссылками довольно часты у значительной части опытных программистов. Как пишет Спольски:"у некоторых людей просто отсутствует часть мозга, позволяющая работать со списками".
Тут и лежит главный резерв надежности: язык должен в первую очередь контролировать ошибки, часто встречающиеся у опытных программистов.

Ответ на »сообщение 1152« (Денис Зайцев)
___________________________

Ответ на »сообщение 1150« (AVC)
___________________________

ИМХО, Geniepro и Илья Ермаков задали очень хороший вопрос: что в принципе можно сделать в таких обстоятельствах?
Дык, там же результаты расследования тоже были опубликованы, в которых было написано, что не нужно было нарушать принципы design by contract. Унаследованный код не был быть нужным образом документирован, значит, его нельзя было использовать.

Полностью с Вами согласен.
Это основной (и фундаментальный) вывод.

Но остается еще один вопрос.
Ведь все предусмотреть трудно (бесспорно, надо к этому стремиться).
Нельзя ли "подстелить соломку" на случай, если все-таки произошло непредвиденное?

Ответ на »сообщение 1150« (AVC)
___________________________

ИМХО, Geniepro и Илья Ермаков задали очень хороший вопрос: что в принципе можно сделать в таких обстоятельствах?
Дык, там же результаты расследования тоже были опубликованы, в которых было написано, что не нужно было нарушать принципы design by contract. Унаследованный код не был быть нужным образом документирован, значит, его нельзя было использовать.

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

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


ИМХО, на такой случай в разных языках существуют "легкоусвояемые" идиомы. :)
Всякий знает, что на Си/Си++ надо писать так:
for (i = 0; i < n; i++) { ... }
На Обероне:
FOR i := 0 TO LEN(array)-1 DO ... END;
И т.д.

Если я правильно понял, главная мысль здесь все же не в повсеместном введении оператора foreach, а в том, что статистика ошибок зависит от программиста.
Все же, мне кажется, что она не настолько уж индивидуальна.
Существуют же типовые ошибки, "ошибки начинающего" и т.д.

Ответ на »сообщение 1147« (Geniepro)
___________________________

Ответ на »сообщение 1141« (Img)
___________________________

4) Выход индекса массива за границы диапазона (no comment);

Этот пункт следует расширить:

Выход значения за границы диапазона (переполнения всякие там...)

Ариан 5 взорвался из-за такого арифметического переполнения; какой-то умник ради повышения эффективности отключил контроль переполнений в компиляторе Ада - вот вам и надёжность языка. :о))

Хотя интересно, если бы не отключили бы программный контроль переполнения - что дальше-то? Логическая ошибка всё равно осталась бы. На лету перешивать ПО взлетающей ракеты? :o))

Случай с Арианом очень интересен.
Я его даже специально отметил в »сообщение 1107«, т.к. не совсем очевидно, что именно он доказывает (в отличие от примеров с переполнением буфера).
Есть над чем подумать.
По существу, там произошла ошибка "повторного использования" (кажется, впервые узнал это от Трурля).
Код, корректно работавший для траектории Ариана-4, оказался непригодным для траектории Ариана-5 (по причине возросшей горизонтальной скорости полета).
Неясно, тестировался ли этот модуль повторно в составе нового комплекса.

ИМХО, Geniepro и Илья Ермаков задали очень хороший вопрос: что в принципе можно сделать в таких обстоятельствах?

На RSDN бросили ссылку
http://www.rsdn.ru/Forum/Message.aspx?mid=2240781#2240781
на недавнее интервью Страуструпа
http://www.technologyreview.com/read_article.aspx?id=17831&ch=infotech

Что вы думаете об этом интервью?

Ответ на »сообщение 1147« (Geniepro)
___________________________
При включенном программном контроле не сработала бы неправильная логика управления ракетой, выполнение перешло бы на заготовленный обработчик исключений, а там должен же быть какой-либо сценарий аварийный... Хотя, что там особенно предпримешь...

Ответ на »сообщение 1141« (Img)
___________________________

4) Выход индекса массива за границы диапазона (no comment);

Этот пункт следует расширить:

Выход значения за границы диапазона (переполнения всякие там...)

Ариан 5 взорвался из-за такого арифметического переполнения; какой-то умник ради повышения эффективности отключил контроль переполнений в компиляторе Ада - вот вам и надёжность языка. :о))

Хотя интересно, если бы не отключили бы программный контроль переполнения - что дальше-то? Логическая ошибка всё равно осталась бы. На лету перешивать ПО взлетающей ракеты? :o))