Comments 44
Идея интересная. Надо дать школьникам пощупать границы применимости методов.
Компиляция блок-схемы в код на Python, конечно, выглядит как жесть. НО сама идея меня заинтересовала.
Уже есть scratch.
А так, задачи, для которых в далекие 80е придуман Дракон, решаются наличием IDE. А для больших проектов Дракон непригоден чуть более чем полностью. Вот как будет выглядеть diff двух простыней ? Можно ли его приложить к третьей как patch?
У scratch есть ключевой недостаток. А Дракон - это скрепно, державно и лампово. Кроме того, я не согласен, что Дракон, в принципе, не применим...
Ну, в принципе, пристроить конечно можно. Но зачем? Большие проекты успешно пилят без. А кому синтаксис js сложное - может, они дверью ошиблись?
У меня ниша узкая - проекты школьников. Там он будет к месту. А дальше... Кто вообще знает, что будет после LLM сингулярности?
Школьникам можно пихать в моск всякую ерунду, конечно. Тут программистская логика не работает;)
Всякая ерунда - scratch. По крайней мере в сравнении с блок-схемами. В том числе и Драконом. Вообще, формирование вербально-логического мышления тема интересная. И пока оно только формируется, тут, действительно, " программистская логика не работает;)" ... И есть разница 7 лет ребенку или 12. В 7 лет ляпать в scratch - самое то. А вот уже 10 лет ИМХО требует более серьезного подхода.
На самом деле я считаю, что LLM там жизненно необходим. Это костыль. и Дракон костыль. Это орудие, которое помогает на определенном этапе мышления, но которое нужно стремиться отбросить.
В промышленной разработке я не вижу ниши для Дракона, потому что он не лаконичен. Всё остальное решается.
В 7 лет ляпать в scratch
Но зачем, Холмс? Зачем оно 7-леткам? Без умения в абстракции, которое вырастет чуть позже, что оно дает? Кривую осанку?
Ну лично я этим не занимаюсь. Именно поэтому scratch и лежит вне моих педагогических интересов. 2 года протестировал и признал негодным. НЕТ, конечно, в 12 лет тоже можно делать проект на scratch. НО это дауншифтинг, ИМХО.
А так есть масса клубов которые обучают с 1 класса. Пока у родителей есть социальный заказ - его будут отрабатывать.
Спасибо! Я добавил в статью еще один способ применения с ИИ и он кажется более перспективным.
А где про ИИ, я ни слова не увидел?!
Основная идея, используем ДРАКОН -> JSON -> Промпт для LLM
В конце статьи добавил еще один вариант применения с ИИ.
Так и надо писать Дракон+LLM или Дракон+нейронная сеть, но не Дракон+ИИ. Где слова про разум, про интеллект, про "свободу мысли" или желаний ИИ?!
Не обращай внимания. Это местный помешанный, который орёт про "ЭТОТ ВАШ ИИ НЕНАСТОЯЩИЙ" в каждом посте.
Ну и про то, что у него есть НАСТОЯЩИЙ ИИ. Но никому он его не покажет.
Могли бы пояснить, почему именно дракон-схемы решили конвертировать, а не стандартные блок схемы? Не очень понятно, чем они нагляднее и понятнее и как именно метод такой визуальной организации информации может снизить вероятность ошибки по сравнению с блок-схемой, например, если человек, допустим, просто не мыслит системно и не разбирается в предметной области по которой составляет схему?
Раньше по коду рисовали блок-схему, а теперь ИИ по блок-схеме пишет код. Прогресс свернул не туда :-D
Погодите-погодите. Это кто это раньше рисовал блок схему по коду? Это называется reverse engineering. В нормальных учебных заведениях учат сначала составлять алгоритм в виде блок схемы (пусть то на бумаге или в голове), а затем писать код. Многие умельцы делали это наоборот, но в таком виде это не имеет смысла, разве что для того чтобы написать отчёт. Но концептуально блок схема всегда первична, и уже из неё пишется код. И правильность логики также проверяется на блок схеме.
Так что прогресс свернул очень даже туда! Отдавая процесс написания кода в руки ИИ, следует вспомнить незаслуженно забытые блок схемы, как абстрактный и пригодный именно для человека формат описания алгоритмов и логики. Недаром визуальное представление всё чаще всплывает в современных системах, особенно для workflows и автоматизаций.
Скажу честно, блок-схемы это совсем уж... Они подходят только для очень простого (мало ветвистого) кода и только когда у вас императивный язык и нет многопоточности, асинхронной обработки, всяких там Continuation, yield, анонимных методов, переданных в качестве параметра другого метода и т.д. Современный код исполняется сложнее, чем можно отразить на блок схеме.
Как и документирование, можно описывать всё, можно не описывать, зависит от установок и подхода. В Алгоритмах так же, можно сделать принципиальную схему, вложенные блоки ДРАКОН это поддерживает, LLM тоже поймут, думаю. Всё можно описать блок-схемами. Нужно-ли, это вопрос.
Я обновил статью, дописал вариант когда связку «ДРАКОН -> JSON -> Промпт для LLM» можно использовать повторно — для управления системными промптами LLM и мне кажется, в таком виде это более перспективно.
Для языка, претендующего как инструмент общего назначения, самый лучший тест - это написать компилятор/интерпретатор Дракона на самом Драконе. Так называемые Self-Hosting языки. Тем более что здесь первично фактически абстрактное синтаксическое дерево (JSON для этого мало подходит из-за проблемы циклических ссылок) и алгоритм. Скорее для обучения ИИ больше подойдёт описание проверяемой последовательности действий или непосредственно абстрактного синтаксического дерева.
LLM, условно, понимают циклические ссылки, а «дерево решений» как-раз не предусматривает их, использовать циклы или нет, придется решить для себя на практике общения с LLM. Но и не обязательно использовать «схемы», в ДРАКОН есть «Карта мыслей», ее можно использовать как дерево решений для ИИ. В статье я больше хотел показать сам смысл перевода визуального представления на более понятный для LLM язык.
Для Linux систем в своё время упаковал drakon в snap. Если не являетесь хейтером snap, то welcome
Много, слишком много вопросов:
Почему ДРАКОН, а не любой другой способ записи алгоритмов: UML, BPMN, EPC, "тысячи их"?
Зачем отдавать схему "ненадежному" ИИ, когда есть специализированные решения для конвертации диаграмм в код?
Ну и зачем было "рисовать" на зыке описания алгоритмов структуру документа, для которой нужен язык разметки?
Ох...
когда есть специализированные решения для конвертации диаграмм в код?
в JS - какие?
Я дополнил статью, в дополнении, наверное, родилось более красивое решение для ДРАКОН с ИИ. Я хотел показать ход мысли, а как использовать каждый сам решит. «Зачем рисовать» — это именно для того, чтобы показать, что можно применять в разных вариантах, не обязательно для программирования, в подписи к картинке я написал «Как К2 видит предыдущую схему, хотя она алгоритмически не совсем верна, ИИ нормально понял задачу», т.е. это просто вариант применения, не совсем правильный, но возможный.
ДРАКОН — визуальный язык
Дракон - не язык. Это максимум нотация или стайлгайд для блок-схем. Ну или покажите мне программу или описание процесса на драконе, но не используя любой другой язык, как естественный, так и программирования.
Его разработали для задач высокой ответственности, где ошибка недопустима.
Но дракон, сам по себе, не гарантирует от ошибок. Как он защищает, например, от деления на ноль или от взаимоблокировки двух процессов?
Для примера я возьму простую задачу, понятную всем
А возьмите другой пример, скажем, из JavaScript с асинхронностью, промисами (обещаниями) и каллбэками. Как будет выглядеть для него схема на драконе?
пример
function foo() {
const promise = new Promise((resolve, reject) => {
setTimeout(
() => { reject(new Error('Time is out!')); },
1000,
);
});
promise
.then(
(result) => { alert(`Fulfilled: ${result}`); },
(error) => { alert(`Rejected: ${error.message}`); },
);
alert('Timer is armed');
}
Дракон - не язык.
Дружелю́бный ру́сский алгоритми́ческий язы́к, кото́рый обеспе́чивает нагля́дность (сокр. ДРАКОН), так его назвали разработчики 🤷♂️
Как он защищает
Естественно — никак, с его помощью вы можете попробовать создать алгоритм и учесть ошибки
Как будет выглядеть для него схема на драконе?
Она не поддается алгоритмированию? )))
так его назвали разработчики
Какая буква в акрониме "ДРАКОН" соответствует слову "язык"?
Естественно — никак
Ну, тут либо "где ошибка недопустима", либо "никак не защищает". Что-то одно явно лишнее.
Она не поддается алгоритмированию?
В драконе нет средств для описания каллбэк-функций и асинхронности. Если есть - покажите.
Значит дракон пригоден для того js, что был в ходу в 2000 году.
Думаю, callbacks в JS были с самого его рождения. Это ж базовая фича. Потом просто новый синтаксис придумали для них. Так что, даже старый js до 2000 года уже не ясно, как нарисовать в Драконе.
Edit: Даже в вездесущем С можно передавать в функцию callbacks (ссылки на функцию) изначально. Так что, выходит некоторые программы С 70х-80х(к примеру, те же WinAPI приложения на чистом С) в Драконе не понятно как делать.
Ну, собственно, это одна из проблем дракона. Он с момента своего создания не развивался и застыл в эпохе однопоточных синхронных приложений.
del
Интересные идеи! Я правильно понимаю, что для большого проекта, или проекта где несколько асинхронных задач, лучше описать его "верхнеуровнево" в одной диаграмме, а для отдельных блоков/частей/подсистем будут свои диаграммы? И тогда можно каждую часть и человеку наглядно представить, и сетке хватит токенов. Единственное тогда, надо прописать и формат обмена данными между частями. Верно?
Вспоминаю вайб-кодеров, которых слушал на конференциях, у них главная проблема, насколько я их понял, именно что ширины контекста со временем не хватает. Для человека тоже важно работать с маленькими и наглядными схемами.
Да, можно организовать вложенность, в ДРАКОН-схемах есть ссылки на другие схемы и всё это можно обрабатывать частями. Мне кажется, если в верхнем уровне разделить логику на практически независимые блоки, описав данные на входе и выходе, процесс можно сделать независимым от глобального контекста и тогда оно влезет. Но, конечно, ДРАКОН не очень хорошо предназначен для большого, было бы здорово, если бы в каждом блоке можно было сразу проводить отдельное обсуждение с LLM. Статья, скорее пример того как визуальное представление можно передавать в LLM структурированно, мне кажется, что в будущем родится подобное решение, его уже сейчас показывают в фантастических фильмах: программист крутит голографическую блок-схему постепенно углубляясь в нужную часть процесса, на любом уровне видны подробности текущего узла (можно обсудить его логику с LLM), но это что-то про «Нью-Васюки», пока, имхо
Я вышел на эту статью, когда отправился на поиски подхода, который бы обеспечил мне ускорение в формализации идеи того, что я сейчас собираюсь делать, и использовать эту формализацию как для представления этой идеи заказчику, так и LLM для ускорения разработки. Я не работал с подобными языками, поэтому остановился пока на своём более старом подходе - я обычно расписываю в виде пунктов и вложенных подпунктов, что я хочу сделать. Это получилось относительно быстро. Я попробовал визуальный редактор, почувствовал что потрачу больше времени на рисование. Но опять же - эта штука новая для меня.
Ещё пару мыслей подкину.
Я обсудил эту статью, мой друг считает, что у нейронки будут трудности с переходом от более высокого уровня абстракции (алгоритма) к более низкой (коду), потому что уровнями абстракции они не владеют, а материалов, связанных с алгоритмами, они видели не так много (обычно тексты содержат код и хорошо есть что он делает).
Спросил параллельно у дипсика, как использовать диаграммы для визуализации асинхронной логики. Он предложил собственный вариант на mermaid, а когда я его направил к существующим решениям, он подсказал сети Петри, диаграммы потоков данных, Асинхронные списки, Архитектурные шаблоны (Async Request-Reply).
Было бы интересно у вас почитать о том, как вы сокращаете время на разработку и/или уменьшаете число ошибок, итераций переделывания/рефакторинга при помощи подходов к формализации и об опыте использования в этом деле ИИ (формировании кода, да и формализовывать он может поможет).
Прорисовка схем, всё же, наверное, имеет смысл для повторно используемых инструкций для LLM, для вайбкодинга выходит муторно перестраивать схему и заново полностью скармливать ее, т.е. у нас разрывается связь диалога и схемы. А вот написать промпт в для циклического использования может быть полезно.
Я не работал с подобными языками, поэтому остановился пока на своём более старом подходе - я обычно расписываю в виде пунктов и вложенных подпунктов, что я хочу сделать.
Тоже любите деревья? Поробуйте мой конструктор, там всё на деревьях https://botpad.ru/ может пригодится где )
Можете повторить предложенным Вами "драконовским" методом мой пример исполняемого BPM "Hello Calculator": нарисовали схему действий "Схема процесса HelloCalculator", получили код (лучше JS) и запустили приложение (в браузере). Желательно - как в примере - все в облаке (чтобы повторить было проще).
ДРАКОН + ИИ: быстрый путь от идеи до работающего кода