Ada_Ru форум

Обсуждение языка Ада

Ada on Topic

Оставить новое сообщение

Сообщения

Victor Olegovich
Ada on Topic
2011-05-30 04:29:21

С миром всем,

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

 Популярное изложение свежих фактов.

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

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

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

2) Полезность такого ДИВЕРСНОГО подхода к управляющим ПС зависит от вероятности

различия случайных составляющих свойств каждой из используемых версий ПС. Для обеспечения максимальной вероятности (говорят: "дивестности") можно использовать, всё, что только можно, в том числе различия ЯП, их компиляторов. Если одна из версий  разработана на языке, который считается наиболее технологичным (например, за счёт своей популярности), то выбор языка для другой,

понятно, должен диктоваться иным соображением - максимальной опозицией первому языку в отношении формирования недокументированной случайной части свойств ПС. Подобный выбор, "диверсной пары" языков конечно не должен быть субъективен, а вытекать из объективных результатов предварительных исследований.

3) Мои коллеги из авиационного ун-та "ХАИ" под руководством проф. В.С.Харченко,

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

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

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

что удалось успешно использовать фонды спортивного программирования, где на одни

и те же требования обнаруживаются разработки примерно равных по силе и условиям

работы участников на разных языках. Результаты могут быть использованы, но, увы,

Ады опять не будет просто потому, что сегодня в спортивном программировании она

не представлена.

 Что делать?

1) Участники упомянутой группы исследователей, которые приедут на школу-семинар

по Аде в Лазурное, предлагают предварительную АНКЕТУ для предварительной оценки

черт отличия языка Ада от прочих с точки зрения возможности привнесения разработками на этом языке оригинальных свойств в недокументированную часть программ. Поскольку я отношусь к этой группе как рабочий консультант по языку Ада, то прошу честных рыцарей заполнить анкету "Языковая диверсность", которая 31 мая появится на сайте Ада-ру, а заодно высказать замечания и предложения по её содержанию. Всё это слать на мой личный мэйл, открытый в рассылке (victor_olegovich@yahoo.com) до 6 июня. От тех, кто со мной лично не знаком, каких-либо анкетных данных о них самих не требуется, в этом случае достаточно, чтобы письмо пришло с адреса, зарегистрированного в рассылке.

2) Более профессионально и подробно о затронутых вопросах будет доложено в середине июня в Лазурном. Планируется обсуждение итогов анкетирования.

3) Предполагается, что участники ВИТ-Ада от "ХАИ" предложат (на основе обработки

анкет) условия проведения прямого эксперимента для оценки диверсности ЯП, включая Аду. Это также будет обсуждаться. В идеале, при наличии благоприятных условий, эксперимент можно было бы провести прямо на месте. Иначе будет составлен какой-то реальный план.

С уважением,

Виктор

On Mon, 30 May 2011 11:29:21 -0700 (PDT), you wrote:

 

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

 

Т.е. ПО, требования к нему, не адекватны. Строили подводную лодку для полета на Луну...

 

Тогда случайным образом ПО либо

вырабатывет решение, благоприятное для предотвращение катастрофы, либо нет.

 

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

функционирования в условиях не предусмотренных требованиями. Оба случая являются грубейшими ошибками.

 

2) Полезность такого ДИВЕРСНОГО подхода к управляющим ПС зависит от вероятности

различия случайных составляющих свойств каждой из используемых версий ПС.

 

Подход этот бесполезен и, более того, вреден по следующим причинам:

1. Случайность требований не имеет отношения к реализации.

 

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

 

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

"голосования" исчислялось бы астрономическим числом.

 

4. Алгоритм "голосования" должен разрабатываться по тем же критериям (порочный круг).

 

ПО корректно тогда и только тогда, когда отвечает требованиям. Этим все сказано. Не ищите Джавдета у Сухого Ручья...

 

3) Мои коллеги из авиационного ун-та "ХАИ" под руководством проф. В.С.Харченко,

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

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

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

что удалось успешно использовать фонды спортивного программирования, где на одни

и те же требования обнаруживаются разработки примерно равных по силе и условиям

работы участников на разных языках. Результаты могут быть использованы, но, увы,

Ады опять не будет просто потому, что сегодня в спортивном программировании она

не представлена.

 

И слава Богу. Усилия следует вкладывать в статический анализ и

совершенствование языковой поддержки оного, а не в "случайное"

программирование случайных программ.

 

P.S. Прошу прощения за резкость, наболело.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Спортивное программирование резко отличается от промышленного

программирования, поэтому для выбора языка промышленного

программирования нельзя использовать собранную статистику в спортивном программировании.

Dmitry A. Kazakov wrote:

On Mon, 30 May 2011 11:29:21 -0700 (PDT), you wrote:

 

И слава Богу. Усилия следует вкладывать в статический анализ и

совершенствование языковой поддержки оного, а не в "случайное"

программирование случайных программ.

 

P.S. Прошу прощения за резкость, наболело.

 

Полностью согласен со сказанным Дмитрием.

 

Случайное программирование хорошо в университетах, и то, если деньги

девать некуда. Едва ли у кого из присутствующих имеет место подобная

ситуация

Ага,

То, что оспаривается, имеет шанс пробиться к истине :)

Добрый вечер, Дмитрий

и все, кто не остался равнодушным!

 

 

________________________________

 

From: Dmitry A. Kazakov <alt@...>

To: ada_ru@yahoogroups.com

Sent: Mon, May 30, 2011 11:02:05 PM

Subject: Re: [ada_ru] Ada on Topic

 

 

-- Или прочли невнимательно, или гипербола - подруга стиля. Речь о том, что в разных доках строили 2 подлодки. Построили, плавают, прошли испытания. А потом попали под глубинные бомбы: так одна треснула вдоль и сразу ко дну, а другая поперёк на безлюдном отсеке, и экипаж сумел штатно спастись. При сварке тяжелого

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

эта разница привела к разному распределению прочностных характеристик по поверхности корпуса. Проэтому лодки из первого дока имеют больше шансов выжить в

одних сверхкритических ситуациях, а из второго - в других. Рекомендация комиссии: в одно боевое соединение обязательно включать подлодки, изготовленные

в разных доках.

 

 

 

Тогда случайным образом ПО либо

вырабатывет решение, благоприятное для предотвращение катастрофы, либо нет.

 

ПО ничего не вырабатывает случайным образом,

 

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

 

 если не используются

генераторы случайных чисел.

 

-- такие генераторы уж точно к случайности отношения не имеют, а выдают детерминированные последовательности, которые позволют более или менее удачно МОДЕЛИРОВАТЬ эффект случайности. Вы это хорошо знаете.

 

 Случайны здесь требования не покрывающие всех

