Re: Что толку в Ада если Ариан 5 все равно упал
От: AndreyFedotov Россия  
Дата: 24.06.05 13:03
Оценка:
Насколько я понимаю ситуацию, ошибка была не в языке программирования, а в процессе разработки.
Технически ошибка заключалась в том, что код использовался с иным диапазоном данных, чем тот, на который он был расчитан.
И решать её научились очень давно — когда начинают с описания как раз таки допустимых значений входных данных и строго контролируют совпадение или не совпадение диапазонов данных одного модуля с другим. Притом это делается автоматически — просто производится проверка спецификаций.
Метод, кстати очень старый, и как его теория, так и практика хорошо отработаны. По крайней мере в резульате его применения в нашей космонавтике подобных проблем было на порядок меньше, чем в западной.
По всей видимости здесь этого сделано не было, что показывает или раздолбайство, или не высокий профессионализм команды, которая писала код для ариана 5.
Re[30]: Что толку в Ада если Ариан 5 все равно упал
От: CrystaX Россия https://crystax.me/
Дата: 24.06.05 13:14
Оценка: 14 (2)
Здравствуйте, AVC, Вы писали:

AVC>В случае с потерей орбиты Марса, если бы вычисления, связанные с разными единицами измерения, относились к разным типам, то ошибку, скорее всего, удалось бы предотвратить, т.к. потребовалось бы явное приведение типов.


Кстати, я тут недавно приводил
Автор: CrystaX
Дата: 23.05.05
примерную реализацию на C++ систем единиц. Сам ею пользуюсь теперь. Что интересно, результат получился довольно приличный.
1. Переменные, обозначающие разные физические понятия (такие как масса и длина, например), не приводятся друг к другу автоматически.
2. В случае присвоения одной переменной значения другой (обозначающей то же понятие, но в другой системе единиц), происходит аквтоматический пересчет из одной системы в другую.

Что примечательно, работает это вообще без оверхеда в run-time. Посему вопрос — можно ли в Обероне, или в Ада, или в Модула-2 сделать подобное же? Если можно, то можно ли сделать это с нулевым run-time оверхедом? Если да, то останется ли использование этих переменных синтаксически таким же?
Вопросы не флейма ради, а действительно интересно.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[31]: Что толку в Ада если Ариан 5 все равно упал
От: Трурль  
Дата: 24.06.05 13:21
Оценка: 8 (1)
Здравствуйте, CrystaX, Вы писали:


CX>Кстати, я тут недавно приводил
Автор: CrystaX
Дата: 23.05.05
примерную реализацию на C++ систем единиц. Сам ею пользуюсь теперь. Что интересно, результат получился довольно приличный.


Баян
Re[2]: Что толку в Ада если Ариан 5 все равно упал
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.06.05 13:27
Оценка: 7 (2)
Здравствуйте, AndreyFedotov, Вы писали:

AF>Насколько я понимаю ситуацию, ошибка была не в языке программирования, а в процессе разработки.

+1

AF>По всей видимости здесь этого сделано не было, что показывает или раздолбайство, или не высокий профессионализм команды, которая писала код для ариана 5.


С этим можно было бы согласиться, если бы не одно "но" (и это очень большое "но", как я люблю говорить).
Андрей, а тебе приходилось работать в областях, которые можно сравнивать с разработкой софта для Ариан-а?
Мне, например, в течении года довелось поработать в области военной радиолокации. Это был такой дурдом! Причем сложность там была не столько алгоритмическая (реализация конкретных алгоритмов -- это совсем плевое дело, т.к. не мы ими занимались ). Хуже всего, что это был комплекс из немерянного количества компонентов, соединенных разными интерфейсами. И большую часть внимания приходится уделять как раз учету различных особенностей этих интерфейсов. И что самое плохое, нет и никогда не было окончательных спецификаций. Мы делаем свою часть и выясняется, что вон тот модуль чего-то нам не сообщает. Утрясли, согласовали. Проявились смежники, говорят, что мы им чего-то недодаем. Проверили -- действительно. Сделали. Проверили -- не попадаем в расчетное время. Упростили алгоритм, переделали, оказалось, что для него еще чего-то не хватает. Запросили, нам сделали. Проявляются поставщики железа с новой версией своих спецвычислителей. Для которых что-то нужно переделать. Переделали. Проявились смежники. Оказалось, что мы им опять чего-то не выдаем. Выяснили, выдаем, но константное значение, которое не изменяется со временем. Раскопали, наша ошибка в версии для нового спецвычислителя.

И такая канитель каждый день, дзинь-ди-лень, дзинь-ди-лень.

Вот потому я оттуда и ушел.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[32]: Что толку в Ада если Ариан 5 все равно упал
От: CrystaX Россия https://crystax.me/
Дата: 24.06.05 13:31
Оценка:
Здравствуйте, Трурль, Вы писали:

