Здравствуйте, MadHuman, Вы писали:

MH>Интересно есть ли уже какие-то онлайн тулы/сервисы, чтоб редактировать, и во что потом преобразуется накликанный алгоритм? javascript? что-то ещё?

1. Инструментальная программа ИС Дракон (автор Геннадий Тышов) по желанию пользователя автоматически преобразует дракон-программу в исходный код любого из 10 целевых языков:
С, Delphi, Java, Lua, PL/SQL, ABAP, Forth, Oberon, 1С, BASCOM.
https://bit.ly/2OOgXgN

2. Инструментальная программа DRAKON Editor (автор Степан Митькин) преобразует дракон-программу в исходный код любого из 13 целевых языков:
Java, Processing, D, C#, C/C++ (with Qt support), Python, Tcl, JavaScript, Lua, Erlang, AutoHotkey, КуМир и Verilog http://sourceforge.net/projects/drakon-editor/files/

3. Инструментальная онлайн-программа Drakon.Tech (автор Степан Митькин) преобразует дракон-программу в исходный код JavaScript
https://drakon.tech

Кроме того, Степан Митькин создал онлайн-программу DrakonHub, не предназначенную для программирования.
https://drakonhub.com/

Она служит для записи на языке ДРАКОН алгоритмических предписаний, бизнес-процессов, workflows, клинических алгоритмов и т.д.

Здравствуйте, Dym On, Вы писали:

DO>Практически любой алгоритм в виде схемы сложнее "Hello world" не влезет в экран. Как правило это будет безумный лес из спагетти линий и разных кватратиков/ромбиков/овальчиков/etc.

Это не так. Никакого леса. Никаких спагетти.

Вам возражает Степан Митькин (Норвегия), разработчик трех программ DRAKON Editor (2011), DrakonHub (2018), Drakon.Tech (2019).

Степан пишет:

<начало цитаты>
Исходный код среды разработки Drakon.Tech выложен на GitHub
https://github.com/stepan-mitkin/drakon.tech

Drakon.Tech написан (нарисован) на языке ДРАКОН в среде
DRAKON Editor

Это к вопросу о том, можно ли на ДРАКОНе создавать большой серьёзный софт.

Публикация исходных текстов проекта Drakon.Tech примечательна в том числе и потому, что показывает, как язык ДРАКОН применяется в практическом программировании.

Любая среда разработки – алгоритмически нагруженная программа. Поэтому язык программирования, на котором написана среда, подвергается особенно суровой проверке.

Выдержал ли ДРАКОН такую проверку? Теперь каждый может это узнать, посмотрев на исходный код Drakon.Tech.

Самое интересное содержится в этих файлах:
https://github.com/stepan-mitkin/drakon.tech/tree/master/static
Lomma.drn – ядро редактора

https://github.com/stepan-mitkin/drakon.tech/tree/master/generator
genserver.drn – генератор кода

Итак, можно ли на драконе создавать большой серьёзный софт?
Можно и нужно!
<конец цитаты>
https://forum.drakon.su/viewtopic.php?p=104451#p104451

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Вам возражает Степан Митькин (Норвегия), разработчик трех программ DRAKON Editor (2011), DrakonHub (2018), Drakon.Tech (2019).
Спасибо за ответ.


ВП>Степан пишет:
ВП>Исходный код среды разработки Drakon.Tech выложен на GitHub
К сожалению оценить исходный код нельзя. Насколько я понял файл drn это просто файл sqlite, т.е. к нему нужен интерфейс. Какой же это исходник?

Этот пример как раз подтверждает, что Дракон узконишевый язык. Среда разработки, кстати, небольшой проект.

Вообще графические языки вполне применяются в промышленности: МЭК 61131-3-2016. Они удобны, когда программирует не программист, а инженер, требования к конечному продукту зафиксированы и каждую программу полностью обслуживает один человек.

LVV>>В том-то и дело, что "безумного леса" не наблюдается из-зы строгих правил Дракона.
DO>Именно из-за строгих правил у Дракона нет и не будет большого будущего в массовой коммерческой разработке. Строго нишевый продукт.
Но ниша — достаточно объемная. Мне москвичи сообщили, что даже в Иркутске интересуются.
LVV>>В Драконе все жестко. И леса не получается.
LVV>>бесконечные схемы (как и всю прогу в одной main()) — никтотне рисует. Рисуют либо прототип, лтибо небольшой силуэт.
LVV>>Малые схемы делают макроиконами и потом эту макроикону вставляют в бОльшую схему.
DO>Чтобы посмотреть вложенную схему нужно провалиться в иконку? А если таких вложений много? В какой-то момент надоест тыкаться и перейдешь на текст.
Ну, а как ты переходишь от вызова функции к определению?
DO>На практике, я встречал обратное — текст преобразуется в схему, на конечном этапе. А работа идет только с текстом. Ну в начале, по-молодости, многие рисуют схемы, потом от схем переходят к тексту и работают с текстом, а потом этап со схемами пропускают.
в мейнстриме — естественно...