возможных состояний системы

 

-- Не для придирки,  я и впраду не понял, что Вы в этой части фразы имели в виду

(возможно оговорка или пропуск). Речь шла не о случайных ТРЕБОВАНИЯХ, а о случайных свойствах. Совокупность требований в критических приложениях стараются

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

одну линию обороны, которая не даст гарантий, но увеличит шансы на выживание. Если воин, на которого в кромешной тьме набегают враги, станет быстро вертеть мечом в разные стороны, то может выжить - случайно, разумеется. А вот, если он останется неподвижен, пока не будет точно знать, с какой сторны придёт смертельный удар, то погибнет (с гордым чувством, что это закономерно).

 

 и реализация допускающая продолжение

функционирования в условиях не предусмотренных требованиями. Оба случая являются грубейшими ошибками.

 

-- Про первый случай сказано. Второй. Капитан ведёт учебное судно в тихой бухте,

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

 

 

2) Полезность такого ДИВЕРСНОГО подхода к управляющим ПС зависит от вероятности

 

различия случайных составляющих свойств каждой из используемых версий ПС.

 

Подход этот бесполезен и, более того, вреден по следующим причинам:

1. Случайность требований не имеет отношения к реализации.

 

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

 

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

"голосования" исчислялось бы астрономическим числом.

 

4. Алгоритм "голосования" должен разрабатываться по тем же критериям (порочный круг).

 

-- Кроме пункта 1, смысл которого искренне не понимаю, и 4, который мне представляется в контексте обсуждения не доказанным, согласиться с посылками можно, особенно со вторым (двумя руками, я часто использую оба сформулированных

в нем аргумента!). А вот правила, с помощью которого из них бы выводилась "бесполезность" и "вредность" не вижу.

 

...

 

> ... Но буквально только

что удалось успешно использовать фонды спортивного программирования, где на >одни

 

и те же требования обнаруживаются разработки примерно равных по силе и условиям

 

работы участников на разных языках. Результаты могут быть использованы, но, >увы,

 

Ады опять не будет просто потому, что сегодня в спортивном программировании она

 

не представлена.

 

И слава Богу. Усилия следует вкладывать в статический анализ и

совершенствование языковой поддержки оного,

 

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

а не в "случайное"

программирование случайных программ.

 

-- опять художественный оборот :)

 

P.S. Прошу прощения за резкость, наболело.

 

-- Охотно извиняю, и в свою очередь прошу не иметь зла за упорство в ереси

-- Предлагаю сосредоточится, как и положено в этой переписке, на Аде. -- Еще раз коротко. В одном из известнейших университетов в Союзе и постсоюзе заинтересовались Адой и попросили подмоги (заполнить анкету). Хотя я не считаю данный конкретный повод бесполезным и вредным, охотно согласился бы с Дмитрием (и от своих коллег в ХАИ не скрываю), если бы он сказал, что тема сложнее, чем об этом было мной популярно объявленно, а получить значимый для практики эффект

от диверсности (особенно языковой!) - это совершить великий подвиг на уровне "миссия невозможна".

-- Однако, "кто ищет, тот найдёт!" ( бывает, что искал золото, а нашел платину

:). Еще раз прошу - помогите людям удовлетворить их интерес к особенным свойствам языка Ада. И анкету критикуйте не стесняясь, только, по возможности, конструктивно. Потом обсудим выводы, к которым придут непредвзятые исследователи. Заодно эти исследователи обживут немного Аду в своём университете

:)

 

Спасибо за высказанные здесь и в других письмах мнения,

с уважением,

Виктор

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

 

 

------------------------------------

 

Yahoo! Groups Links

 

 

 

 

On Mon, 30 May 2011 11:29:21 -0700 (PDT), you wrote:

 

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

 

Т.е. ПО, требования к нему, не адекватны. Строили подводную лодку для полета на Луну...

 

 

 

________________________________

 

From: Alexey Veselovsky <alexey.veselovsky@...>

To: ada_ru@yahoogroups.com

Sent: Mon, May 30, 2011 11:42:00 PM

Subject: Re: [ada_ru] Ada on Topic

 

 

-- Да!!!

 

поэтому для выбора языка промышленного

программирования

 

-- Пардон, будьте внимательны, не одного языка, а, покрайней мере, пары. При этом первый в паре наверняка такой, "как надо" для промышленного программирования, что бы это ни значило. А второй должен удовлетворять другим  требованиям, а именно, как можно больше "отличаться" от первого. А что бы это значило, может помочь понять и спортивное программирование, и заполнение и обработка предлагаемой анкеты!

 

-- Виктор

 

нельзя использовать собранную статистику в спортивном

программировании.

 

 

------------------------------------

 

Yahoo! Groups Links

 

 

 

 

Спортивное программирование резко отличается от промышленного

программирования,

 

 

 

________________________________

 

From: Sergey I. Rybin <rybin@adacore.com>

To: ada_ru@yahoogroups.com

Sent: Tue, May 31, 2011 1:18:05 AM

Subject: Re: [ada_ru] Ada on Topic

 

 

-- Однако, Сергей Игоревич, а кто и кому здесь предлагал "слечайное программирование"? 

-- Что до денег в универах, то на голую Аду и шишь ждать не приходится, Вы это давно и первый поняли! А вот на языковую диверсность светит, причём против Ады в

этом контексте не только никто не против, а даже интересуются... Так как там, в

индустрии, с потенциальным заказчиком себя ведут :?

 

-- Приезжайте в Лазурное - покажете,

-- В.О.

 

 

 

 

------------------------------------

 

Yahoo! Groups Links

 

 

 

 

Dmitry A. Kazakov wrote:

On Mon, 30 May 2011 11:29:21 -0700 (PDT), you wrote:

 

И слава Богу. Усилия следует вкладывать в статический анализ и

совершенствование языковой поддержки оного, а не в "случайное"

программирование случайных программ.

 

P.S. Прошу прощения за резкость, наболело.

 

Полностью согласен со сказанным Дмитрием.

 

Случайное программирование хорошо в университетах, и то, если деньги девать некуда. Едва ли у кого из присутствующих имеет место подобная ситуация

 

 

 

 

________________________________

 

From: Alexey Veselovsky <alexey.veselovsky@...>

To: ada_ru@yahoogroups.com

Sent: Tue, May 31, 2011 4:11:16 PM

Subject: Re: [ada_ru] Ada on Topic

 

 

-- На вкус и цвет ...  Мне показалось - неплохо (правда, на своей машине я черного фона не видал)....

