Я тоже программист.
1. Объектно-риентированного программирования не существует. Существует объектно-ориентированное проектирование. И нужно оно только для того, чтобы свести сложность системы к приемлемому уровню. Все. Точка. Это единственная причина применения ООП.
2. Для встраиваемых и, тем более, систем реального времени отказ от ООП можеть быть вызван жесткими требованиями к шустордействию и то только если нельзя поставить более мощное железо. Второй (первый на самом деле) уважаемый мотив: знания имеющейся команды. Все остальное - базары в пользу бедных.
3. Язык вобще не имеет значения. На Ц++, Жаве или МелкомТолке можно писать вполне процедурно - хлеще чем на бэйсике. Язык, кроме узкоспециализированных, вобще почти не на что не влияет. Культура проектирования и кодирования - да, а утверждать, что на паскале получается "понятнее"... Ну да - для программистов на паскале.
5. Не ОО библиотеки подразумеваются свободными от ошибок? Ха-ха-ха!

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

Извините, что вобще влез.

>...это не значит, что он панацея

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

Хм... Сам компилятор - такой слой :-) Еще один слой - рантайм библиотека паскаля. А если уж дать волю паранойе и писать систему с нуля (вполне оправдано, когда основое требование - надежность), то чем ООП хуже процедурного программирования? ОО подход, скажем, очень сильно помогает избежать логических при внесении изменений в систему. Это работает и при процедурном подходе: программируя на ассемблере для PICа (RISC-однокристаллка), я договаривался с собой, что эта вот переменная "инкапсулированна" вот в этом вот модуле - получился вполне устойчивый к изменениям код.

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

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

Всё, что Вы рассказали, наверное, правильно. Чувствуется, что у Вас большой опыт и понимание того, что Вы пишете. Если Вы будете создавать комплекс ДПЛА или другую сложную техническую систему, то наверное, всё это примените.
Беда в том, что Вы, как и все нынешние программисты, потоптанные конкурентной гонкой, всё видите несколько через кривое зеркало. Вот Вы пишете:

>...тут критерий один - скрость разработки системы на известном вам языке..<

НЕТ!!! Нет такого критерия вообще! Надо не быстро, а надёжно. Понимате? Самолёты иначе НЕ ЛЕТАЮТ.

А юнит-тесты -- очень правильный подход, хотя и очень трудоёмкий. Зато Вы хорошо продумываете внешние условия для каждого модуля программы. Ну, и проверяете всё. Это хорошо.

{+}

а кто будет тестировать те самые юнит-тесты, которые будут тестировать юниты? Люди всегда остаются людьми, и им все равно, где делать ошибки. В тестах или собственно в целевой программе. Это, вообще-то, проблема любой КПА (контрольно-проверочной аппаратуры) - аппаратура в результате регулировки (программа в результате поиска багов) соответствует параметрам КПА, или юнит-теста. И если для железа это оправдано - железа может быть много, а руки у монтажников и комплектовщиков кривые каждый раз по новому, то с ПО - непонятна выгода. Программа-то одна, нет? и от номера изделия ее свойства не изменяются. Имеют смысл интерфейсные тесты, для стыковки юнит, разрабатываемыми разными коллективами. А это - чистое КПА.

Мудрый текст.

Конечно, "юнит-тесты" отражают скорее представления программиста о том, в какой среде живёт программа в реальности, а вовсе не правильность работы программы.
Уверенность в сложных комплексах дают только большие объёмы лётных (ну, натурных) испытаний. Очень большие объёмы испытаний... Годы испытаний...

время светских бесед:)
Реальная программа живет в железе, которое подключено к датчикам и исполнительным механизмам. Юнит-тестовое окружение дает среду для действий программы, созданную воображением программиста. И если он считает землю плоской - увы. Для реальной пользы словом тест не отделаться. Жуткий по сложности программный комплекс нужен. И колоссальный объем его испытаний, даже не представляю, какой. Как его соотнести с реальностью - не Doom, чай.
Юнит тесты могут быть так же средством контроля взаимодействия программы с железом. Хотя я предпочитаю имитаторы. Нет, положительно, навскидку такой разговор я вести не способен, шибко думай надо, однака:)

>...Жуткий по сложности программный комплекс нужен...

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