CX>>Кстати, я тут недавно приводил
Автор: CrystaX
Дата: 23.05.05
примерную реализацию на C++ систем единиц. Сам ею пользуюсь теперь. Что интересно, результат получился довольно приличный.


Т>Баян


"Это как же, вашу мать, извиняюсь, понимать?" (с) не помню кто

1. Мы не в "Коллеги, улыбнитесь", чтобы баянами кидаться. К тому же на RSDN этого не было, стало быть — не баян в любом случае.
2. Меня на создание этого враппера подвигло чтение документации к boost::mpl. Если ты внимательно почитаешь доку, что мне дал, то обратишь внимание, что решение Мейерса немного другое. У Мейерса нет систем единиц, у меня — есть. Кроме того, у меня есть автоматический перевод из одной системы в другую.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[3]: Что толку в Ада если Ариан 5 все равно упал
От: AndreyFedotov Россия  
Дата: 24.06.05 13:36
Оценка:
Здравствуйте, eao197, Вы писали:

AF>>По всей видимости здесь этого сделано не было, что показывает или раздолбайство, или не высокий профессионализм команды, которая писала код для ариана 5.


E>С этим можно было бы согласиться, если бы не одно "но" (и это очень большое "но", как я люблю говорить).

E>Андрей, а тебе приходилось работать в областях, которые можно сравнивать с разработкой софта для Ариан-а?
Чуть-чуть.
E>Мне, например, в течении года довелось поработать в области военной радиолокации. Это был такой дурдом! Причем сложность там была не столько алгоритмическая (реализация конкретных алгоритмов -- это совсем плевое дело, т.к. не мы ими занимались ). Хуже всего, что это был комплекс из немерянного количества компонентов, соединенных разными интерфейсами. И большую часть внимания приходится уделять как раз учету различных особенностей этих интерфейсов. И что самое плохое, нет и никогда не было окончательных спецификаций. Мы делаем свою часть и выясняется, что вон тот модуль чего-то нам не сообщает. Утрясли, согласовали. Проявились смежники, говорят, что мы им чего-то недодаем. Проверили -- действительно. Сделали. Проверили -- не попадаем в расчетное время. Упростили алгоритм, переделали, оказалось, что для него еще чего-то не хватает. Запросили, нам сделали. Проявляются поставщики железа с новой версией своих спецвычислителей. Для которых что-то нужно переделать. Переделали. Проявились смежники. Оказалось, что мы им опять чего-то не выдаем. Выяснили, выдаем, но константное значение, которое не изменяется со временем. Раскопали, наша ошибка в версии для нового спецвычислителя.

E>И такая канитель каждый день, дзинь-ди-лень, дзинь-ди-лень.


E>Вот потому я оттуда и ушел.


Очень знакомая картина. Правда аксакалы рассказывали, что во времена седой старины всех жутко дрючили и заставляли документировать интерфейсы в первую очередь и это давало свои плоды... И как все радовались, когда контроль ослаб (как стало ясно горздо позде — как раз в тот момент когда стали терять культуру управления сложными промышленными проектами) и как плевались потом, когда всё пришло к столь знакомой ситуации.
Re[4]: Что толку в Ада если Ариан 5 все равно упал
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.06.05 13:48
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:

AF>Очень знакомая картина. Правда аксакалы рассказывали, что во времена седой старины всех жутко дрючили и заставляли документировать интерфейсы в первую очередь и это давало свои плоды... И как все радовались, когда контроль ослаб (как стало ясно горздо позде — как раз в тот момент когда стали терять культуру управления сложными промышленными проектами) и как плевались потом, когда всё пришло к столь знакомой ситуации.


Как раз документирование лично меня сильно не напрягало, хотя я не много-то в том проекте и задокументировал. Хуже было другое: держишь на руках готовые спецификации, вроде бы всеми согласованные и утвержденные. А начинаешь по ним работать... Мать, мать, мать!!! Оказывается, что все ключевые разработчики, которые реально все знают и все делают, ничего об этих спецификациях и не знают , т.к. пишут бумажки те, кому компилятор в руки давать страшно.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Что толку в Ада если Ариан 5 все равно упал
От: AndreyFedotov Россия  
Дата: 24.06.05 15:39
Оценка: 1 (1) +1
Здравствуйте, eao197, Вы писали:

E>Как раз документирование лично меня сильно не напрягало, хотя я не много-то в том проекте и задокументировал. Хуже было другое: держишь на руках готовые спецификации, вроде бы всеми согласованные и утвержденные. А начинаешь по ним работать... Мать, мать, мать!!! Оказывается, что все ключевые разработчики, которые реально все знают и все делают, ничего об этих спецификациях и не знают , т.к. пишут бумажки те, кому компилятор в руки давать страшно.