-- Однако потребитель всегда прав, и автор дизайна опвещен, и обещал подумать, как сделать лучше.

 

 

Можно версию с черным текстом и таблицами на обычном белом фоне без изысков дизайнеров?

 

-- Конечно, у меня есть. Я прешлю Максиму, и, думаю, завтра будет на сайте.

------------------------------------

 

Yahoo! Groups Links

 

 

 

 

Убей дизайнера - спаси юзабилити!

 

Это ж не читаемо! Черный текст на черном фоне.. Так, помнится в ZX Spectrum'e загрузчики игр защищали от взлома :-)

 

 

 

 

 

________________________________

From: Vladimir Gorelov <virtual.lark@gmail.com>

To: ada_ru@yahoogroups.com

Sent: Tue, May 31, 2011 3:12:46 PM

Subject: Re: [ada_ru] Ada on Topic

 

 

прошу честных рыцарей заполнить анкету "Языковая диверсность", которая 31 мая появится на сайте Ада-ру, а заодно высказать замечания и предложения

по

её содержанию.

 

Вот обещанная анкета:

http://www.ada-ru.org/files/languagies_diversity_form.doc

 

На всякий случай в PDF-формате:

http://www.ada-ru.org/files/languagies_diversity_form.pdf

 

Текст под "красивыми кружевными изогнутыми линиями" не читаем. Ни в doc ни в pdf.

 

 -- С конструктивностью этого зампечания не поспоришь! Прошу простить, что такое

случилось. Простой док, как я пообещал, будет передан, чтобы выставить. Если и это не поможет, выставим плэйн текст :!)

 

 

 

 

________________________________

 

From: Vadim Godunko <vgodunko@rostel.ru>

To: ada_ru@yahoogroups.com

Sent: Tue, May 31, 2011 9:45:12 PM

Subject: Re: [ada_ru] Ada on Topic

 

 

-- Через десяток дней сможете ... Творчество было коллективное, но, кажется, будут все

 

К своему

несчастью, я "завалился" уже на первой странице в виду неспособности охарактеризовать Рук/Кол/Исп. :-(

 

-- Вы, я думаю, "Рук" :) Можете продолжать дальше :)

 

Если серьёзно - не важно какой язык,

важно какая Команда. Без Команды произведения технологического искусства типа подводных лодок, космических станций и адронных коллаидров невозможны.

-- Но Команды, по моим наблюдениям, редко (чтобы не сказать никогда) возникают,

как манна небесная. Это всегда чей-то труд, чаще всего коллективный, по привлечению, отбору, обучению, поощрению. По мне это труд в целом радостный

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

--В.О.

------------------------------------

 

Yahoo! Groups Links

 

 

 

 

On 05/31/2011 03:24 PM, Maxim Reznik wrote:

On Mon, May 30, 2011 at 11:29:21AM -0700, Victor Olegovich wrote: [skip]

прошу честных рыцарей заполнить анкету "Языковая диверсность", которая 31 мая появится на сайте Ада-ру, а заодно высказать замечания и предложения

по

её содержанию.

 

Вот обещанная анкета:

http://www.ada-ru.org/files/languagies_diversity_form.doc

 

На всякий случай в PDF-формате:

http://www.ada-ru.org/files/languagies_diversity_form.pdf

 

Интересная анкета, здорово было бы побесеовать с авторами.

On Mon, May 30, 2011 at 11:29:21AM -0700, Victor Olegovich wrote: [skip]

прошу честных рыцарей заполнить анкету "Языковая диверсность", которая 31 мая появится на сайте Ада-ру, а заодно высказать замечания и предложения по

её содержанию.

 

Вот обещанная анкета:

http://www.ada-ru.org/files/languagies_diversity_form.doc

 

На всякий случай в PDF-формате:

http://www.ada-ru.org/files/languagies_diversity_form.pdf

 

--

Maxim Reznik

прошу честных рыцарей заполнить анкету "Языковая диверсность", которая 31 мая появится на сайте Ада-ру, а заодно высказать замечания и предложения по её содержанию.

 

Вот обещанная анкета:

http://www.ada-ru.org/files/languagies_diversity_form.doc

 

На всякий случай в PDF-формате:

http://www.ada-ru.org/files/languagies_diversity_form.pdf

 

Текст под "красивыми кружевными изогнутыми линиями" не читаем. Ни в doc ни в pdf.

Убей дизайнера - спаси юзабилити!

 

Это ж не читаемо! Черный текст на черном фоне.. Так, помнится в ZX Spectrum'e загрузчики игр защищали от взлома :-)

 

Можно версию с черным текстом и таблицами на обычном белом фоне без изысков дизайнеров?

On 05/31/2011 03:24 PM, Maxim Reznik wrote:

On Mon, May 30, 2011 at 11:29:21AM -0700, Victor Olegovich wrote:

[skip]

прошу честных рыцарей заполнить анкету "Языковая диверсность", которая

31 мая появится на сайте Ада-ру, а заодно высказать замечания и предложения по

её содержанию.

 

Вот обещанная анкета:

http://www.ada-ru.org/files/languagies_diversity_form.doc

 

На всякий случай в PDF-формате:

http://www.ada-ru.org/files/languagies_diversity_form.pdf

 

