Владимир, здравствуйте.
Мне на самом деле лестно получить Ваше письмо, особенно если учесть что два года назад я осознал, что полностью реализовать задуманное в одиночку я не потяну, и поэтому отложил проект в “долгий ящик”.
КАРТИНКИ ГРЯДУЩЕГОДавайте я сейчас попробую в письме изложить картинки грядущего, которые есть в моей голове.
Если это будет каким–то образом согласовываться с Вашим собственным виденьем развития ДРАКОНа, тогда я буду чувствовать себя вправе искать поддержки и сотрудничества в сообществе, собравшемся вокруг Вас и Ваших идей.
Итак, мне бы хотелось видеть ДРАКОН в качестве некоей lingua franca для прототипирования алгоритмов и реализаций протоколов.
ЧТО ЭТО ПОДРАЗУМЕВАЕТ? ДРАКОНу нужно какое–то ещё выражение, кроме графического, такое, которое легко интегрируется в имеющиеся промышленные toolchains и инструментарий разработки.
Давайте я с позиций своего опыта постараюсь прикинуть, что именно это должны быть за требования к формату:
Требование 1. ОТКРЫТЫЙ ФОРМАТВо–первых, этот формат должен быть открытым, целиком описанным и публично доступным без отчислений — нет нужды объяснять почему, мне кажется.
Требование 2. ТЕКСТОВЫЙ ФОРМАТВо–вторых, этот формат должен быть текстовым — то есть не бинарным. Это позволит гораздо легче вписывать его в имеющиеся инфраструктуры программирования и сборки программных компонент — они за малым исключением построены на преобразованиях именно текстовых данных.
Требование 3. ЧЕЛОВЕКОЧИТАЕМЫЙ ФОРМАТВ–третьих, этот формат должен быть человекочитаемым — то есть допускать его генерацию и редактирование “руками”, а не средствами программы–транслятора из графического представления.
Требование 4. ВЗАИМООДНОЗНАЧНОЕ СООТВЕТСТВИЕВ–четвёртых, он должен предполагать взаимооднозначное соответствие графическому представлению ДРАКОНа, то есть допускать не только сериализацию в него ДРАКОНограммы, но и из этой ДРАКОНограммы полностью эквивалентное воссоздание из сериализированного представления.
Требование 5. СТАНДАРТНЫЙ ФОРМАТВ–пятых, этот формат разумно делать на основе имеющихся стандартных текстовых форматов. Это обеспечит простоту интеграции нашего формата с другими программными компонентами — благо всякого рода парсеры и объектные представления можно будет задействовать имеющиеся.
Комментарий 1. ТОЖДЕСТВЕННОЕ ПРЕДСТАВЛЕНИЕЕщё раз отмечу, что я здесь описываю требования к стандартизации ещё одного тождественного представления имеющихся диаграмм ДРАКОНа, то есть просто способа записывать диаграммы во втором, не графичном, виде.
Никаких изменений и дополнений самой графической формы записи, естественно, не предполагается, и четвёртый пункт явно требует однозначное соответствие этого расширения языка оригинальному ДРАКОНу.
Если разработать такой стандарт и реализовать к нему “образцово–показательную” реализацию, ДРАКОНом практически сразу же можно будет автоматизировать многие программистские–задачи–для–непрограммистов.
Комментарий 2. ТРИ СЛОЯ По сути, это позволит легко разделить реализацию ДРАКОНа на три слоя независимых компонент:
— визуальные редакторы графического представления ДРАКОНограмм, как общего назначения, так и специфические/встроенные;
— текстовый формат для унифицированного сохранения на диск, передачи по сети и сохранения в БД этих схем;
— и наконец прослойка трансляторов, выполняющая полезное действие на основе этих единообразных и стандартизированных текстовых записей.
ПРИМЕРЫПримерами последних могут служить:
— трансляторы ДРАКОНа в программы на других языках программирования,
— проблемно–специфичные исполнители ДРАКОНограмм (наподобие макросов VisualBasic в Microsoft Office),
— разного рода инструментарий для тестирования и проверки корректности визуально созданных диаграмм.
АДАПТАЦИЯ К НУЖДАМ ПОЛЬЗОВАТЕЛЕЙРазведя эти слои абстракции, мы позволим любому желающему с минимальными затратами и при помощи готовых компонентов свободного ПО добавить поддержку ДРАКОНа в свой продукт, адаптировав его к собственным нуждам без потери совместимости со всей остальной экосистемой.
Естественно, я верю что это позволит резко увеличить пользовательскую базу и востребованность ДРАКОНа и связанной с ним софтовой экосистемы.
ИТОГВ итоге, мне кажется, я смог продумать формат, который бы удовлетворял этим требованиям.
Мне, естественно нужна сторонняя экспертиза для того, чтобы проверить соответствие моей имплементации пяти изначальным тезисам–постулатам.
Собственно, я и прекратил работу именно осознав, что в одиночку я имею дело с парадоксом наподобие любительской криптографии — абсолютно любой человек может создать шифр, который он сам не сможет взломать; подобный шифр не будет от этого являться хоть сколько–нибудь надёжным.
НУЖНА ПОДДЕРЖКА СООБЩЕСТВАЕсли я получу валидацию и поддержку сообщества, я готов:
— залатать обнаруженные дыры в спецификации
— и в кооперации с другими энтузиастами спроектировать и реализовать “образцово–показательную” реализацию для всех трёх слоёв.
(Благо я надеюсь, что опыт именно проектирования конкретных программных решений и реализаций позволит мне не допустить ошибок на этой стадии. Другое дело, что для одиночки с собственным бизнесом по 14 часов в день этот проект растянется на годы...)
ПРОТОТИП И ПОПЫТКАПрототип такой записи для одной из схем Вашего авторства можно посмотреть здесь:
https://github.com/kirushik/libtougarin ... ample.jsonБрошенную на середине попытку формализованной записи каждого из узлов — здесь:
https://github.com/kirushik/libtougarin ... 0%BE%D0%B2ВОПРОСКак Вы считаете, это то направление, в котором Вам хотелось бы двигать ДРАКОН? Сообщество небольшое, естественно я считаю необходимым получить Ваше одобрение, прежде чем отвлекать на эту достаточно амбициозную задачу часть коллективных усилий.
Вход
FAQ
Поиск