Так я об этом бардаке и говорю. По рассказам было время, когда за подобную ситуацию начальника легко могли снять, а спеца если он отступит от бумажки вполне могли вообще под статью подвести. И эта система себя оправдывала. А потом начался либерализм...
Re[30]: Что толку в Ада если Ариан 5 все равно упал
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.06.05 15:55
Оценка: 34 (6)
Здравствуйте, AVC

Попробуем разобраться с твоими вопросами по частям.

AVC>В основном, я вижу опасность в неявном применении переопределенных операторов.

AVC>Я уже приводил на форумах примеры "неадекватного" поведения Си++ в подобных случаях.
AVC>C++ действительно сложен.
AVC>Вопрос в том, насколько необходима, а насколько излишня такая сложность.

Эти вопросы оказались для меня более тяжелыми, чем я предполагал вначале. Дать объективный ответ сложно, поскольку я являюсь ортодоксальным фанатом C++. Так уж получилось, что несколько языков я изучил в университете, а затем особо ничего не изучал, т.к. мне хватало C++. Ситуация частично изменялась всего два раза: в 2001 году, когда я сменил место работы и попрограммировал на Java и в 2004-м году, когда я выбирал язык для реализации своего очередного велосипеда (тогда я серьезно рассмотрел Perl, Python и Ruby, на котором и остановился). Года до 2001-го я думал, что хорошо знаю C++, но затем я узнал про boost и время от времени заглядываю в его реализацию, что бы в очередной раз убедиться, что сейчас C++ -- это совсем не то, что было еще десять лет назад. Сложнее и мощнее.

Собственно, такое длинное вступление я делаю для того, чтобы поделиться своим субъективным мнением. Язык C++ слишком сложен для того, чтобы применяться в большой команде (может быть даже в условиях т.н. промышленной разработки). Подобными выводами я уже делился вот здесь: Re[44]: Почему нельзя преподавать C#
Автор: eao197
Дата: 07.04.05
.

Если провести аналогию, то C++ -- это топор в руках плотника. Известны случаи, когда плотники достигали такого совершенства во владении топором, что могли им бриться (сам видел по телевизору). Равно как известны случаи, когда один-два мастера возводили здания без единого гвоздя и эти здания стояли столетия. Т.е., в моем понимании, C++ -- это сложный, но черезвычайно мощный инструмент, который позволяет за приемлимое время, в условиях органиченных ресурсов, получать отличные результаты. Но платить за это приходится высокой (а иногда и высочайшей) квалификацией и способностями разработчика. Когда над C++ проектом работают два/три продвинутых C++ программиста, они создают очень качественный и надежный код. Но! Стоит этот коллектив каким-то образом разладить, скажем ввести в него парочку менее квалифицированных товарищей, как вся стройность и красота C++ кода превращается в страшилки, которыми регулярно пугают программистов.

Поэтому я думаю, что если в условиях ограниченных ресурсов нужно что-то сделать, и испольнитель отлично владеет C++, то лучше C++ сложно что-то придумать (хотя я не знаток диаметрально противоположных языков, т.к. Smalltalk или Lisp). И еще одно важнейшее условие: команда должна быть небольшой и очень слаженной. Собственно, такое определение можно отнести к любому языку, но для C++ важно то, что C++ имеет очень высокую стоимость вхождения. Гораздо более высокую, чем паскале-подобные языки или Java/C# (хотя последние демонстрируют тенденцию к усложнению). К сожалению, подобные команды складываются не часто. И, к еще большему сожалению, они распадаются под влиянием различных внешних факторов. А стоимость потери ключевого разработчика в C++ проекте, имхо, все же выше, чем в Java. Во многом из-за того, что одну и туже идею на C++ можно реализовать гораздо большим количеством способов, чем на Java. И когда кто-то уходит, то его way теряется безвозвратно.

Опять же к этому можно добавить кучу проблем, которая появилась в C++ из-за совместимости с C. Это и отсутствие проверок при выходе за пределы массива. И возможность приведения типов (как явных, так и неявных). И пятое, и десятое.

В общем, нелицеприятная картина для С++ получается. Особенно в области критически важных систем. И я вынужден с ней согласиться.
Более того, вспоминая свой короткий опыт работы над военным софтом могу сказать, что там не было никаких сверхзадач, для которых потребовалась бы мощь C++ (шаблонов, RAII, макросов). Отличные задачи для реализации на Pascal-е. Хотя, если бы команду уменьшили бы раза в два, то единственным языком, на котором ее можно было бы вовремя решить, имхо, был бы C++. Как раз за счет макросов и шаблонов, которые позволяют писать меньше кода.

E>>С этим сложно спорить. Но широкоизвестные космические катастрофы, связанные с ошибками ПО, никак с этим не были связаны. Про Ариан мы уже долго говорим. Был еще старый случай с фортраном и запятой вместо десятичной точки (хотя этот пример и может попасть в данную категорию, если только все это было на самом деле). А ведь еще был случай с Mars Explorer (или как его там), когда разные модули вычисляли значения в разных системах счисления.