Интересная анкета, здорово было бы побесеовать с авторами. К своему несчастью, я "завалился" уже на первой странице в виду неспособности охарактеризовать Рук/Кол/Исп. :-( Если серьёзно - не важно какой язык, важно какая Команда. Без Команды произведения технологического искусства типа подводных лодок, космических станций и адронных коллаидров невозможны.

On Tue, 31 May 2011 11:14:54 -0700 (PDT), you wrote:

 

-- Или прочли невнимательно, или гипербола - подруга стиля. Речь о том, что в разных доках строили 2 подлодки. Построили, плавают, прошли испытания. А потом

попали под глубинные бомбы: так одна треснула вдоль и сразу ко дну, а другая поперёк на безлюдном отсеке, и экипаж сумел штатно спастись. При сварке тяжелого

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

эта разница привела к разному распределению прочностных характеристик по поверхности корпуса. Проэтому лодки из первого дока имеют больше шансов выжить в

одних сверхкритических ситуациях, а из второго - в других. Рекомендация комиссии: в одно боевое соединение обязательно включать подлодки, изготовленные

в разных доках.

 

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

 

Тогда случайным образом ПО либо

вырабатывет решение, благоприятное для предотвращение катастрофы, либо нет.

 

ПО ничего не вырабатывает случайным образом,

 

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

дляя их создателей.

 

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

 

-- такие генераторы уж точно к случайности отношения не имеют, а выдают детерминированные последовательности, которые позволют более или менее удачно МОДЕЛИРОВАТЬ эффект случайности. Вы это хорошо знаете.

 

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

 Случайны здесь требования не покрывающие всех

возможных состояний системы

 

-- Не для придирки,  я и впраду не понял, что Вы в этой части фразы имели в виду

(возможно оговорка или пропуск). Речь шла не о случайных ТРЕБОВАНИЯХ, а о случайных свойствах.

 

Именно о требованиях. Свойства, существенные для функционирования системы, исчерпывающе описаны в требованиях. То, что требованиями не описано, не случайно, а просто не определено. Например, не определено, как будет вычислен синус при сбрасывании системного блока с 15-го этажа. (В некоторых случаях определено, например, до 10g должно работать, после - на

усмотрение).

 

Совокупность требований в критических приложениях стараются

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

одну линию обороны, которая не даст гарантий, но увеличит шансы на выживание.

 

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

Короче, задернем занавески не окнах вагона, и будем петь - "ту-ту", никто не заметит, что поезд стоит...

 

> и реализация допускающая продолжение

функционирования в условиях не предусмотренных требованиями. Оба случая являются грубейшими ошибками.

 

-- Про первый случай сказано. Второй. Капитан ведёт учебное судно в тихой бухте,

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

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

критического назначения.

 

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

 

2) Полезность такого ДИВЕРСНОГО подхода к управляющим ПС зависит от вероятности

 

различия случайных составляющих свойств каждой из используемых версий ПС.

 

Подход этот бесполезен и, более того, вреден по следующим причинам:

1. Случайность требований не имеет отношения к реализации.

 

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

 

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

"голосования" исчислялось бы астрономическим числом.

 

4. Алгоритм "голосования" должен разрабатываться по тем же критериям (порочный круг).

 

-- Кроме пункта 1, смысл которого искренне не понимаю,

 

Смысл в том, что ошибки в требованиях не являются ошибками программы. Если Вы потребовали чтобы + умножал, то программа вычисляющая 3+2=6 корректна, а 3+2=5 ошибочна. Поэтому, когда Вы говорите, что программа может что-то там исправить, пропущенное в требованиях, это просто бессмысленно. Если только не предполагать наличие божественного провидения, помечающего одни цепочки команд как кошерные, а другие нет.

 

и 4, который мне

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

в нем аргумента!). А вот правила, с помощью которого из них бы выводилась "бесполезность" и "вредность" не вижу.

 

Правила просты:

 

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

 

б. Даже если бы закон больших чисел работал, количество "неправильных" программ на много порядков превышает количество "правильных". (Кавычки здесь, потому, что правильно-неправильно бессмысленно вне требований) Так вот, в силу этого прискорбного обстоятельства голосование всегда будет выдавать "неправильный" ответ. (Знакомая ситуация, не правда ли? (:-))

в. И наконец, даже если бы Вам каким-то чудом удалось бы изменить (воспитать) Ваших избирателей так, чтобы правильных стало, хотя бы больше 50%, число вариантов таково, что всех атомов вселенной не хватило бы для кодирования программ покрытия всех критериев с доминированием "правильных" по каждому.

 

Ситуация заведомо проигрышная: "Как поймать льва. Оставьте клетку в пустыне. Существует большая нуля вероятность, что лев сам залезет в клетку и запрет за собой дверь."

 

И слава Богу. Усилия следует вкладывать в статический анализ и

совершенствование языковой поддержки оного,

 

-- Вкладывать нужно, а кто спорил? Но выше прозвучало "разработчики требований совершают ... ошибки" А чем в такой ситуации может помочь любой вид

анализа на соответствие кода и требований?

 

"Любой" это как? Мой любимый анекдот на эту тему про то, как астронавтов тренировали лазать на деревья. На дереве-то ближе к Луне...

 

Особенно, если это ошибки не по

невнимательности, а по недостаточности уровня современных знаний?

 

И что теперь, карты Таро раскладывать? При любом уровне знаний подход должен быть научным.

 

а не в "случайное"

программирование случайных программ.

 

-- опять художественный оборот :)

 

Так оно образней... (:-))

 

-- Однако, "кто ищет, тот найдёт!" ( бывает, что искал золото, а нашел платину

:). Еще раз прошу - помогите людям удовлетворить их интерес к особенным свойствам языка Ада. И анкету критикуйте не стесняясь, только, по возможности,

конструктивно. Потом обсудим выводы, к которым придут непредвзятые исследователи. Заодно эти исследователи обживут немного Аду в своём университете

 

Есть такое

 

http://rosettacode.org/wiki/Language_Comparison_Table

 

и такое

 

http://rigaux.org/language-study/syntax-across-languages.html

 

Вообще, в сети этого полно, я привел только то, где по-участвовал немного, и потому запомнил.

 

А анкета - забавна, поскольку, в отличие от как-бы "объективных" критериев, как в приведенных выше сравнениях, она вроде бы напирает на субъективную оценку опрашиваемого. Я такого еще не встречал.

 

Присоединяюсь к Вадиму, было бы очень интересно побазарить с авторами анкеты.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

 

 

 

 

________________________________

 

From: Dmitry A. Kazakov <alt@dmitry-kazakov.de>

To: ada_ru@yahoogroups.com

Sent: Wed, June 1, 2011 12:35:38 AM

Subject: Re: [ada_ru] Ada on Topic

 

 

:)))

 

 

Тогда случайным образом ПО либо

вырабатывет решение, благоприятное для предотвращение катастрофы, либо нет.

 

ПО ничего не вырабатывает случайным образом,

 

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

 

дляя их создателей.

 

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

 

 

 

:(( Критерий максимальной предсказуемости - да. Увольнениям - нет (никого не останется)

 

 

 

-- такие генераторы уж точно к случайности отношения не имеют, а выдают детерминированные последовательности, которые позволют более или менее удачно МОДЕЛИРОВАТЬ эффект случайности. Вы это хорошо знаете.

 

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

 

 

;) Именно ими Вы чаше всего и пользуетесь? (можно не отвечать)

 

 

 

 Случайны здесь требования не покрывающие всех

возможных состояний системы

 

-- Не для придирки,  я и впраду не понял, что Вы в этой части фразы имели в >виду

 

(возможно оговорка или пропуск). Речь шла не о случайных ТРЕБОВАНИЯХ, а о случайных свойствах.

 

Именно о требованиях. Свойства, существенные для функционирования системы, исчерпывающе описаны в требованиях. То, что требованиями не описано, не случайно, а просто не определено. Например, не определено, как будет вычислен синус при сбрасывании системного блока с 15-го этажа. (В некоторых случаях определено, например, до 10g должно работать, после - на

усмотрение).

 

 

 

;) А, вот- вот, как-то сбросили на какой-то планете, где 10.001g и синус (который входит в формулу подачи для нас кислорода) посчитался правильно. Мы тогда как говорим "Хвала Богу, что на эти 0.001 не посмотрело и сработало правильно!" или "Подумаешь, сегодня-завтра помереть - какая разница!" ?

 

