Выделено из
этого поста как топик скорее для данной темы.
В исходном посте остановился на последствиях "технического универсализма", проявленного при использовании ГНОМа в Ты-среде. Более общо о возможных эффектах "наивного" подхода к разработке сложных, "кризисных" программируемых систем говорил здесь:
viewtopic.php?p=53467#p53467.
В то же время кое-что из сказанного о Ты-среде:
Вариант 1. Мы не поддерживаем механизм пользовательских транзакций и требуем согласованного состояния системы после каждого атомарного действия. Работать с подобной системой не то что некомфортно, а неэргономично до полной невозможности. По этому пути, увы, идёт Тышов.
Вариант 2. Мы разрешаем любые разумные действия (вырезка, перемещение любых участков схемы, произвольное проведение связей) внутри пользовательской транзакции редактирования.
Однако при таком подходе необходимо явное завершение транзакции с автоматическим контролем корректности состояния и исправлением ошибок.
я бы воспринимал не столь критически - в свете, допустим, этого заявления:
...основное требование - прозрачность свойств составленной конструкции. И изучать цикл должен не в порядке выполнения его машиной, а с помощью инструмента логических рассуждений (начать с того, что построен он должен быть посредством таких рассуждений, а не путём постепенного подбора команд). Основной смысл цикла -это его цель, в какое конечное состояние он должен привести (какое постусловие обеспечить). В состояние из каких возможных классов (например, у поиска два или более исхода: не нашли, нашли А, нашли Б… И т.п.) Действия же, которые в цикле происходят - это отнюдь не его смысл, а «грязная работа» по продвижению от начального состояния к целевому. Чем проще эти внутренние действия, тем лучше. И уж конечно, они не должны содержать вперемешку ещё и принятие решений о том, достигнута цель или нет.
Тышов идёт по пути шампур-метода, и пока не введена иная математика шампур-схем, гарантирующая правильность их "либерал-вывода" (напр., то, о чём Илья же говорил) - он прав. Однако лишь с позиций "наивного" сочинения маршрутов деятельности.
Если же мы становимся на инженерные позиции - то ввод атомов должен давать любые конструкции (структуры маршрутов). Операции же с лианами исключаются. А значит, вообще трудоёмкость построения схем не слишком высока - в основном сводится к заполнению вертикалей лин-вершинами. Поскольку предварительно выводится логика условий - то и "матрёшки" определяются. Перемещать можно шампур-блоки - что и реализовано. И циклы определяются заранее (в частности, многое должно делаться через ЦД).Временный (переходный к инженерному) путь - пересадка же лиан исключается, а заземление ограничивается. Думаю, что это стоит допустить только в диалекте ДРАКОН-Родной, а начиная уже с ДРАКОН-Алго (как находящегося на более высоком уровне формализованности) запретить.
В принципе сторонники доказательного программирования могут посоветовать вообще отказаться от "шампур-садоводства", т.е. не только от пересадок, но и от заземлений лиан. Однако уже сочинено (и ещё будет сочиняться в "наивных" редакторах) много схем с лианными структурами. Т.е. имеем "унаследованный код", с которым надо что-то делать при переходе к инженерии.
В свете теоретических результатов можно сказать следующее. С одной стороны, Рэйлвей Каген и Дмитрий_ВБ показали, что представление дракон-силуэта разными матемформализмами не вызывает проблем (в отличие от схем, где допустимы не только силуэтно-разрешённые БП). С другой - есть возможность преобразовать силуэт в СЦД, "спрятав" Р-БП внутри СЦД-ветвей за счёт присваиваний номера следующей ветви переменной Имя Ветви и использовать для прогтекстового представления обычные ТЯП, включающие цикл Дейкстры. И тем самым переводить код "унаследованный" от шампур-силуэта, в "квазидоказательную форму".
Вот для изначально доказательной разработки нужно пользоваться только атомарными структурами - как и предлагалось в этой теме:
viewtopic.php?f=78&t=2919. Т.е. практиковать только базис-метод в терминах отсюда:
http://grafit-basis.narod.ru/L3/grafit- ... l#GR-n1411.
Время первых успехов в визуализации знаний, считаю, прошло. Итог этому этапу подвели доработанная по минимальным эргономическим требованиям Ты-среда, ДРОН и работы С. Тарасенко по "ресторации" Ты-среды и особенно - дракон-конверсии; в теоретическом плане - также работа Рэйлвей Каген по представлению шампур-схем S-выражениями (ПРОТОН). Показано, что можно создать дракон-среду как общедоступное и развиваемое приложение - это, считаю, уже много. Предварительно решена задача трансляции в исходный текст - но разными разработчиками со своими ограничениями. Кроме того, все основные результаты развития касались интерфейса - но не языков визуализации и не их машинного представления.
Со своей стороны Дмитрий_ВБ по ходу развития этой темы предложил идеи, которые позволят перейти к следующему этапу; речь идёт о текстовом представлении схем, которое я назвал ТФРД, позволяющем и хранить необходимые данные для отрисовки содержимого документа, и генерировать не шаблоны исходного текста для последующей доработки, а исходный прогтекст на конкретном ТЯП. Предлагается также "человекочитаемость" самого текстового представления (т.е. файла проектного документа).
По-видимому, предложение Дмитрия имеет потенциал эволюционного развития. Поэтому и не обсуждаю лишний раз свойств ВЯЗБС - ведь в принципе состав вершин можно переопределять если определены все возможные структурно-топологические типы - вижу два измерения базиса типов - по структуре вершины{одно-/многофигурные}; по топологии её связей{"один вход - один выход"/"один вход - ряд выходов"(разветвители)/"ряд входов - один выход"(соединители)/"ряд входов - ряд выходов"(области)} - кстати, подобный принцип, видимо, и Станислав заложил при определении
в этой теме языков для конверсии. Это не значит, что я отдаю предпочтение эволюционному пути перед революционным
... но кто сегодня сможет "революционизировать", допустим, Ты-среду по указанным направлениям?...
Цель объективно наступающего этапа - стандарт описания процессов с возможностью детализации до программно строгого через семейство граф-языков, воплощённый в расширяемое новыми языками текстовое представление инфордокумента и работающий с этим представлением редактор-транслятор на языки исходного текста (РДП-редактор).
Эти языки д.б. такими, чтобы сопрягать РДП-редактор по данным со внешними приложениями - как с промышленным ТЯП-компилятором, так и с системой верификации описаний (подчеркну ещё раз - на основе автоматически генерируемых входных файлов для этих приложений и автоматического же чтения их выходных файлов с соответствующим обновлением проекта - человек должен заниматься максимально содержательным трудом, а не кросс-техоперациями). Тогда можно построить технологию инженерной разработки процессов (с выделением по усмотрению сочинителей их элементов для программной реализации по принципу "дракон-руководства" - т.е. формируя и визуальные инструкции по применению программно-аппаратных комплексов, образующихся как результат такой реализации).
Критика по возможности д.б. конструктивной (по крайней мере такая, как я считаю, достаточно резкая). Что же предлагается взамен? Комплекс специализированных языков, основанных на шампур-методе, с одной стороны и учитывающих текстовую составляющую - с другой. Основные идеи базового (т.е. реализующего визуализацию обобщённого уровня) языка лист-силуэтов фактически изложены выше при разборе ГНОМа; остальные языки можно найти в
этом разделе.
Минуя возможное самовосхваление, перейду к самокритике
Чего же нехватает на сегодня этому предложению? Ну прежде всего - деклар-языка; здесь ещё нужно работать. Далее, сами описания языков даются на уровне /Паронджанов, 2001/, т.е. качественные - а это следствие того, что я сам во многом нахожусь на качественном уровне понимания формальной визуализации; возможно, в дальнейшем оно углубится - но пытаться сейчас сразу давать математические и информатические формализмы было бы с моей стороны своего рода "ополченством", если я правильно понимаю этот термин
В то же время более глубокого определения, возможно, и не требуется - реализовал же Геннадий Николаевич техноязык по определениям Паронджанова - сапиенти сат, короче. Ну а я из проблем математического уровня разобрал вопрос о преобразовании шампур-силуэта в силуэтный ЦД - поскольку он имеет и насущно-практическое значение в свете стыка с реальным визуальным программированием - и хватит пока 
Главное - чтобы реализация сопровождалась публикацией разработчиком спецификаций и их обсуждением.
Также не рассматриваются вопросы текстового представления; это дело во многом программистов - но как уже отмечал, спецификация текстового формата д.б. согласованной. Не вполне определены общеязыковые требования - должны уточняться по мере определения языков в комплексе. Наконец, в определении дракон-языков для инженерного представления алгоритмической части имеются нестыковки - а это уже следствие различия некоторых механизмов в текстовых языках, выбранных для гибридизации, т.е. лежит за пределами решаемой качественной задачи.
Вход
FAQ
Поиск