AVC>Да, был такой случай в 1999 году.

AVC>С Фортраном тоже был случай. Кажется, это было в нашем (еще советском) проекте в начале 1970-х.
AVC>Я не понимаю, почему ты полагаешь, что широкоизвестные катастрофы никак не связаны с надежностью языка.
AVC>Смотри сам.
AVC>В случае с циклом FOR в Фортране, просто очевидно, что большая доля вины — на языке.

Возможно, но где-то в форумах было показано, что досадные ляпы можно допускать практически везде. И даже подсветка синтаксиса в интеллектуальных редакторах не спасает.

AVC>В случае с Арианом, из-за недостаточности ресурсов целочисленную переменную не защитили от переполнения, что привело к отключению компьютера. Обращаю внимание, что игнорирование переполнения могло привести к еще худшим последствиям. В области безопасности программа должна быть корректна на 100%. 99% недостаточно!


+1
Но как в этом удостовериться?
Так что это была именно проектная проблема, а не проблема языка.

AVC>В случае с потерей орбиты Марса, если бы вычисления, связанные с разными единицами измерения, относились к разным типам, то ошибку, скорее всего, удалось бы предотвратить, т.к. потребовалось бы явное приведение типов.

AVC>Т.е. напротив, трудно назвать случай не связанный с языком (или нарушением его правил)!

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

Кроме того, я не очень понимаю твою фразу по поводу разных типов. Ведь оперировали-то одним понятием: дистация. Может быть даже тип ввели такой distance . Только одни вычисляли дистанцию в футах, а другие -- в метрах .
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: Что толку в Ада если Ариан 5 все равно упал
От: Павел Кузнецов  
Дата: 24.06.05 16:42
Оценка:
CrystaX,

> "Это как же, вашу мать, извиняюсь, понимать?" (с) не помню кто


Леонид Филатов. "Сказка о Федоте — стрельце, удалом молодце"
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[26]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 24.06.05 21:30
Оценка:
Здравствуйте, eao197, Вы писали:

AL>>Явное и неявное приведение типов, исключения, синтаксический сахар и прочие механизмы, удачные и не очень, -- детский лепет по сравнению с реальными проблемами, возникающими при создании систем управления вроде той, что летает на арианах.


E>Все это так. Но согласитесь, что даже если весь синтаксический сахар какого-тот конкретного языка способен оказать влияние хотя бы на 5% ошибок, то в системах класса Ариан-5 это достаточно высокий показатель для того, чтобы им пренебрегать. И, поскольку изначально тема касалась сложности C++ и ошибок, которые в программы привносятся именно из-за сложности C++, то, имхо, все эти рассуждения в тему.


Никоим образом не желая возобновить флейм на "лингвистические темы", все же не удержусь и подкину "информацию к размышлению".
В том же номере "Открытых систем", откуда взята русскоязычная статья о падении Ариана-5, приводятся следующие сведения. (Кстати, весь этот номер был посвящен теме надежности ПО.)
http://www.osp.ru/os/1998/06/46.htm

Язык С++ дает на 25% больше ошибок, чем традиционные Си или Паскаль, а исправление ошибок в ОО программах на С++ требует в 2-3 раза больше времени. Наследование порождает в 6 раз больше ошибок.

Конечно, будет справедливо, если ты в свою очередь спросишь, кто и как установил сей факт.
Буду честен — не знаю. Так что на цифрах не настаиваю.
Но все же журнал взял откуда-то эти цифры?!

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[28]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 24.06.05 21:30
Оценка:
Здравствуйте, faulx, Вы писали:

F>PVS использовался для верификации IEEE 854 floating point specification. Для подробного знакомства нужно посмотреть сайт или почитать хотя бы первю главу вот этого учебника: http://www.csl.sri.com/papers/wift-tutorial/


Спасибо за ссылку!
Мне кажется, что роль формальных методов в создании надежного ПО сейчас недооценивается.
Хорошо, что не всеми.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[31]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 24.06.05 21:34
Оценка: 15 (2)
Здравствуйте, eao197, Вы писали:

E>Попробуем разобраться с твоими вопросами по частям.


AVC>>В основном, я вижу опасность в неявном применении переопределенных операторов.

AVC>>Я уже приводил на форумах примеры "неадекватного" поведения Си++ в подобных случаях.
AVC>>C++ действительно сложен.
AVC>>Вопрос в том, насколько необходима, а насколько излишня такая сложность.

E>Эти вопросы оказались для меня более тяжелыми, чем я предполагал вначале. Дать объективный ответ сложно, поскольку я являюсь ортодоксальным фанатом C++.