Совокупность требований в критических приложениях стараются

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

 

одну линию обороны, которая не даст гарантий, но увеличит шансы на выживание.

 

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

 

 

-- И согласиться бы можно, да страшновато. То, что ПО, как вещь в себе детерминировано, много ли нам пользы несёт? у нас-то всё оценки да ожидания ...

 

 

Короче, задернем занавески не окнах вагона, и будем петь - "ту-ту", никто не заметит, что поезд стоит...

 

 

-- Я такого не предлагал и теоретики диверсности тоже

 

 

> и реализация допускающая продолжение

функционирования в условиях не предусмотренных требованиями. Оба случая являются грубейшими ошибками.

 

-- Про первый случай сказано. Второй. Капитан ведёт учебное судно в тихой >бухте,

 

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

 

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

 

критического назначения.

 

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

 

 

-- Ну, тот капитан, который среагирует так, вряд-ли спасет себя и команду. Но найдутся и такие, кто умудрится принять нештатное решение, которое спасёт. И обсуждаемый вопрос сводится к тому, следует ли учить капитанов так, чтобы повысить вероятность второго исхода?

 

 

 

 

2) Полезность такого ДИВЕРСНОГО подхода к управляющим ПС зависит от вероятности

 

 

различия случайных составляющих свойств каждой из используемых версий ПС.

 

Подход этот бесполезен и, более того, вреден по следующим причинам:

1. Случайность требований не имеет отношения к реализации.

 

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

 

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

"голосования" исчислялось бы астрономическим числом.

 

4. Алгоритм "голосования" должен разрабатываться по тем же критериям (порочный круг).

 

-- Кроме пункта 1, смысл которого искренне не понимаю,

 

Смысл в том, что ошибки в требованиях не являются ошибками программы.

 

-- Уважаю чужое мнение, но моё таким не будет никогда.

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

доступных терминах или доступными  средствами).

 

 Если

Вы потребовали чтобы + умножал, то программа вычисляющая 3+2=6 корректна, а 3+2=5 ошибочна. Поэтому, когда Вы говорите, что программа может что-то там исправить, пропущенное в требованиях, это просто бессмысленно.

 

 

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

минимальныаи потерями не удасться. Но, если у кого-то есть идея, как повысить шансы на лучший исход, то почему-бы не содействовать его изысканиям?

 

 Если только

не предполагать наличие божественного провидения, помечающего одни цепочки команд как кошерные, а другие нет.

 

и 4, который мне

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

 

в нем аргумента!). А вот правила, с помощью которого из них бы выводилась "бесполезность" и "вредность" не вижу.

 

Правила просты:

 

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

 

б. Даже если бы закон больших чисел работал, количество "неправильных" программ на много порядков превышает количество "правильных". (Кавычки здесь, потому, что правильно-неправильно бессмысленно вне требований) Так вот, в силу этого прискорбного обстоятельства голосование всегда будет выдавать "неправильный" ответ. (Знакомая ситуация, не правда ли? (:-))

в. И наконец, даже если бы Вам каким-то чудом удалось бы изменить (воспитать) Ваших избирателей так, чтобы правильных стало, хотя бы больше 50%, число вариантов таково, что всех атомов вселенной не хватило бы для кодирования программ покрытия всех критериев с доминированием "правильных" по каждому.

 

Ситуация заведомо проигрышная: "Как поймать льва. Оставьте клетку в пустыне. Существует большая нуля вероятность, что лев сам залезет в клетку и запрет за собой дверь."

 

 

 

-- Внимательно читал. Показалось, что это тоже - не правила вывода, а постулаты.

Каждый из которых можно признать справедливым. Но чтоб из них логически вытекало

опровержение диверсного подхода, я не вижу. А на собственное доказательство его

правильности не претендую нисколько. Только сочувствую, желаю, чтоб чего-то полезное получилась на этом пути. Готов в меру сил посодействовать.

 

И слава Богу. Усилия следует вкладывать в статический анализ и

совершенствование языковой поддержки оного,

 

-- Вкладывать нужно, а кто спорил? Но выше прозвучало "разработчики требований совершают ... ошибки" А чем в такой ситуации может помочь любой вид

 

анализа на соответствие кода и требований?

 

"Любой" это как? Мой любимый анекдот на эту тему про то, как астронавтов тренировали лазать на деревья. На дереве-то ближе к Луне...

 

 

-- Я бы ничего и не говорил, если бы знал уже тогда, что Вы готовы признать программу безупречной, несмотря на то, что она разрабатывалась по ошибочным требованиям.

 

 

Особенно, если это ошибки не по

невнимательности, а по недостаточности уровня современных знаний?

 

И что теперь, карты Таро раскладывать? При любом уровне знаний подход должен быть научным.

 

 

 

-- Неужто понимание недостаточности знания НЕ ЕСТЬ неотъемлемая черта научного знания?

-- Тем-то карты таро и не научны, что всегда чего-то "говорят" с одинаковым апломбом

 

 

а не в "случайное"

программирование случайных программ.

 

-- опять художественный оборот :)

 

Так оно образней... (:-))

 

 

-- Да я не против не только науки, но и искусства :-))

 

 

-- Однако, "кто ищет, тот найдёт!" ( бывает, что искал золото, а нашел платину

 

:). Еще раз прошу - помогите людям удовлетворить их интерес к особенным свойствам языка Ада. И анкету критикуйте не стесняясь, только, по возможности,

 

конструктивно. Потом обсудим выводы, к которым придут непредвзятые исследователи. Заодно эти исследователи обживут немного Аду в своём >университете

 

 

Есть такое

 

http://rosettacode.org/wiki/Language_Comparison_Table

 

и такое

 

http://rigaux.org/language-study/syntax-across-languages.html

 

Вообще, в сети этого полно, я привел только то, где по-участвовал немного, и потому запомнил.

 

 

-- Передам своим коллегам диверсологам, мо и не видели!

 

 

А анкета - забавна, поскольку, в отличие от как-бы "объективных" критериев, как в приведенных выше сравнениях, она вроде бы напирает на субъективную оценку опрашиваемого. Я такого еще не встречал.

 

 

