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

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

Не понял про 90% -- Вы буквы считаете?
В оставшиеся 10% входят 1) большая разница в производительности 2) большая разница в сложности.

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

№ 1106   info21
В исследовании, которое я только что процитировал, тщательно (насколько это возможно) выделялись ошибки, относимые именно к языку программирования.
А я как раз говорю о соотношении ошибок, относимых именно к языку программирования и к нему не относимых. Поэтому приведённое исследование - лишь половина вопроса.

Если писать на Обероне, то серьезных ошибок на оператор оказалось в 16 раз меньше, чем на С. Ну что тут мусолить.

Вдогонку:

№ 1099  Илья Ермаков
Подавляющее большинство "крупных компаний с мировым именем" не разрабатывает критичные системы.

http://www.pcweek.ru/?ID=510869

В бортовых системах самолетов Boeing заработает ПО, созданное с помощью среды программирования AdaMULTI для промышленных процессоров Freescale ColdFire 5307. В среду входят компиляторы языков Ada 95/Си/C++/Embedded C++ и система поддержки времени выполнения GMART. Пакет выпускается компанией Green Hills (www.ghs.com).
Как видите, Боинг не столь категоричен.

№ 1099  Илья Ермаков
Подавляющее большинство "крупных компаний с мировым именем" не разрабатывает критичные системы.
Полагаю, АСУ всех метро, кроме парижского, написаны не на Обероне, не так ли?

По поводу Ады - ничуть не устарела. Язык динамично развивается, только что вышел свежий стандарт, полностью стандартизирована библиотека, аналогичная STL, и другие нововведения..
Если Вы не в курсе, STL и появилась когда-то именно на Аде. Потом уже была переписана на C++. Так что "динамичным развитием" это сейчас назвать немного сложно.

№ 1106  info21
В исследовании, которое я только что процитировал, тщательно (насколько это возможно) выделялись ошибки, относимые именно к языку программирования.
А я как раз говорю о соотношении ошибок, относимых именно к языку программирования и к нему не относимых. Поэтому приведённое исследование - лишь половина вопроса.
Разве я где-нибудь утверждаю, что зависяящих от языка ошибок в C++ и Обероне одинаково? Я говорю о том, что проблема языка - лишь часть проблемы. Причём на мой взгляд, малая.

№# 1107-1112  AVC
Нужны результаты расследований, проведенных государственными комиссиями по следам крупных катастроф.
Ну зачем катастроф? Да любая программа: сколько при её отладки вносится исправлений, связанных с алгоритмом, а сколько - с памятью, типами и т.п.

Надо же, такое совпадение, на прошедшей неделе видел, как у товарища Visual C++ 6.0 "навернулся". :)
У нас пока ни одного сбоя не было. Так что извините, повторюсь, может товарищу диск другой купить?
(Сам я предпочитаю gcc.)
Я тоже - MinGW.

Даже при самом поверхностном взгляде как минимум 3 из 10 (30%) ошибки связаны с ненадежностью языка.
:) Как видите, моя прикидочная оценка оказалась недалека от истины - я говорил про 10%.
Благодарю за ссылки - первая конкретная информация по вопросу. По этим данным готов признать 30%. Т.о. получается, что даже супернадёжный язык оставит 70% ошибок.

С Еленой Сагалаевой я в целом вполне согласен. У вас есть процессор. Вы можете его разогнать (и он будет работать ненадёжнее), а можете (как я) не разгонять.
Аналогично, можно пользоваться или не пользоваться "опасными" средствами языка.
Но повторю: я и не утверждаю, что C++ надёжнее как язык.
И кстати: вообще-то разговор шёл о сравнении Oberon с Java и C#, где 90% аргументов за Оберон просто теряют всякий смысл.

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

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

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


Этот дурак может перепутать знак в числе и самолёт "взлетит" с ветикальной скоростью -20 м/с. Ни один язык этого не проверит.

Кто-то реально оценивал соотношение ошибок:
- потерянные указатели, неверное приведение типов и т.п. (т.е. зависящих от языка)
- не та переменная, не тот знак, ошибка в формуле и т.п. (зависящих только от программиста)
?


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

