OberonCore

У Кнута изначально был использован язык Паскаль.

Но его программистские предрассудки сложились еще до Паскаля.

Не могу согласиться. Нужно комментировать именно те элементы структуры, которых в синтаксисе языка нет: они заданы неявно, а комментарий помогает понять их быстро и снижает ошибочность восприятия. Ну и комментировать, конечно, семантику. Может, Вы всё-таки имели в виду именно это?

Комментировать нужно прежде всего смысл: зачем? Во вторую очередь способ: как? (Особенно крайние случаи: предусловия, постусловия.) Далее причины: почему именно так? В последнюю очередь: что делается? Это должно быть ясно из самого текста, если язык программирования читабельный. Сюда же инварианты.

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

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

Возможно, имеются в виду такие метаконструкты как паттерны проектирования (MVC, CRM и т.п.). Они имеют свойство быть "размазанными" по модулям, объектам и процедурам, но дают достаточно чёткий и связный смысл происходящего, если их иметь в виду при чтении. Следовательно, надо где-то их задокументировать.

Хочется отнести пред- и пост-условия к "зачем".

Но по степени критичности инварианты я бы гораздо раньше поставил. Вместе с пред- и пост- в самое начало.
Инварианты, например, объектов -- существенная часть прочих объяснений, того же зачем.

Про паттерн CRM я ничего не знаю, в отличие от Customer Relationship Management.

Что касается паттерна MVC, то в моем понимании это просто выделение специализированных модулей, играющих три разные роли: ввод данных в систему пользователем (C), хранение и обеспечение целостности введенных данных (M) и отображение данных для пользователя (V) - с целью повышения гибкости и надежности программы. То есть, речь идет о модулях, к которым можно делать комментарии. В семантическом редакторе роли модулей могут явным образом указываться и зрительно выделяться (например, цветом значка или обозначением типа в таблице) - без необходимости делать текстовые комментарии о ролях модулей.

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

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

Вот очень нужны способы фиксировать такие связи в системе.

В традиционной текстовой программе, конечно, динамические связи прилепить некуда. Просто вместо текста нужен мощный GUI, например, https://sites.google.com/site/purebuilder/#TOC-11 . Щелкаешь по линии, изображающей связь, - и специфицируй себе, сколько хочешь. А существующие связи должны отображаться автоматически.

Вот у меня есть группа динамических объектов в куче, каким-то образом связанных и взаимодействующих. Между чем же будет устанавливать связи редактор? Редактор даже не может знать, куда же ведёт виртуальный вызов obj.Method, ибо это будет зависеть от динамического типа obj во время выполнения программы.

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

Есть пара предпосылок:
1. "отмазка":

по аналогии с тройкой "синтаксис - абстрактный синтаксис - метаиодель". Можно посмотреть на подстановки в obj.Method как на операции, заданные определённым синтаксисом, который может находиться в рамках "некоего DSL". В рамках метамодели которого можно проверить правильность используемых подстановок или сгенерить все возможные подстановки. Но семантику процесса этот метод не покроет.

2. "костыль":

динамические связи маршрута выполнения алгоритма можно отобразить на статические связи по данным. Проще говоря - можно попытаться сопоставить подстановкам obj.Method некий набор состояний и правил перехода между ними. В декларативной области. Сейчас модно использовать TGG(triple graph grammars) для установления и анализа подобных соответствий.

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

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

Что касается "системы ... правил", то ведь существуют декларативные языки, таблицы истинности и проч. Почему бы этим не воспользоваться?

Пока нет, но ищу. Ближе всего к этому n-диагональные схемы.

Google такого не знает. Можете прислать ссылку или описание или рисунок?

Пардон, n-прямоугольные схемы.
Описаны у Басса-Клементса-Кацмана, с. 239.

viewtopic.php?p=53725#p53725

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

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

Я где-то читал про такую матрицу, что интенсивность межмодульных связей обозначается цветом с целью выделения укрупненных модулей (подсистем) с минимальным обменом данных между собой. Вообще же такие таблицы (оба варианта) в качестве GUI семантического редактора неудачны, так как очень громоздки, и к ним никак не применить фолдинг (разве что прокрутку для матрицы). Гораздо удобнее граф (например, полный граф) или квадратная матрица, отображающая лишь связи модулей (без демонстрации данных), и дополнительная таблица, отображающая состав данных, соответствующих выделенной связи. Может быть и еще одна таблица - с характеристиками модулей.

А как n-прямоугольные схемы используете Вы?

Да, недостатки Вы правильно отметили.

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

Конечно, на безрыбье и рак - рыба. Можно и Excel'евской табличкой обойтись, и отслеживать все связи вручную. Но это трудоемко и чревато ошибками.

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

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