-- Вот видите, "честная анкета" (я обращаю внимание на Ваше "как-бы")!

 

Присоединяюсь к Вадиму, было бы очень интересно побазарить с авторами анкеты.

 

 

-- Присоединяйтесь физически, и побазарите !:)

 

-- А вообще у Вадима правильная реакция была в том смысле, что на практике диверсность проистекает из таких более мощных и комплексных факторов, как разные

исполнители (а они разные, в частности, но не только, и по ипользуемым инструментам, как, например, язык) . Но давайте подождём (кто туда собрался) до

Лазурного и послушаем участников программы исследований, о тему которой уже наломали копий, хотя я, вро подчеркнул, что предлагаю популярное введение в предмет и только на своё примитивное понимание.

 

-- С уважением к слушателям и опонентам,

-- Виктор

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

 

 

------------------------------------

 

Yahoo! Groups Links

 

 

 

 

On Tue, 31 May 2011 11:14:54 -0700 (PDT), you wrote:

 

-- Или прочли невнимательно, или гипербола - подруга стиля. Речь о том, что в разных доках строили 2 подлодки. Построили, плавают, прошли испытания. А потом

 

попали под глубинные бомбы: так одна треснула вдоль и сразу ко дну, а другая поперёк на безлюдном отсеке, и экипаж сумел штатно спастись. При сварке >тяжелого

 

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

 

эта разница привела к разному распределению прочностных характеристик по поверхности корпуса. Проэтому лодки из первого дока имеют больше шансов выжить

 

одних сверхкритических ситуациях, а из второго - в других. Рекомендация комиссии: в одно боевое соединение обязательно включать подлодки, изготовленные

 

в разных доках.

 

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

On Tue, May 31, 2011 at 11:43:51AM -0700, Victor Olegovich wrote:

Можно версию с черным текстом и таблицами на обычном белом фоне без изысков дизайнеров?

 

-- Конечно, у меня есть. Я прешлю Максиму, и, думаю, завтра будет на сайте.

 

Версия без фона на сайте, на том же месте. Присланый .htm не стал выкладывать, т.к. там все русские буквы физически представлены

знаками вопроса.

--

Maxim Reznik

On Wed, 1 Jun 2011 13:36:41 -0700 (PDT), you wrote:

 

;) А, вот- вот, как-то сбросили на какой-то планете, где 10.001g и синус (который входит в формулу подачи для нас кислорода) посчитался правильно.

 

Когда Вас сбросят в поле тяготения постоянных 10g, Вам не понадобится ни синус, ни кислород...

 

Мы

тогда как говорим "Хвала Богу, что на эти 0.001 не посмотрело и сработало правильно!" или "Подумаешь, сегодня-завтра помереть - какая разница!" ?

 

Что иллюстрирует ошибочность подхода. Когда требования разрабатываются, они должны отвечать критериям:

 

1. Полноты. Это означает, что фактор ускорения должен рассматривается, если идет речь о людях, как субъектах движения. Ваша первая ошибка в том, что Вы собираетесь что-то сказать о факторах, которые не рассматривались вообще. Ошибочно это в корне, так как всего предсказать невозможно, а тем более, разумным образом учесть. Существенные же факторы ДОЛЖНЫ быть в требованиях. Ничто Вам не поможет, если это не сделано. Если Вы не рассматривали необходимость регенерации воздуха вообще, то никакая "диверсионная" (:-)) разработка туалетного блока кислородом Вас не обеспечит.

 

2. Факторы вошедшие в требования и подающиеся измерению (и, имеющие порядок, как сказали бы математики), учитываются с ЗАПАСОМ. Это вторая Ваша ошибка: 0.001 процент вариации ускорения в запланированном диапазоне ничего не меняет, т.к. запас 200-400% и более, либо "пациент" все равно помрет. (Пол у Вас в квартире не рухнет, если Вы пригласите в гости на одного человека больше, а вот ведро нейтронов с нейтронной звезды я бы не советовал.)

 

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

 

-- И согласиться бы можно, да страшновато. То, что ПО, как вещь в себе детерминировано, много ли нам пользы несёт? у нас-то всё оценки да ожидания ...

 

Это вопрос не ко мне, а к господу Богу. Я изложил факт не-применимости методов статистического анализа к поведению программ (и процессу их разработки тоже). Факт сам по себе не может нравится или не нравится, нести пользу и или нет. Он просто есть. Установление факта может.

 

Короче, задернем занавески не окнах вагона, и будем петь - "ту-ту", никто не заметит, что поезд стоит...

 

-- Я такого не предлагал и теоретики диверсности тоже

 

А как иначе? Вы предлагаете манипулировать оценкой функционирования кривого ПО, вместо того, чтобы менять его.

 

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

Эта "беда" имеет массу причин как экономического, так и психологического свойства, и Ваше программирование "диверсий", лишь один пример из длинного и печального ряда других "диверсий".

 

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

 

-- Ну, тот капитан, который среагирует так, вряд-ли спасет себя и команду. Но найдутся и такие, кто умудрится принять нештатное решение, которое спасёт. И обсуждаемый вопрос сводится к тому, следует ли учить капитанов так, чтобы повысить вероятность второго исхода?

 

Не следует, так как учеба предполагает наличие знания. Так вот, если Вы ЗНАЕТЕ, что надо делать для спасения жизней, это уже ШТАТНОЕ действие, и его не исполнение - преступная халатность.

 

Смысл в том, что ошибки в требованиях не являются ошибками программы.

 

-- Уважаю чужое мнение, но моё таким не будет никогда.

-- Если, конечно, не давать какого-то казуистического определения "программе",

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

 

(Например маршевая боеголовка...) Это - чепуха, действия программы не моральны. Бессмысленно говорить о моральности программы вычисляющий синус, даже если результат используется в артиллерийской таблице стрельб. Ее правильность определяется не использованием, в соответствием спецификации.

Простенькое доказательство: программа правильна, даже если не используется и наоборот.

 

а любое формальное понимание

правильности - попытка предсказать или оценить эту "человеческую" правильность в

доступных терминах или доступными  средствами).

 

Не хочу Вас огорчать, но Вселенной или Богу, как угодно, глубоко наплевать на "человеческую" правильность.

 

Если

Вы потребовали чтобы + умножал, то программа вычисляющая 3+2=6 корректна, а 3+2=5 ошибочна. Поэтому, когда Вы говорите, что программа может что-то там исправить, пропущенное в требованиях, это просто бессмысленно.

 

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

 

Если Вам это не безразлично учтите те, другие, условия. Тут все просто, если Вы не учитываете их, значит Вам или а) лень (уволить!), или б) безразлично.

 