Тем более я ценю твою попытку посмотреть на проблему объективно.
Даже если твои выводы не совпадут с моими.
Из-за некоторой ограниченности во времени отвечать буду тоже по частям.

E>>>С этим сложно спорить. Но широкоизвестные космические катастрофы, связанные с ошибками ПО, никак с этим не были связаны. Про Ариан мы уже долго говорим. Был еще старый случай с фортраном и запятой вместо десятичной точки (хотя этот пример и может попасть в данную категорию, если только все это было на самом деле). А ведь еще был случай с Mars Explorer (или как его там), когда разные модули вычисляли значения в разных системах счисления.


AVC>>Да, был такой случай в 1999 году.

AVC>>С Фортраном тоже был случай. Кажется, это было в нашем (еще советском) проекте в начале 1970-х.
AVC>>Я не понимаю, почему ты полагаешь, что широкоизвестные катастрофы никак не связаны с надежностью языка.
AVC>>Смотри сам.
AVC>>В случае с циклом FOR в Фортране, просто очевидно, что большая доля вины — на языке.

E>Возможно, но где-то в форумах было показано, что досадные ляпы можно допускать практически везде. И даже подсветка синтаксиса в интеллектуальных редакторах не спасает.


Согласен, что ошибки можно совершать везде.
Но некоторые языки (не будем тыкать пальцем ), кажется, и не думают им препятствовать, что несомненно увеличивает число ошибок.
Справедливости ради, должен признать, что и надежные языки таят в себе подводные камни.
После того, как мы начали обсуждать катастрофу Ариана-5, я обратил внимание на пример из электронной книги Вирта "Программирование на Обероне".
PROCEDURE sum(VAR x: ARRAY OF REAL): REAL;
  VAR i: INTEGER; s: REAL;
BEGIN s := 0.0;
  FOR i := 0 TO LEN(x)-1 DO s := x[i] + s END ;
  RETURN s
END sum

На невнимательный взгляд, этот маленький кусок кода не внушает опасений.
Но я только что обдумывал то, что случилось с Арианом-5.
Там переполнилось 16-битное знаковое целое.
В данном случае INTEGER — именно 16-битное знаковое целое, а вот LEN(x) — 32-битное знаковое целое.
По моим представлениям об Обероне компилятор не должен был пропустить такую конструкцию. (Я могу обосновать это, со ссылками на определение языка.)
Но, раз такой пример закрался даже в книгу Вирта (если это не опечатка), я решил проверить доступные мне компиляторы Оберона на "вшивость".
Компиляторы ETH Oberon и BlackBox (в последнем другая разрядность INTEGER и LONGINT, так что я модифицировал исходный код, выбрав тип i: SHORTINT) показали себя "молодцами" и гневно отвергли ошибочный код.
Но вот компилятор XDS счел его корректным.
Для завершения эксперимента осталось только создать массив размерности, превышающей вместимость типа INTEGER
VAR a: ARRAY MAX(INTEGER)+2 OF REAL;

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

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[27]: Что толку в Ада если Ариан 5 все равно упал
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.06.05 07:53
Оценка: +1
Здравствуйте, AVC, Вы писали:

AVC>Здравствуйте, eao197, Вы писали:


AL>>>Явное и неявное приведение типов, исключения, синтаксический сахар и прочие механизмы, удачные и не очень, -- детский лепет по сравнению с реальными проблемами, возникающими при создании систем управления вроде той, что летает на арианах.


E>>Все это так. Но согласитесь, что даже если весь синтаксический сахар какого-тот конкретного языка способен оказать влияние хотя бы на 5% ошибок, то в системах класса Ариан-5 это достаточно высокий показатель для того, чтобы им пренебрегать. И, поскольку изначально тема касалась сложности C++ и ошибок, которые в программы привносятся именно из-за сложности C++, то, имхо, все эти рассуждения в тему.


AVC>http://www.osp.ru/os/1998/06/46.htm

AVC>

AVC>Язык С++ дает на 25% больше ошибок, чем традиционные Си или Паскаль, а исправление ошибок в ОО программах на С++ требует в 2-3 раза больше времени. Наследование порождает в 6 раз больше ошибок.

AVC>Конечно, будет справедливо, если ты в свою очередь спросишь, кто и как установил сей факт.
AVC>Буду честен — не знаю. Так что на цифрах не настаиваю.
AVC>Но все же журнал взял откуда-то эти цифры?!

Честно говоря, я очень скептически отношусть к сравнениям языков между собой по подобным критериям. Ведь что значит сравнить количество ошибок в реализации на C++ или на Паскале? Как минимум, это означает, что нужно взять одну и туже задачу и реализовать ее на двух языках. И вот тут хочется остановиться на двух моментах:

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

