Знаете, Илья, не знаю, что вам написали в ЛС, но полагаю, попытку защитить текст программы как литературный текст. Во всяком случае, если бы я писал по этому поводу до вашего вчерашнего сообщениия, я бы тоже написал нечто подобное.
Но я воздерживался от такой постановки вопроса, поскольку никак не мог понять вашу позицию, хоть и вроде инженер по образованию. А если не могу понять, то и писать не стану.
Но вчерашнее ваше, спонтанное, в общем-то, сообщение заставило меня серьезно задуматься. И я понял, чего я в ваших словах не понимал (простите за каламбур).
Те программисты, которых я знаю, включая меня, о том, что архитектура программной системы
существует наслышаны, но как к ней подходить, с какими мерками, с какими инструментами - толком не знает никто. Все, чему нас учили (мы учились, как вариант) - это умение так скомбинировать операторы, чтобы получился результат, более-менее соответствующий постановке задачи.
А комбинирование это происходит на уровне "атомарных" операций, т.е. операций, как правило библиотечных, которые заведомо где-то прописано. В редких случаях собирается своя библиотека, которая в этот смысле тоже становится вместилищем "атомарных" операций. Беру в кавычки, поскольку это понятие [мне] еще предстоит обдумать; про Дейкстру я написал не в шутку.
С этой позиции программист далее своего текста ничего не видит, а потому никаких других требований, кроме, пожалуй, эстетики и субъективной "понятности" не предъявляет.
Предъявление же требования некоторой структурной целостности (вроде одного RETURN или цепочки IF...ELSIF...END), зачастую даже не приходит в голову в силу отсутствия вообще какого-либо навыка в этой области.
Поэтому возникает естественная защитная (профессиональная!) реакция недоверия к сказанному, поскольку это выталкивает человека за пределы его круга познания (тут я наверное переборщил с формулировками
)
Сессия не позволяет подумать над этими вещами основательно, но скажу, что текущее обсуждение уже сейчас позволяет сделать несколько выводов:
- архитектура системы выражается тем же текстом, что и конкретные действия в программе, но имеет совершенно другой смысл.
- Оберон(ы) имеют некоторое преимущество в архитектурном смысле благодаря синтаксической конструкции модуля, но это не значит, что подобная техника не может использоваться в других языках. В этом смысле ошибок можно наделать и на Обероне, и на С++
- ДРАКОН более других способов выражения программистской мысли способствует архитектурным решениям, чем традиционные языки, благодаря более четкому разделению "модулей" в широком смысле этого слова.
Последнее высказывание требует дополнительного анализа, но представляется разумным.