Больше того, я

говорил, что, к сожалению, форс-мажор и есть форс-мажор - гарантировать выход с

минимальныаи потерями не удасться. Но, если у кого-то есть идея, как повысить шансы на лучший исход, то почему-бы не содействовать его изысканиям?

 

Разумеется, и это важнейшая часть требований к ПО. Потери тут ни при чем. Требования просто ТРЕБУЮТ, чтобы при скорости более 200км/ч система выполнила процедуру аварийного останова. Оный останов, между прочим, разносит юстировку валов стенда, после чего неделю стенд не работает. Стоимость порядка 100К и выше. Это - лучший исход, чем вылет машины вместе с водителем через стену испытательной камеры. Оценка рисков - часть процесса разработки требований.

 

Теперь подумайте вот над чем. А собственно почему разброс поведения должен минимизировать риск? Пример: почему бы не воткнуть два гвоздя в розетку и не полизать их языком, в плане диверсификации поведения? См. пункт б ниже.

и 4, который мне

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

 

в нем аргумента!). А вот правила, с помощью которого из них бы выводилась "бесполезность" и "вредность" не вижу.

 

Правила просты:

 

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

 

б. Даже если бы закон больших чисел работал, количество "неправильных" программ на много порядков превышает количество "правильных". (Кавычки здесь, потому, что правильно-неправильно бессмысленно вне требований) Так вот, в силу этого прискорбного обстоятельства голосование всегда будет выдавать "неправильный" ответ. (Знакомая ситуация, не правда ли? (:-))

в. И наконец, даже если бы Вам каким-то чудом удалось бы изменить (воспитать) Ваших избирателей так, чтобы правильных стало, хотя бы больше 50%, число вариантов таково, что всех атомов вселенной не хватило бы для кодирования программ покрытия всех критериев с доминированием "правильных" по каждому.

 

Ситуация заведомо проигрышная: "Как поймать льва. Оставьте клетку в пустыне. Существует большая нуля вероятность, что лев сам залезет в клетку и запрет за собой дверь."

 

-- Внимательно читал. Показалось, что это тоже - не правила вывода, а постулаты.

Каждый из которых можно признать справедливым. Но чтоб из них логически вытекало

опровержение диверсного подхода, я не вижу.

 

Оно опровергает обоснование подхода, базирующееся на некоей

(предполагаемой) статистической модели поведения и разработки программ.

Согласно а) модели быть не может вообще.

 

Согласно б) если бы была (но см. пункт а), то не такая как подход предполагает.

 

Согласно в) если бы даже и такая (но см. пункт б), то экономически и технически подход не был бы применим.

 

ergo, полная безнадега.

 

И слава Богу. Усилия следует вкладывать в статический анализ и

совершенствование языковой поддержки оного,

 

-- Вкладывать нужно, а кто спорил? Но выше прозвучало "разработчики требований совершают ... ошибки" А чем в такой ситуации может помочь любой вид

 

анализа на соответствие кода и требований?

 

"Любой" это как? Мой любимый анекдот на эту тему про то, как астронавтов тренировали лазать на деревья. На дереве-то ближе к Луне...

 

-- Я бы ничего и не говорил, если бы знал уже тогда, что Вы готовы признать программу безупречной, несмотря на то, что она разрабатывалась по ошибочным требованиям.

 

А как иначе? Вы приходите в магазин и говорите - дайте мне пол-кило масла. А Вам приносят крем для чистки ботинок, на том основании, что Ваше требование кто-то (кто? когда? почему? зачем?) признал ошибочным. Это называется - бардак, а не магазин.

 

Особенно, если это ошибки не по

невнимательности, а по недостаточности уровня современных знаний?

 

И что теперь, карты Таро раскладывать? При любом уровне знаний подход должен быть научным.

 

-- Неужто понимание недостаточности знания НЕ ЕСТЬ неотъемлемая черта научного

знания?

 

Так в том то и дело, что понимания НЕТ! Если есть понимание, что знаний недостаточно для постройки корабля для полета к центру галактики, так его и не строят. А если понимания нет, то бегут на блошиный рынок покупать запчасти от велосипедов!

 

-- Тем-то карты таро и не научны, что всегда чего-то "говорят" с одинаковым апломбом

 

Вот тут мы и возвращаемся к "программным диверсиям"! (:-))

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

-- Привет всем!

 

 

 

Когда Вас сбросят в поле тяготения постоянных 10g, Вам не понадобится ни синус, ни кислород...

 

-- придирка к условностям примера. Стоило ли?

 

 

Что иллюстрирует ошибочность подхода. Когда требования разрабатываются, они должны отвечать критериям:

...

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

когда из этих очень общих положений нельзя извлечь конкретной пользы, давайте не

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

 

-- И согласиться бы можно, да страшновато. То, что ПО, как вещь в себе детерминировано, много ли нам пользы несёт? у нас-то всё оценки да ожидания

...

 

Это вопрос не ко мне, а к господу Богу...

 

 

-- но он не участник нашей переписки ;) и такими пассажами спорщик присваивает себе статус вещания от его имени - давайте не будем!

 

 

 

А как иначе? Вы предлагаете манипулировать оценкой функционирования кривого ПО, вместо того, чтобы менять его.

 

-- и когда это я "предлагал манипулировать оценкой функционирования кривого ПО" напомните, пожалуйста

 

 

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

 

-- Вы предлагаете осудить "Всякие там "стандарты" безопасности ПО" как вредное 

явление?

-- ОК - согласен! Однако ни от Вашего осуждения, ни от моего согласия они не сгинут!:)

 

 

 

Эта "беда" имеет массу причин как экономического, так и психологического свойства, и Ваше программирование "диверсий", лишь один пример из длинного и печального ряда других "диверсий".

 

 

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

 

 

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

 

-- Ну, тот капитан, который среагирует так, вряд-ли спасет себя и команду. Но найдутся и такие, кто умудрится принять нештатное решение, которое спасёт. И обсуждаемый вопрос сводится к тому, следует ли учить капитанов так, чтобы повысить вероятность второго исхода?

 

Не следует, так как учеба предполагает наличие знания. Так вот, если Вы ЗНАЕТЕ, что надо делать для спасения жизней, это уже ШТАТНОЕ действие, и его не исполнение - преступная халатность.

 

 

 

-- Если бы в эту фразу не вкралась описка, я бы сказал, что мы с Вами -  единомышленники (правильно: "если Вы ЗНАЕТЕ, что надо ХОТЬ ЧТО-ТО делать для спасения жизней" и далее по тексту)

 

 

 