2. Не понимаю, как сравнивать качество кода, написанного разными командами, разными людьми с разной квалификацией? А если задачу реализует один человек, то как можно оценивать, насколько хорошо он знает оба языка?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[34]: Что толку в Ада если Ариан 5 все равно упал
От: CrystaX Россия https://crystax.me/
Дата: 25.06.05 08:53
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Леонид Филатов. "Сказка о Федоте — стрельце, удалом молодце"


Точно! Спасибо, Павел!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Re[27]: Что толку в Ада если Ариан 5 все равно упал
От: FR  
Дата: 25.06.05 08:57
Оценка:
Здравствуйте, AVC, Вы писали:


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

AVC>В том же номере "Открытых систем", откуда взята русскоязычная статья о падении Ариана-5, приводятся следующие сведения. (Кстати, весь этот номер был посвящен теме надежности ПО.)
AVC>http://www.osp.ru/os/1998/06/46.htm
AVC>

AVC>Язык С++ дает на 25% больше ошибок, чем традиционные Си или Паскаль, а исправление ошибок в ОО программах на С++ требует в 2-3 раза больше времени. Наследование порождает в 6 раз больше ошибок.

AVC>Конечно, будет справедливо, если ты в свою очередь спросишь, кто и как установил сей факт.
AVC>Буду честен — не знаю. Так что на цифрах не настаиваю.
AVC>Но все же журнал взял откуда-то эти цифры?!

Бред редкостный, судя по дате публикации и стилю, цифры взяты из буржуйских источников эпохи тотального перхода с процедурных языков на C++.
Re[30]: Что толку в Ада если Ариан 5 все равно упал
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 25.06.05 20:52
Оценка:
Здравствуйте, AVC

E>>Сейчас на наших глазах происходит интересное явление: острая конкуренция в языках программирования. С одной стороны, огромные финансовые вливания в Java и C#, с другой стороны -- Perl, Python, Ruby, PHP, да и старичек C++ сдаваться не собирается. Почему языки, лишенные мощной финансовой поддержки (т.к. Perl, Python, Ruby) успешно конкурируют с монстрами Java/C#? Имхо потому, что эти языки создавались для решения конкретных проблем. И развивались для решения других конкретных проблем. И выжили благодоря тому, что хорошо эти проблемы решали. Т.е. это реальные инструменты для реальных задач. Аналогично и с C++. Его необъятность и сложность проистекают из того, что он хорошо решает реальные задачи (было бы наоборот, его бы уже не было). Вот, например, я привел одну такую задачу, которую с помошью generic-ов Java и C# просто так не решить: А generic-и так могут?
Автор: eao197
Дата: 30.05.05


AVC>Спасибо за действительно интересный пример!

AVC>Постараюсь его обдумать.
AVC>Для стимулирования воображения, хотелось бы (если можно) увидеть маленький кусочек клиентского кода.
AVC>Т.е. я все примерно представляю, но в последнее время я мало доверяю своим "беглым мыслям". Стар стал, воображение уже не то...

Алексей, я вот попробовал более простыми словами описать чего хотел: Re: А generic-и: попытка упростить описание
Автор: eao197
Дата: 25.06.05
и Sinclair привел два возможных решения этой проблемы в C#: Re[2]: А generic-и: попытка упростить описание
Автор: Sinclair
Дата: 25.06.05
и Re[4]: А generic-и: попытка упростить описание
Автор: Sinclair
Дата: 25.06.05
.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: Что толку в Ада если Ариан 5 все равно упал
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.06.05 01:39
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>То, что ПО для Ариан-а было написано не на C++, сильно смягчило потерю полумиллиарда долларов

E>Сразу стало легче на душе.

Да, потому что следующие пол миллиарда терять уже не прийдется. Ведь ошибка была найдена. А при проходе по памяти после взрыва сказать что-либо разумное уже не удалось бы.

VD>>Да, да. А опасные возмоности С++ не применяй. А для чего их сделали?


E>Для возможности выжать максимум производительности.


Производительность можно достигнуть и без обхода системы типов. А на более менее большом проекте мест на которых теряется производительность просто моере и лучше устранять их чем лепить опасный код везде. К тому же если авторы осознанно ввели опасные конструкции, то можно было ввести безопасный и опасный режимы, указывая для участков кода что они опасные. Это хотя бы позволило бы больше внимания уделять опасным областям.

E>Таки нет.


Позволь не поверить. Тут вообще лучше спрашивать ваших пользователей. А то вот в МС тоже говорят, что их Ворд очень надежен. А у меня он вылетает трофейный мессер.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Что толку в Ада если Ариан 5 все равно упал
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 26.06.05 06:49
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Таки нет.


VD>Позволь не поверить. Тут вообще лучше спрашивать ваших пользователей. А то вот в МС тоже говорят, что их Ворд очень надежен. А у меня он вылетает трофейный мессер.


Не веришь, проверь: http://eao197.narod.ru/objessty/oess.1.4.0-b2.tar.bz2, если делать больше нечего.
Я свой код ни от кого не скрываю.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[31]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 26.06.05 13:10
Оценка: 27 (1)
Здравствуйте, eao197, Вы писали:

AVC>>C++ действительно сложен.

AVC>>Вопрос в том, насколько необходима, а насколько излишня такая сложность.

E>Эти вопросы оказались для меня более тяжелыми, чем я предполагал вначале. Дать объективный ответ сложно, поскольку я являюсь ортодоксальным фанатом C++. Так уж получилось, что несколько языков я изучил в университете, а затем особо ничего не изучал, т.к. мне хватало C++. Ситуация частично изменялась всего два раза: в 2001 году, когда я сменил место работы и попрограммировал на Java и в 2004-м году, когда я выбирал язык для реализации своего очередного велосипеда (тогда я серьезно рассмотрел Perl, Python и Ruby, на котором и остановился). Года до 2001-го я думал, что хорошо знаю C++, но затем я узнал про boost и время от времени заглядываю в его реализацию, что бы в очередной раз убедиться, что сейчас C++ -- это совсем не то, что было еще десять лет назад. Сложнее и мощнее.


Причем ты делаешь акцент на мощности, а я — на сложности.
Давай, я приму твой довод о мощности Си++, и посмотрим, что из этого получится.
Я думаю, что сложность Си++ во многом вытекает из попыток решения реальных проблем программирования при сохранении старого фундамента.
В силу уже одного этого фактора язык становится сложнее. (Причем "сложнее" — не то слово.)
Казалось бы, такой сложный (и, конечно, мощный тоже) язык теперь предназначается все меньшему числу "истинных профессионалов", так как остальные программиисты ("похуже" ) неизбежно будут путаться и совершать множество ошибок, как "грубых", так и "тонких".
Т.е. Си++ должен был бы позиционироваться как "язык для немногих".
Ведь вряд ли ты ожидаешь увидеть рекламу вроде: "В широкую продажу поступила новая партия машин класса Формула-1, еще более мощных и опасных."
Но вот из "поразившей" тебя цитаты Страуструпа следует, что он гордится безудержным ростом числа Си++программистов (а ведь кому захочется признать себя "лохом", не способным породить высококачественный код на Си++ ). Он пишет, что еще не было года, чтобы в "его полку не прибыло".
Ответственная ли это позиция, учитывая, что подавляющее большинство новоявленных Си++программистов напишет ужасный код?

E>Собственно, такое длинное вступление я делаю для того, чтобы поделиться своим субъективным мнением. Язык C++ слишком сложен для того, чтобы применяться в большой команде (может быть даже в условиях т.н. промышленной разработки). Подобными выводами я уже делился вот здесь: Re[44]: Почему нельзя преподавать C#
Автор: eao197
Дата: 07.04.05
.


E>Если провести аналогию, то C++ -- это топор в руках плотника. Известны случаи, когда плотники достигали такого совершенства во владении топором, что могли им бриться (сам видел по телевизору). Равно как известны случаи, когда один-два мастера возводили здания без единого гвоздя и эти здания стояли столетия. Т.е., в моем понимании, C++ -- это сложный, но черезвычайно мощный инструмент, который позволяет за приемлимое время, в условиях органиченных ресурсов, получать отличные результаты. Но платить за это приходится высокой (а иногда и высочайшей) квалификацией и способностями разработчика. Когда над C++ проектом работают два/три продвинутых C++ программиста, они создают очень качественный и надежный код. Но! Стоит этот коллектив каким-то образом разладить, скажем ввести в него парочку менее квалифицированных товарищей, как вся стройность и красота C++ кода превращается в страшилки, которыми регулярно пугают программистов.


Хочу привести пример в подкрепление твоей точки зрения.
Есть у меня один знакомый Си++программист высочайшего уровня.
(Я даже назову его имя, так как страна должна знать своих героев: Иван Жиганов.)
В одиночку он сопровождает огромный код, обслуживающий целую отрасль нашего города.
Но работать в команде он практически неспособен. (Потому и делает все сам.)
Его код труден для понимания, настолько там все закручено на ООП.
Как он поясняет свои мысли, я уже рассказывал.
Добавим сюда, что программирование для него — образ жизни, а не "просто работа".
Вот таким я и вижу настоящего Си++программиста.
Образ притягивающий и отталкивающий одновременно.
Наподобие Стрикленда, главного героя романа Сомерсета Моэма "Луна и грош".