DO>Вообще графические языки вполне применяются в промышленности: МЭК 61131-3-2016. Они удобны, когда программирует не программист, а инженер, требования к конечному продукту зафиксированы и каждую программу полностью обслуживает один человек.
Ну, дык а я о чем! И таких "один человек" — дофига и больше.

Здравствуйте, LaptevVV, Вы писали:

LVV>Но ниша — достаточно объемная. Мне москвичи сообщили, что даже в Иркутске интересуются.
Но эта ниша не для коммерческого софта. Большинство таких программ не выходят за пределы организации, где были созданы.

Здравствуйте, Dym On, Вы писали:

DO>Но эта ниша не для коммерческого софта. Большинство таких программ не выходят за пределы организации, где были созданы.

Это не так. Вот пример. На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании «Сургутнефтегаз» и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.

Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.

Подробности по ссылке https://www.youtube.com/watch?v=_XOuhV_8N_I&amp;feature=youtu.be
Разработчик шкафа управления и программы СПК (Сенсорного программируемого контроллера) Алексей Муравицкий — системный интегратор фирмы ОВЕН.

LVV>>Но ниша — достаточно объемная. Мне москвичи сообщили, что даже в Иркутске интересуются.
DO>Но эта ниша не для коммерческого софта. Большинство таких программ не выходят за пределы организации, где были созданы.
А вот нас настойчиво втягивают именно в коммерцию. Контора, для которой делаем, намерена это продавать заинтересованным людям. И они уверены, что спрос будет.

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП>Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
Именно, о чем я и говорил

Автор: Dym On
Дата: 27.07.20

, промышленные контроллеры, ПЛК и т.п. Там Дракон на своем месте.

Здравствуйте, Dym On, Вы писали:

ВП>>Исходный код среды разработки Drakon.Tech выложен на GitHub
DO>К сожалению оценить исходный код нельзя. Насколько я понял файл drn это просто файл sqlite, т.е. к нему нужен интерфейс. Какой же это исходник?

Спасибо за вопрос. Поясняю.

Открытый исходный код (public domain) имеют все три инструментальные программы Степана Митькина.

1. Программа DRAKON Editor имеет открытый исходный код.
http://sourceforge.net/projects/drakon-editor/files/
Это офлайн программа, расширение .drn

2. Исходный код DrakonHub.com выложен на GitHub.
Приложение написано на языках ДРАКОН-JavaScript и ДРАКОН-Lua в среде
DRAKON Editor.
https://github.com/stepan-mitkin/drakonhub
Это онлайн-программа, работает в браузере.

3. Исходный код среды разработки Drakon.Tech выложен на GitHub
https://github.com/stepan-mitkin/drakon.tech

Drakon.Tech написан (нарисован) на языке ДРАКОН в среде DRAKON Editor
Это тоже онлайн-программа, работает в браузере.

Три года назад я делал доклад в Институте системного программирования Российской академии наук под названием Неклассическая теория алгоритмов и алгоритмический язык ДРАКОН.

Аннотация доклада

Современная теория алгоритмов не имеет удобного (эргономичного) языка, позволяющего облегчить и ускорить понимание алгоритмов ЧЕЛОВЕКОМ. Она не применима к медицинским алгоритмам и не содействует повышению безопасности пациентов. Она не оказывает практической помощи при разработке бизнес-процессов, потоков работ (workflows) и пр.

Современные языки программирования используют управляющие слова (if, then, else, case, switch, break, while, do, repeat, until, for, foreach, continue, loop, exit, when, last и др.) , которые играют роль визуальных помех, провоцируют появление ошибок и мешают понять смысл алгоритма в терминах предметной области.

В докладе предлагаются теоретические и практические средства, чтобы устранить или ослабить указанные недостатки.

Видеозапись доклада и обсуждения 2 часа 38 минут
https://www.youtube.com/watch?v=MFPqCqcv7kY&amp;t=7496s

Выкладываю ссылку на презентацию (104 слайда) https://drakon.su/_media/video_i_prezentacii/parondzhanov_slajdy_1-104_isp_rana_.pdf к докладу "Паронджанов В.Д. Неклассическая теория алгоритмов и алгоритмический язык ДРАКОН".

Здравствуйте, MadHuman, Вы писали:

MH>И также понятно что такой подход в некоторых случаях (что-то очень большое, высокопроизводительное и тп) не подойдёт.

Был такой у MS сервер — BizTalk. Лет 17-ть назад на одном проекте нам его активно пихали. Так вот там, всё это уже было реализовано. После нескольких попыток использования вердикт был однозначен — фтопку. Для того, чтобы нарисовать в графике более менее сложные алгоритмы потребовались бы экранны с разрешением не менее 100000x50000.