Смысл в том, что ошибки в требованиях не являются ошибками программы.

 

-- Уважаю чужое мнение, но моё таким не будет никогда.

-- Если, конечно, не давать какого-то казуистического определения "программе",

 

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

 

(Например маршевая боеголовка...) Это - чепуха, действия программы не моральны. Бессмысленно говорить о моральности программы вычисляющий синус, даже если результат используется в артиллерийской таблице стрельб. Ее правильность определяется не использованием, в соответствием спецификации.

 

-- праграмма-то не моральна (да это никого и не волнует), но иногда имеет смысл учитывать маральные аспекты при её оценке!

 

 

 

Простенькое доказательство: программа правильна, даже если не используется и наоборот.

 

-- Верность этого утверждения зависит от того, что понимать под "правильная" и тем Выше "доказательство" заводит в порочный круг...

 

...

 

Не хочу Вас огорчать, но Вселенной или Богу, как угодно, глубоко наплевать на "человеческую" правильность.

 

-- Как удобно высказываться за субъектов, которые в дискуссию заведомо не вмешаются, не опровергнут :) .......... но и не подтвердят! :(

 

....

 

Разумеется, и это важнейшая часть требований к ПО. Потери тут ни при чем. Требования просто ТРЕБУЮТ, чтобы при скорости более 200км/ч система выполнила процедуру аварийного останова. Оный останов, между прочим, разносит юстировку валов стенда, после чего неделю стенд не работает. Стоимость порядка 100К и выше. Это - лучший исход, чем вылет машины вместе с водителем через стену испытательной камеры. Оценка рисков - часть процесса разработки требований.

 

-- С этим отрывком согласен!

 

 

Теперь подумайте вот над чем. А собственно почему разброс поведения должен минимизировать риск? Пример: почему бы не воткнуть два гвоздя в розетку и не полизать их языком, в плане диверсификации поведения? См. пункт б ниже.

-- А это элементарное передёргивание (не думаю, что ошибка). Опонент говорит: "существуют ситуации, когда риск таким-то способом можно минимизировать"  И, чтобы его опровергнуть необходимо доказать, что "таким-то" способом риск НИКОГДА

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

 

 

... 

опровержение диверсного подхода, я не вижу.

 

Оно опровергает обоснование подхода, базирующееся на некоей

(предполагаемой) статистической модели поведения и разработки программ.

Согласно а) модели быть не может вообще.

 

Согласно б) если бы была (но см. пункт а), то не такая как подход предполагает.

 

Согласно в) если бы даже и такая (но см. пункт б), то экономически и технически подход не был бы применим.

 

ergo, полная безнадега.

 

 

-- Разрешите не коментировать! То, что имело бы смысл возразить, с логической точки зрения аналогично тому, что я пояснял Выше

...

 

А как иначе? Вы приходите в магазин и говорите - дайте мне пол-кило масла. А Вам приносят крем для чистки ботинок, на том основании, что Ваше требование кто-то (кто? когда? почему? зачем?) признал ошибочным. Это называется - бардак, а не магазин.

 

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

...

 

-- Неужто понимание недостаточности знания НЕ ЕСТЬ неотъемлемая черта научного

 

знания?

 

Так в том то и дело, что понимания НЕТ! Если есть понимание, что знаний недостаточно для постройки корабля для полета к центру галактики, так его и не строят. А если понимания нет, то бегут на блошиный рынок покупать запчасти от велосипедов!

 

 

 

-- Само по себе это не вызывает особых возражений

 

 

 

-- Тем-то карты таро и не научны, что всегда чего-то "говорят" с одинаковым апломбом

 

Вот тут мы и возвращаемся к "программным диверсиям"! (:-))

 

 

 

 

 

-- Дмитрий, пусть это последнее слово будет за Вами! Спасибо, Вы много сделали для того, чтобы к вопросу о заполнении анкет привлечь внимание участников переписки! И я искренне старался во всем, что до моего скромного ума доходило, с

Вами соглашаться :)

 

-- С уважением,

-- Виктор

-- Еще раз привет!

 

 

________________________________

 

From: Sergey I. Rybin <rybin@adacore.com>

To: ada_ru@yahoogroups.com

Sent: Wed, June 8, 2011 5:52:09 PM

Subject: Re: [ada_ru] Ada on Topic

 

 

 

 

-- Вот это правильно! Чем больше убираешь. тем яснее становится!!!

 

 

Господа-товарищи, по-моему, дискуссия приобрела характер священной войны индустрии с университетами. А оно бесконечно и неконструктивно.

 

 

 

 

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

квалифицировать как флуд. Согласимся?

 

 

 

Можно еще раз с начала, но КОРОТКО. Что предлагается? Зачем? За какие ресурсы?

 

 

-- //Коротко:// я просил заполнить анкету, выставленную на сайте //Зачем:// по просьбе коллег из другого универа, изысканиям которых я вполне сочувствую. //За

какие ресурсы:// - за моральное удовлетворение - просил не стесняться присовокупить к анкете здоровую ругань и конструктивные предложения - всё на мой

личный адрес в Яхо (дабы не засорять переписку).

 

 

-- Что до потенциального зказчика - он не мой. В Лазурном, кто захочет, попробует на такие темы общаться с авторами диверсного подхода и анкеты. А потом

делиться с тем, с кем сочтёт (если сочтёт) возможным и нужным, разумеется, приватным образом.

 

-- С уважением,

-- Виктор

Dmitry A. Kazakov wrote:

On Wed, 1 Jun 2011 13:36:41 -0700 (PDT), you wrote:

 

;) А, вот- вот, как-то сбросили на какой-то планете, где 10.001g и синус (который входит в формулу подачи для нас кислорода) посчитался правильно.

 

Когда Вас сбросят в поле тяготения постоянных 10g, Вам не понадобится ни синус, ни кислород...

 

остальное убрано для ясности....

Dmitry A. Kazakov wrote:

On Wed, 1 Jun 2011 13:36:41 -0700 (PDT), you wrote:

 

;) А, вот- вот, как-то сбросили на какой-то планете, где 10.001g и синус

(который входит в формулу подачи для нас кислорода) посчитался правильно.

 

Когда Вас сбросят в поле тяготения постоянных 10g, Вам не понадобится ни

синус, ни кислород...

 

остальное убрано для ясности....

 

Господа-товарищи, по-моему, дискуссия приобрела характер священной войны

индустрии с университетами. А оно бесконечно и неконструктивно.

 

Можно еще раз с начала, но КОРОТКО. Что предлагается? Зачем? За какие ресурсы?

Новое сообщение:
Страницы: 1 2

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти