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