Однако, повторю, что опасность таких ошибок также нельзя преуменьшать.
В уже названной статье о "самых ужасных ошибках" первая ошибка
July 28, 1962 -- Mariner I space probe
была вызвана именно ошибкой в формуле.
Здесь, конечно, возникают вопросы о том, как тестировалось ПО Маринера.

Вообще, в отношении обязательной надежности языков мнение людей разнится. :)
Как-то набрел на страничку в блоге программистки Елены Сагалаевой
http://alenacpp.blogspot.com/2005/09/blog-post_21.html
где она делится услышанным и увиденным на публичной лекции Вирта в Политехническом Музее.
В конце она (как поклонница Си++) все же не удерживается от критического пассажа:

Как вы, наверное, заметили, Вирт несколько недолюбливает C и C++, противопоставляет им Оберон. Он создавал очень небольшой, строгий, не громоздкий язык, спецификация Оберона занимает всегдо 16 страниц, что гораздо меньше, чем спецификация C++, и Вирт этим гордится. Вообще поклонники Оберона очень часто противопоставляют Оберон и C++ [Oberon против С++, pdf]. И ставят такие акценты: возможно приведение типов - значит считай, что нет типизации. Можно объявить friend функции - значит считай, что нет инкапсуляции. И т.п. Имхо, неправильно это. Да я теоретически могу использовать приведение типов, но это не значит, что я это делаю постоянно. C++ предоставляет программисту свободу, за что я и люблю этот язык, но этой свободой надо пользоваться аккуратно.

Вот такое несгибаемое свободолюбие. :)
Статью Темпла "Oberon против C++" я читал и попытался объяснить, что ее поняли неправильно. (Характерен комментарий, который сделал REM.)
Но все это уже "прошлогодний снег". :)

Еще немного о влиянии языка на надежность ПО.
Читаю статью History's Worst Software Bugs:
http://wired.com/news/technology/bugs/0,2924,69355,00.html?tw=wn_tophead_1
http://wired.com/news/technology/bugs/0,69355-1.html?tw=wn_story_page_next1
Даже при самом поверхностном взгляде как минимум 3 из 10 (30%) ошибки связаны с ненадежностью языка.

2 случая - переполнение буфера.

1988 -- Buffer overflow in Berkeley Unix finger daemon.
Здесь характер ошибки назван прямо.
С двумя другими пришлось немного покопаться.
Поэтому привожу также ссылки на вспомогательные источники.

1995/1996 -- The Ping of Death.
Тоже переполнение буфера.
Цитата из
http://www.cert.org/advisories/CA-1996-26.html
It is known that some systems will react in an unpredictable fashion when receiving oversized IP packets. Reports indicate a range of reactions including crashing, freezing, and rebooting.

Третий случай - пропущенный break в сишном операторе switch.
January 15, 1990 -- AT&T Network Outage.
Цитата из
http://www.cs.berkeley.edu/~nikitab/courses/cs294-8/hw1.html
However, the bug (a misplaced "break" statement in C code)

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

Ответ на »сообщение 1104« (Илья Ермаков)
___________________________
>>>Отклоняясь от темы программирования - кто додумался пилотировать машину на такой высоте на автопилоте :-))
Прошу прощения за неточность, это не тот автопилот, который мы видим в кино про гражданскую авиацию.
Это система стабилизации высоты, призванная парировать самопроизвольное изменение высоты (воздушные ямы и т.д.). Без такой системы летать на этих высотах и скоростях проблематично.

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

По поводу Студии
Мну конечно может ошибаться, но почти ни у кого (и у меня) среда не слетает.
Может, просто диск тогда другой взять - а дело не в среде вовсе?

Надо же, такое совпадение, на прошедшей неделе видел, как у товарища Visual C++ 6.0 "навернулся". :)
(Сам я предпочитаю gcc.)

Насколько я понимаю, здесь просто нужна статистика, нужны цифры.
Нужны результаты расследований, проведенных государственными комиссиями по следам крупных катастроф.

Пока (нейтрально, просто как факт, как пример реальной "крупномасштабной" ошибки, причины которой впоследствии полностью были выявлены комиссией) информация об одной из самых известных катастроф 1990-х, вызванных неадекватностью программного обеспечения:
http://en.wikipedia.org/wiki/Ariane_5_Flight_501

Б.Мейер использовал этот случай для подтверждения своего принципа "проектирования по контракту" (кстати, одной из основ программирования в BlackBox):
http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html