Oberon space

Ага... вслед за Путиным в каких случаях?..

Если Вы имеете в виду, что некие вещи вроде как описаны на одинэсовской странице про УПП, про которую Geniepro говорил - то из этого неясно, как там внутри сделано... а Усов вроде как об этом (типа, какие БД и процедуры их обработки)...

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

... интерпретируемый функциональный erlang (оторванный от реального железа и замаскировавший императивную машину) со сборщиком мусора работает на уровне java и быстрее чем хвалимый Go.

и при каких условиях?..

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

... подобный рецепт как минимум гарантирует отвращение к синтаксису языка которым подобным образом пытали (и инструментарию вообще).

А какими высказываниями Усова это подтверждается?..
Кстати, на ту же тему, в общем, и мой вопрос здесь: каким образом всё это несвязанное реализуется?..

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

Т.е. проблема могла быть "за пределами Оберона или Ады" - но определяться свойствами их конкретных реализаций (язык+библиотеки)... из данных по отчёту неясно, почему тупо взяли этот прибор, не скомпоновав его нормально с окружением...

Да, вот ещё такая книга была... Вроде как в тему - но каков подход, понять трудно... много чего бывает за мудрыми названиями и аннотациями... Может, кто читал и поделится впечатлениями?..

Цитата: info21 от Сентябрь 07, 2012, 07:39:21 am

Про Ариан.

Изделие стоимостью полГИГАдолларов.

Окей, давайте вернёмся к Ариану-5.

... что в Вашем разборе опять же в тему... для чего программировать без отвращения...

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

Разработчики данного прибора - да. Тем более, что они, как можно понять, зафиксировали условия применения.
Как я понимаю, в целом разработчиков Ариан-5 извинить мы не можем. Исходя из этого:

..., а тот самый злосчастный код перешёл в Ариан-5 именно из Ариана-4.

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

То есть в ПО этого датчика на самом деле НЕ БЫЛО ошибки!!!

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

- я так же понял это. И вот мы видим, что неправильная эксплуатация прибора была заложена в самом проекте Ариан-5 - его разработчиками.
Ибо из изложенного следует - главной ошибкой в том ПО было то, что главному компу вообще было позволено решать что-то по данным от этого датчика после команды "Подъём" (или как там у них, у французов). И пользователи ракеты изменить в этом уже ничего не могли - разве что грамотно приёмку проекта проводить - что тоже важно.
А ошибку допустили, как ни крути, архитекторы проекта. Раз датчик только для состояния ракеты "на старте" - значит, надо было прописать в требованиях отключение этого входа после выхода ракеты из этого состояния. Как уж там - программно поставить порт в игнор или схемно отключить по прохождению какого-то сигнала, означающего начало движения ракеты - их дело. Но что д.б. реализовано в программе точно - это логика нормальной реакции на пропадание этих данных. Т.е. ПО главного компа по отключению этого входа обязано было пользоваться только другими источниками для определения положения.

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

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

У меня рабочее определение здесь - документирование фактов организованной деятельности с последующим отнесением к категориям отражения деятельности. Типа так.

И вот отсюда, как уже говорил, вижу различия видов учёта прежде всего в выборе структуры категорий. Для начала - в источнике выбора. Для БУ - это государство с его ПС, ПБУ, НК и пр. Для УУ - руководство оргсистемы (предприятия, учреждения) с его [не]системным подходом к управлению. Системный, по моему разумению в свете позиции Усова - это когда в основе подразделение на рабочие места и более укрупнённые единицы ПМ.
И потребители результатов разные - надсистема у БУ и подсистема управления у УУ. Каждый принимает свои решения, касающиеся ЖЦ оргсистемы - и там, и там разные и по степени оперативности, и по глубине влияния. И требует своих представлений учтённого - как по составу показателей, так и по формам выдачи.
Тогда как ОУ - поставщик документированных фактов для того и другого. Первичное звено в обоих контурах...
Вот и интересно, как ещё можно понимать...

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