Здравствуйте, IT, Вы писали:

IT>Был такой у MS сервер — BizTalk. Лет 17-ть назад на одном проекте нам его активно пихали. Так вот там, всё это уже было реализовано.

Эти слова не имеют отношения к Дракону. Первый общедоступный редактор Дракона появился 12 лет назад. Ваши слова "всё это уже было реализовано" не относятся к Дракону и вводят в заблуждение.

IT>Для того, чтобы нарисовать в графике более менее сложные алгоритмы потребовались бы экраны с разрешением не менее 100000x50000.

Это не так. У языка Дракон есть мощные средства декомпозиции. Чем сложнее алгоритмы, тем больше выигрыш от использования Дракона.

Здравствуйте, Владимир Паронджанов, Вы писали:

IT>>Для того, чтобы нарисовать в графике более менее сложные алгоритмы потребовались бы экраны с разрешением не менее 100000x50000.
ВП>Это не так. У языка Дракон есть мощные средства декомпозиции. Чем сложнее алгоритмы, тем больше выигрыш от использования Дракона.

Конечно, есть. Но мы их не покажем. Я правильно понимаю? В приведённой в этом топике презентации никаких средств декомпозиции не обнаружено.

IT>>>Для того, чтобы нарисовать в графике более менее сложные алгоритмы потребовались бы экраны с разрешением не менее 100000x50000.
ВП>>Это не так. У языка Дракон есть мощные средства декомпозиции. Чем сложнее алгоритмы, тем больше выигрыш от использования Дракона.
IT>Конечно, есть. Но мы их не покажем. Я правильно понимаю? В приведённой в этом топике презентации никаких средств декомпозиции не обнаружено.
Почему не покажем. Посмотри у Митькина — там вполне работающий редактор и не только...

Здравствуйте, IT, Вы писали:

IT>В приведённой в этом топике презентации никаких средств декомпозиции не обнаружено.

В языке ДРАКОН для декомпозиции больших алгоритмов предусмотрены два инструмента:
• использование Вставок (процедур и функций),
• дробление алгоритмов силуэт на ветки.

Про силуэт и ветки см.
https://www.youtube.com/watch?v=Q0YBdX9xazw
Декомпозицию я подробно описал в книге для врачей про клинические алгоритмы (алгоритмы действий врача) на стр. 219-238.
https://drakon.su/_media/26_algoritmicheskaja_klinicheskaja_medicina.pdf

Программистам подобное разжевывание неинтересно, так как все становится ясно при знакомстве с инструментальными средствами Дракона.

Есть еще один полезный прием, известный как Правило Сергея Ефанова.
https://forum.drakon.su/viewtopic.php?f=172&amp;t=6853

Делайте ветки силуэта небольшой высоты, чтобы силуэт по высоте целиком размещался на экране (без прокручивания вверх-вниз).

Выгода в том, что прокручивать можно и нужно будет только в одном направлении — по горизонтали (влево и вправо).
И никогда — по вертикали

Вводные видео по языку ДРАКОН см.
https://forum.drakon.su/viewforum.php?f=179

Здравствуйте, Владимир Паронджанов, Вы писали:

ВП> В языке ДРАКОН для декомпозиции больших алгоритмов предусмотрены два инструмента:
ВП>• использование Вставок (процедур и функций),
ВП>• дробление алгоритмов силуэт на ветки.

Т.е. если простые диаграммы вынуждают нас прогручивать их по вертикали, то силуэты добавляют сюда ещё и прокрутку по горизонтали.

Интересно, как будет выглядеть такая диаграмма, если у неё в одном блоке будет 15 элементов, а в другом 2. Боюсь, что таких ровненьких алгоритмов, как в этой презентации, в жизни существует не много.

ВП>Есть еще один полезный прием, известный как Правило Сергея Ефанова.
ВП>https://forum.drakon.su/viewtopic.php?f=172&amp;t=6853
ВП>Делайте ветки силуэта небольшой высоты, чтобы силуэт по высоте целиком размещался на экране (без прокручивания вверх-вниз).

Этот способ известен лет сорок и звучит как "процедура должна помещаться на экране". Обусловлен он ограничениями древних мониторов, которые умели листать код только постранично. Если такой полезный приём необходим дракону, то это однозначно признак несовершенства.

IT>Этот способ известен лет сорок и звучит как "процедура должна помещаться на экране". Обусловлен он ограничениями древних мониторов, которые умели листать код только постранично. Если такой полезный приём необходим дракону, то это однозначно признак несовершенства.
Процедура и сейчас должна быть маленькой...
И дело не в экране.
А в размере страницы памяти и кэша.