---Господ "программистов" просят не беспокоиться.

я не "программист" а программист. Потому вырос до руководителя проектов. И вот эта мысль мне нравится:

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

Документирование всегда было проблемой. Не существует абсолютно достоверной конструкторской документации, увы. А тут такое везение! Текст программы явялется конструкторским документом абсолютной точности и достоверности, причём, как правило, самых важных свойств комплекса! Поэтому язык программирования должен по возможности легко читаться человеком. Вот почему я за Паскаль. И против "Си".

Кроме исходников, гостом (еспд) регламентируется еще большая куча документов.
Сюды. (http://www.info-system.ru/tech_doc/tech_doc.html)
В данный момент я милостив и позволяю программистам дышать. А вот конструкторам, мать их... Чуть ПСИ не завалил.

Туды не пойду, ибо ГОСТы и так знаю :).

Я веду речь не о соблюдении ГОСТа, что зачастую просто с маниакальным упорством требуют военные заказчики, а сущность дела. Никакой бумажный документ, по ГОСТу он, или не по ГОСТу, не может обладать той абсолютной достоверностью, которой обладает текст работающей программы. Поэтому текст программы -- это типа "последнее прибежище негодяеев", которые писаные документы неизбежно делают из рук вон плохо. Когда на испытаниях или при эксплуатации сложного комплекса происходит что-то непонятное, то нужно читать текст программы, а не руководство оператора:)

Понимаете меня?

{+}

+

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

>...Вы предпологаете что сделанные Вами ДПЛА будут развиваться тольво Вами или по крайней мере людьми, знакомыми с техналогиями, по которым они создавались

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

Пока не описал ещё, но в течение месяца сделаю.
Название красивое. В течении месяца увидим, не изобретаете ли Вы велосипед. :-)

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

Велосипед я, безусловно, изобретаю. Но это будет мой велосипед. А не выданный мне каким-то Биллом Гейтсом или Торвальдом. Это важно.
А пошаговыми инструкциями можно сделать всё. Главное, правильно управлять сложностью. Ну, сами знаете, структурирование, декомпозиция, стандартизация, унификация...

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

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

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

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

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

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

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

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

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

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

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

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

{+}

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

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

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

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

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

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

разница? Программирование, фигирование... Это только одно из средств решения поставленной задачи. Причем, не всегда оптимальный. На одном старом-старом самолете стоял механический вычислитель астроориентатора и весил чуть больше килограмма. На новом-новом самолете (70-х годов) поставили новую-новую вычислительную машину на 133 серии весом 15кГ. И с глючным ПО. Мне все равно, каким способом решать задачу, я всегда выберу оптимальный - по организационным показателям в том числе. Если у меня в распоряжении будут только программисты, которых так недолюбливает ГК, я предпочту механику. Утрирую, конечно.

Вы правы. Только, увы, сегодня уже не 70е. Такая ЭВМ сегодня весила бы 100 г.
У ГК программистов в распоряжении сейчас нет. Он ими питается:).