_bel@s_
Так вот думаю: "А вообще возможно в принципе написать серьезный программный продукт, при этом допустить минимум (идеальный случай 0) глюков ?"
Кто как думает? Может это просто моя особенность, или у остальных также?
- есть такая наука - термодинамика (если не ошибаюсь)
- так вот там есть один вывод: любой кристалл при температуре Т>0 ДОЛЖЕН иметь вполне определенное относительное количество дефектов
(и только самые малые кристаллы - например вискеры - могут быть без дефектов, просто за счет вероятности)

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

panch

по термодинамике глюков должно быть гораздо меньше

гдето 3 на 100000000

в нашем случае все гороздо хуже
Эта оценка зависит от температуры программиста - и от чего то еще...

contr
Космические проекты слишком малочисленны для набора надежной статистики.
Если оценивать именно по проектам (т.е. уникальным конструкциям, а не запускам типовых систем), то я бы оценил процентов этак в 5-10...
На память, правда, приходят только венерианский зонд, один из марсианских проектов и пара "дальних" аппаратов...
самая классическая ошибка - взрыв ракеты ариан

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

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

Пользователь
- отсюда вопрос: как из малых программ создать большую программу, которая будет иметь малое количество ошибок (большую прочность - в терминологии материалов)?
раз уж выходные:
1) кадый программный модуль - использовать только в тех конфигурациях (диапазон переменных, выполняемая задача) - для которого он (модуль) создан
2) на каждом этапе создания программы - создавать только малые программные модули (малые - в смысле чтоб быть уверенным в отсутствии ошибок)

- требование (2) - создавать программу с несколькими уровнями абстракции:
% команды языка,
% модули первого слоя,
% из модулей первого слоя - модули второго слоя,
% и т. д.

DocAl Пользователь
- отсюда вопрос: как из малых программ создать большую программу, которая будет иметь малое количество ошибок (большую прочность - в терминологии материалов)?
А это классический Unix-way...
- переведи ? (я не понял)

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

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

Пользователь
1) кадый программный модуль - использовать только в тех конфигурациях (диапазон переменных, выполняемая задача) - для которого он (модуль) создан
2) на каждом этапе создания программы - создавать только малые программные модули (малые - в смысле чтоб быть уверенным в отсутствии ошибок)
(продолжим оперу)
- при сравнении с миром нитей, тканей - вырисовывается и третий пункт:

3) должно быть несколько (много) РАЗНЫХ путей в программе для выполнения одной и той же задачи.
------------
(расшифровка)
- из вискеров всегда создают дву\трех мерные сборища (веревки, ткани), в результате надежность конструкции возрастает: обрыв одного вискера не приводит к разрыву веревки\ткани.
- все вискеры РАЗНЫЕ (в смысле: обрыв одного вискера не приводит автоматически к разрыву других - если в данном вискере есть дефект, то это не значит, что в других этот же дефект будет присутствовать - все вискеры РАЗНЫЕ)

То есть если взять просто несколько копий одного и того же модуля (простое дублирование) - ошибка в модуле (если она есть) будет во всех. Это и означает (много) РАЗНЫХ путей.
------------
вот пункт (3) - как логически реализовать - непонятно...
современные программы - (если продолжить аналогию) - это вискеры, связанные в одномерную нить: обрыв одного вискера - приводит к обрыву всей нити.

pirovindos Рецепт лечения простой, но почти не выполнимый: 80% времени от работы потратить на тестирование (можно и самому если фантазии хватит). Помогает, проверено.
так пользователи все свое время и занимаются тестированием,
то есть по этой логике
- тиражный продукт всегда надежнее,
- одиночный продукт сделать надежным нельзя.

Пользователь
3) должно быть несколько (много) РАЗНЫХ путей в программе для выполнения одной и той же задачи.

- РАЗНЫЕ пути: если есть N разных путей для выполнения одной задачи (как они там будут конкурировать - отдельный вопрос - простым голосованием...) - то нет ни одного модуля, который бы присутствовал во всех путях.
(иначе ошибка в одном модуле приведет в обрыву сразу всех путей)

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

В базах данных - достаточно хорошо разработанные методы - транзакции и т.д.

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

Пользователь
В базах данных - достаточно хорошо разработанные методы - транзакции и т.д.

- есть ли что-то похожее для программ - для обработки событий в программах?
(типа есть менеджер транзакций - есть ли менеджер событий?)
типа:
МЕНЕДЖЕР СОБЫТИЙ (МС)
--------------------
- все события - через МС
- хранит список зарегистрированных событий
- каждое событие: состоит из:

* максимального времени на обработку события
* список обработчиков событий, выстроенный по приоритету
* состояние события: ожидание\обработка

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