E>Поэтому я думаю, что если в условиях ограниченных ресурсов нужно что-то сделать, и испольнитель отлично владеет C++, то лучше C++ сложно что-то придумать (хотя я не знаток диаметрально противоположных языков, т.к. Smalltalk или Lisp). И еще одно важнейшее условие: команда должна быть небольшой и очень слаженной. Собственно, такое определение можно отнести к любому языку, но для C++ важно то, что C++ имеет очень высокую стоимость вхождения. Гораздо более высокую, чем паскале-подобные языки или Java/C# (хотя последние демонстрируют тенденцию к усложнению). К сожалению, подобные команды складываются не часто. И, к еще большему сожалению, они распадаются под влиянием различных внешних факторов. А стоимость потери ключевого разработчика в C++ проекте, имхо, все же выше, чем в Java. Во многом из-за того, что одну и туже идею на C++ можно реализовать гораздо большим количеством способов, чем на Java. И когда кто-то уходит, то его way теряется безвозвратно.


E>Опять же к этому можно добавить кучу проблем, которая появилась в C++ из-за совместимости с C. Это и отсутствие проверок при выходе за пределы массива. И возможность приведения типов (как явных, так и неявных). И пятое, и десятое.


BTW, сильно сомневаюсь в искренности аргумента Страуструпа о "совместимости" Си++ и Си (тема legacy code).
Если даже я, грешный, весьма свободно сочетаю в своей работе несколько языков (в том числе Си++ и Оберон).
Ведь, как правило, "сменные части" наших систем мы выносим в DLL, которые могут быть написаны на разных языках.

E>В общем, нелицеприятная картина для С++ получается. Особенно в области критически важных систем. И я вынужден с ней согласиться.

E>Более того, вспоминая свой короткий опыт работы над военным софтом могу сказать, что там не было никаких сверхзадач, для которых потребовалась бы мощь C++ (шаблонов, RAII, макросов). Отличные задачи для реализации на Pascal-е. Хотя, если бы команду уменьшили бы раза в два, то единственным языком, на котором ее можно было бы вовремя решить, имхо, был бы C++. Как раз за счет макросов и шаблонов, которые позволяют писать меньше кода.

E>>>С этим сложно спорить. Но широкоизвестные космические катастрофы, связанные с ошибками ПО, никак с этим не были связаны. Про Ариан мы уже долго говорим. Был еще старый случай с фортраном и запятой вместо десятичной точки (хотя этот пример и может попасть в данную категорию, если только все это было на самом деле). А ведь еще был случай с Mars Explorer (или как его там), когда разные модули вычисляли значения в разных системах счисления.


AVC>>Да, был такой случай в 1999 году.

AVC>>С Фортраном тоже был случай. Кажется, это было в нашем (еще советском) проекте в начале 1970-х.
AVC>>Я не понимаю, почему ты полагаешь, что широкоизвестные катастрофы никак не связаны с надежностью языка.
AVC>>Смотри сам.
AVC>>В случае с циклом FOR в Фортране, просто очевидно, что большая доля вины — на языке.

E>Возможно, но где-то в форумах было показано, что досадные ляпы можно допускать практически везде. И даже подсветка синтаксиса в интеллектуальных редакторах не спасает.


AVC>>В случае с Арианом, из-за недостаточности ресурсов целочисленную переменную не защитили от переполнения, что привело к отключению компьютера. Обращаю внимание, что игнорирование переполнения могло привести к еще худшим последствиям. В области безопасности программа должна быть корректна на 100%. 99% недостаточно!


E>+1

E>Но как в этом удостовериться?
E>Так что это была именно проектная проблема, а не проблема языка.

Вместе с тем, это проектное решение, наверное, нашло выражение в конкретной строке кода.
Т.к. это была Ада, подозреваю, что строка выглядела примерно так:
pragma SUPPRESS(OUT_OF_BOUNDS);

(Интересно, владеет ли кто-нибудь информацией об этом злополучном фрагменте исходного кода Ариана-5?)
Хоар много раз выступал против подобной практики удаления защитного кода после отладки.

AVC>>В случае с потерей орбиты Марса, если бы вычисления, связанные с разными единицами измерения, относились к разным типам, то ошибку, скорее всего, удалось бы предотвратить, т.к. потребовалось бы явное приведение типов.

AVC>>Т.е. напротив, трудно назвать случай не связанный с языком (или нарушением его правил)!

E>Вот чего я в этой аварии не понимаю, так это то, что данную ошибку не смогли обнаружить во время тестовых прогонов на Земле! Такое чувство, что разные модули вообще не сопрягали в тестовом режиме! Имхо, здесь проблема была в организации тестирования (хотя мне легко об этом говорить).


Меня это тоже удивляет.
Вероятно, прав Трурль: во многом причина в беспечности, связанной с "кодреюзом" (это код многократно тестировался и использовался до того, blah-blah-blah, зачем его тестировать заново?).

E>Кроме того, я не очень понимаю твою фразу по поводу разных типов. Ведь оперировали-то одним понятием: дистация. Может быть даже тип ввели такой distance . Только одни вычисляли дистанцию в футах, а другие -- в метрах .


Наверное, ты прав: я здесь "умен задним числом".
Но хотя бы на будущее...

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.