Наверное, ветка всё-таки не о конкретном редакторе...
Отсюда такие замечания.
1. В доступных (на разных коммерческих условиях) средах, включающих реализацию техноязыка, пока недостаточно таких возможностей:
* смена языков по принципу "переключения синтаксиса содержимого схем";
* работа с сущностями как словарными единицами;
* использование в документах также базового набора автофигур, располагаемых произвольно.
Первые две показаны в
этом ролике, а обсуждены здесь:
viewtopic.php?p=76731#p76731.
Замечу, что <Ctrl-F> у Митькина - это тоже неплохо, когда проходит по всему документу (проекту как связке схем). Но надо именно поддерживать имена как сущности модельной БД. Чтобы можно было заменить имя и разом в заданной области... не отдавая многократно команду типа "Найти следующее <вхождение>"...
Насчёт того, зачем нужно второе, также говорится
здесь (прежде всего Info21 и SergeyNK, разумеется
).
Третье было сделано уже в
этой среде. Работал бы в ней... если бы поддерживалась полноценная работа с текстом, о которой и Сергей говорит...
Надо и организовать данные, содержащиеся в документе... имея в виду, что какие-то из них образуют программу (вместе с её спецификацией), а какие-то самостоятельны (общие вопросы, результаты допрограммной разработки задачи).
2. Есть и базовые вопросы по целям, в первую очередь "что для чего". Например, такие:
igor писал(а):
Комментарий не должен нести никакой смысловой нагрузки. Видимо, поэтому Вы такое решение обозначили как временное ("на первых порах").
Именно. Это было временным решением.
igor писал(а):
Далее, в качестве развития идеи Вы предлагаете для описания декларативной части использовать табличные формы. Это работает, но это уже не ДРАКОН!
Ну, не совсем не ДРАКОН. ДРАКОН там всё-же останется, в императивной части модуля.
igor писал(а):
Программирование - это не только программная логика, но и сложные структуры данных. Как там у Вирта? "Программы = алгоритмы + данные". Правда, однако, очень проста: в ДРАКОНЕ не было и нет средств для описания (или рисования) декларативной части, и ничего не предлагается в замен.
Есть ещё другая вполне жизненная идея.
Представьте, что у Вас есть обычный модуль на любом языке программирования. В модуле традиционным способом описаны различные типы данных, реализованы какие-то процедуры... И где-то в тексте в закоментированном блоке находится ДРАКОН-схема в компактном текстовом представлении (XML, JSON). В IDE естественно должен быть установлен плагин, "понимающий", что в подобных закоментированных блоках хранятся ДРАКОН-схемы. Плагин должен обеспечивать возможность просмотра, редактирования этих "вшитых" ДРАКОН-схем и обеспечивать генерацию из них исходного кода. т.е. схему открыли, подредактировали, закрыли и автоматически под блоком коментария получили обновлённый код процедуры. ...
PS. ДРАКОН полезен в первую очередь для сложных алгоритмов, для мелких процедур использовать его не имеет никакого смысла.
Итак:
* а для чего схемы маршрутов деятельности, если принятый порядок проектирования деятельности предполагает её декомпозицию на "мелкие процедуры" (где маршрутная часть тривиальна)?
* жизненная идея может означать снова отрыв разработки от документирования. Т.е. усложнение работы "сочинителей". Позиция Сергея (иметь сменные виды одного описания, а не редактировать отдельно описание "традиционным способом" и отдельно в виде "компактных представлений") эргономична.
* да, у Вирта (и не только) так... и даже точнее + "систематическое представление об исполнителе". И нужен базис языков, отражающий всё это как целостные модели программ/инструкций;
* в отношении "литературного программирования" Сергей, как можно понять, близок к "помощи писателю" С.Е. Михайлова.
Пример программы из "мелких процедур" - гетерогенная очередь у Свердлова. Илья также указывал, что предпочитает доводить проекты до такой гранулярности процедур.
Для чего в этом случае схемы маршрутов? Для представления именно работы программы как целого, как общего описания "поведения исполнителя". Обсуждалось в
этой теме. Как пример техноязыкового решения - Z-язык, предложенный Паронджановым (решение частное, т.к. предполагает детерминацию порядка работ до "циклограммы", но важное, ибо для гарантоспособности часто надо к этому стремиться).
3. Общие проблемы реализации, в очередной раз обозначены, например, тут:
Так я ж не говорю о том, чтобы преобразовывать произвольный текст на произвольном языке в ДРАКОН-схему.
Я говорю о том, чтобы эквивалентный ДРАКОН-схеме текст, использующий текстовые ДРАКОН-операторы, сделать первичным документом и на его основе строить схему. Исходником сделать текст, конечный результат "неживая" картинка. При необходимости тот же текст можно преобразовывать в программу на конкретном языке программирования. Один и тот же текст, двумя разными преобразованиями.
...
Если нужно преобразование в программу на каком-то конкретном языке программирования, то потребуется явно определять преобразование операторов из текстовых ДРАКОН-операторов в операторы конкретного языка, это понятно.
Думаю, формат исходника (документа среды) - описание на некоем метаязыке. Из которого получаются виды для разных элементов структуры документа (и документа в целом), переключаемые командами оператора.
Возможны некоторые направления, "как":
* формат документа вырабатывает и группа Лаптева: viewtopic.php?p=63995#p63995;
* "интеграция с сетями" уже была реализована Михайловым: http://citycat.ru/iq/ti/ - кстати, программа открытая. Возможно, если формат файла можно обрабатывать, то и программу можно использовать как внешнее приложение для среды;
* вид структуры документа может учитывать обсуждавшееся в этой теме. Т.е. от "батарей запоминателей" - к "синтаксическому силуэту";
* чтобы получать из документа программу целиком - надо и модель её в среде поддерживать целостную. Где представлена структура не только для маршрутов. Тогда и схемы можно получать не только для них.
Опорный пример - модель задачи, представленная в
этой работе. Правим её[ элементы] хоть в текстовом представлении, хоть в табличном, хоть в схемном... а результат всё одно должен сохраняться в файл проекта... И более одного раза описание
любого места в
одной и той же редакции не делается. В работе вопрос организации документа в целом остаётся открытым.
Пока представляется маловероятным, что какую-то из доступных реализаций "прежде всего техноязыка" можно развить в этих направлениях... Возможно, Ярослав потому и говорит снова о своём редакторе. Вот что будет у Эдуарда?..