Обсуждение ИС Дракон

Учитывая интерес (как собственный, так и сообщества) к данному средству, решил вынести в отдельную тему, т.к. вобсуждении статьи очень тяжело ориентироваться.
Цель - не только обсудить, но и в меру возможностей посодействовать развитию данного проекта.
Задачи:
1. Создание актуальной и удобной справочной системы
2. Совершенствование кодогенератора, поддержка новых языков
3. Что-нибудь ещё придумаем по ходу :)
______________________________

Мои предложения по п.1:
Организовать открытый проект на вики-системе, чтобы каждый мог легко внести свой посильный вклад в свободное время.
Например, на викиучебниках (если там модеры не такие отмтроженные, как на педивикии)

По п.2 пусть предлагают те, кому актуально *(ассемблисты, например).
От себя бы предложил автору представить полную спецификацию формата хранения дракон-схем .drt, чтобы люди могли подключать к редактору собственные примочки (не только кодогенераторы, а и преобразователи, например, в .pdf, .doc итдитп.)

В общем, как-то так.

1

Сообщение от sitimur Вот пример из чего получился приведенный мною 1С код: http://infostort.ru/public/311020/

Автор 1С кода - Илексиндр Ириптинав и Влидимир Паронджанов приглашают познакомиться с их мнением по поводу обсуждения на данной теме: http://forum.obiromcore.ru/vie... 989#p89989

0

Я на том форуме не зарегистрирован, поэтому отвечу тут. Лично мое мнение, что смена программиста не приведет к потерям если код, который писал "старый" программист, хорошо документирован. Не стоит допускать делитантов до работы, тем более позволять им делать автоматизацию бизнес процессов. А сборка программ "из кубиков со стрелочками" ведет к повышению требований к оборудованию и невозможности что-то изменить в будущем. Я не говорю о том, что подобные инструменты не имеют права на жизнь. Я говорю о том, что они хороши как средство для "чернового" написания кода, который в обязательном порядке подлежит анализу и документированию для будущих поколений. А иначе мы будем иметь хаос. В принципе, мы его и имеем.

0

Давайте спорить о вкусе устриц с теми кто их ел, не вижу смысла обсуждать проблемы кодинга с Илексиндром Араптановым и Влидимиром Паронджановым не написавших ни строчки кода.
Деятельность конфигураторов 1С какой имеет отношение к программированию ?

0

Сообщение от dosykus_2 Давайте спорить о вкусе устриц с теми кто их ел, не вижу смысла обсуждать проблемы кодинга с Илексиндром Араптановым и Влидимиром Паронджановым не написавших ни строчки кода.

Не совсем так. Паронджанов создал систему именно программирования, а не кодирования. Программа, написанная на Драконе (да, все эти "кубик-стрелочки-свистелки-перделки") - суть готовое ТЗ для кодирования. причем кодировать по такому ТЗ могут практически самые тупые кодеры (может, даже пынгвын, хотя вряд ли) . Причем испортить этот псевдокод крайне трудно - даже кодогенератору дракона это не удается. :-)
И обсуждать тоже можно - мы ж обсуждаем, допустим, идеи Дейкстры, а не его код (Или Ричи и Кернигана, кода которых я не видел - хотя, в принципе, скачал когда-то куда-то их "оригинальную версию" компилятора, когда ее нашли и выложили)

Деятельность конфигураторов 1С какой имеет отношение к программированию ?

Имеет. Не все 1с-ники - конфигурасты. :-) Да и в конце концов, не имеет особой роли, на чем именно писать (инструмент, ака язык программирования - вторичен).

0

Сообщение от Mykysoft Сообщение от oomomstir А вот то, что вы описали (генерация кода из схем через goto) - это лютый [censored], простите мой французский. Это такой жирный намёк, что под Драконом никакой разумной основы нет, просто квадратики и стрелочки. Вы мне тут пели песню, что Дракон не даст расставлять стрелочки чёрт знает как? Похоже, врали. Или Паронджанов - чистый теоретик, а реализацию "Дракона" делали студенты-двоечники, никогда не слышавшие ни об AST (Abstract Syntax Tree), ни о прочих давно придуманных человечеством радостях жизни для создателей компиляторов?

Основной принцип ООП - отделение интерфейса от реализации :-)
Интерфейс - это Паронджанов и его идеи (достаточно хорошо продуманное), а реализация - ну, в общем, где-то в том районе, что вы описали. Может, и не двоечники, правда... но я ж неспроста выше говорил про "продаться корпорации" - были бы ресурсы нанять программистов, либо поляна, на которой можно найти гиков-энтузиастов.В принципе, есть ощущение, что Паронджанов пишет разумные вещи =), но почему тогда он не внушил последователям, что основной строительной единицой является не квадратик, а примититив/силуэт (или какие там макроконструкции)?
Ну, к примеру, что цикл - это не набор независимых иконок, а единый блок, _внутри_ которого что-то находится?

Поймите простую вещь: если язык не даёт писать кривой код - значит, его синтаксис этого кривого кода не предусматривает (а для исключений из правил - есть операторы-изгои типа goto).

С другой стороны, если будет 100% адекватность исполнения дракон-схеме - разве же так важно, "что внутре"? пусть даже и гоуту. в конце концов, все равно все структурные конструкции в итоге транслятся в джампы и бранчи :-)
Другое дело, что адекватности выполнения пока нет (и не будет, пока не будет специализированного продукта), следовательно, надо отлаживать на целевой системе. а при отладке и трасировке на целевой системе у нормального человека от сгенерированного кода крышу снесет. а кому нужен сумасшедший программист?
Для меня неадекватный сгенерированный код (помимо того, что в случае 1С его наверняка придётся поддерживать именно в таком виде) - это признак того, какие данные скармливали генерирующему алгоритму. Не дерево, а массив блоков.

Цитата:

Если язык Дракона тупо отображается в серию goto - значит, он и состоит из блоков и стрелочек, а не конструкций более высокого уровня. С этого момента говорить о нём как о языке высокого уровня бессмысленно: он отстал от жизни лет на 30 (когда от бейсиков с goto перешли к Паскалю и Си, в которых goto был табу... Да что там - даже в Fortran 77 появился блочный оператор if).

он и состоит из блоков и стрелочек. и "блочно-стрелочная часть" у него замечательная. Структурированная, вполне в духе дейкстры, только лучше. только код генерится, как у не первый день пьяного первокурсника-двоечника.
Ну вот это ненормально. Накладывать ограничения на группы блоков и стрелочек вместо того, чтобы создать конструкции высокого уровня - это способ наловить багов.
Кстати, в незапамятные времена (в 90-е) видел другой вариант графического представления программ: не квадратики-стрелочки, а вложенные блоки. С ходу не нашёл, зато нагуглил более новую смешную штуку - http://habrahabr.ru/post/145067/ (обратите внимание на пример сгенерённого кода - он простой и вполне читаемый)
В принципе, как я понимаю, правильно построенные дракон-схемы должны позволять представление в виде вложенных блоков (или дерева).

Да, хороший программист и на ассемблере напишет структурированный код. Но зачем? затем, что структурированный код легко читается, сопровождается, тестируется и модифицируется. Хоть на ассемблере. Я имел в виду, что если нет жёсткой необходимости в ассемблере (или другом языке, позволяющем превращать код в клубок макарон) - то и не надо на нём писать, код ня языке высокого уровня легче поддерживать.

0

В принципе, есть ощущение, что Паронджанов пишет разумные вещи =), но почему тогда он не внушил последователям, что основной строительной единицой является не квадратик, а примититив/силуэт (или какие там макроконструкции)? Ну, к примеру, что цикл - это не набор независимых иконок, а единый блок, _внутри_ которого что-то находится?

согласен, что разумные.Не знаю, почему не внушил. Наверное, потому, что кроме внушения нужно финансирование. Гикам (разумным) ДРАКОН просто неинтересен, они его функционал выполняют своим мозгом. а неразумные гики - ну, делают то, что мы видим :-) :-(

Для меня неадекватный сгенерированный код (помимо того, что в случае 1С его наверняка придётся поддерживать именно в таком виде) - это признак того, какие данные скармливали генерирующему алгоритму. Не дерево, а массив блоков.

ага. именно так. "чем удобряли - то и выросло".
Хотя пример с инфостарта - это типа "мигания светодиодом", только исполненый с величайшей глубиной похабности... у меня даже аналогий вменяемых нет.

Ну вот это ненормально. Накладывать ограничения на группы блоков и стрелочек вместо того, чтобы создать конструкции высокого уровня - это способ наловить багов. Кстати, в незапамятные времена (в 90-е) видел другой вариант графического представления программ: не квадратики-стрелочки, а вложенные блоки. С ходу не нашёл, зато нагуглил более новую смешную штуку - http://habrahabr.ru/post/145067/ (обратите внимание на пример сгенерённого кода - он простой и вполне читаемый)

еще один скратч? :-) функционал и парадигма Дракона немного иная (точнее, расширенная).

В принципе, как я понимаю, правильно построенные дракон-схемы должны позволять представление в виде вложенных блоков (или дерева).

Должны.

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

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

0

Сообщение от Mykysoft Кстати, в незапамятные времена (в 90-е) видел другой вариант графического представления программ: не квадратики-стрелочки, а вложенные блоки. С ходу не нашёл, зато нагуглил более новую смешную штуку - http://habrahabr.ru/post/145067/ (обратите внимание на пример сгенерённого кода - он простой и вполне читаемый)

еще один скратч? :-) функционал и парадигма Дракона немного иная (точнее, расширенная). Ага, про скрэч я не знал.
"Расширенная" - в том плане, что варианты case рисуются не последовательно, а рядом друг с другом? Ну, это погоды не делает, и, как вы понимаете, изменить форму фигурок так, чтобы кейсы располагались по горизонтали, а не по вертикали - не великая проблема.
Кстати, заодно можно и shrink/expomd outline реализовать было бы (как я понимаю, правильно построенные дракон-схемы тоже должны бы это позволять).

0

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

Рассказывает руководитель разработки банковских систем, используется СУБД Оракел.

1. Дракон и PL/SQL, а могло и подойти, но .....
http://analyticls.ru/--drokomcheg

2. Дракон работает и весьма неплохо
http://analyticls.ru/--2

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

Между сообщениями промежуток в 2 месяца.

0

По сравнению с текстом, не хватает инструмента по сравнению схем, то есть нет способа наложить одну схему на другую и разницу увидеть в цвете, либо он пока не найден.

Ну вы поняли. Ни diff, ни mirki.
Хотя, если я правильно понимаю, "правильная" схема взаимно-однозначно переводится в AST (abstract syntax tree), а деревья уже нормально сравниваются. Так что проблема чисто техническая.

Кстати, есть текстовое представление драконовского кода? Не выложите пример?
Оно столь же ужасно, как сгенерённый код на 1С, или представляет из себя что-нибудь внятное, пригодное для диффов и хранения в VCS?

0

В теме уже разбиралась практика программирования в ИС Дракон:

от 24 мар 2014, 04:45

0

Ну да, я уже забыл (пролистал вниз, там как раз ответы на мои вопросы). Всё печально.

Единственное, что оставляет тень надежды - что это всего лишь одна реализация дракон-схем, сделанная одним человеком не лучшим образом. Возможно, когда-нибудь их реализует кто-нибудь, кто не поленится изучить теорию и реальные практики программирования (простите, но полноценная работа с VCS перебивает все возможные плюсы дракона по сравнению с текстовыми языками).

0

Сообщение от oomomstir Ага, про скрэч я не знал.

Есть даже вариант для ардуины - я на нем сына учил.

"Расширенная" - в том плане, что варианты case рисуются не последовательно, а рядом друг с другом? Ну, это погоды не делает, и, как вы понимаете, изменить форму фигурок так, чтобы кейсы располагались по горизонтали, а не по вертикали - не великая проблема.

Расширенная - это добавлены по сути два правила:
1) выполнение идет "сверху вниз" (что "по человечески логично", хотя естественнонаучникам и математикам привычнее "слева направо" ("функция от времени"), но по сути направление непринципиально. главное - что оно определено, причем именно "по заветам дейкстры" ). в традиционных блок-схемах направление как раз "каждый делает как хочет", ибо не стандартизировано.
2) принцип "чем правее, тем хуже" (что тоже несет свою логику, и "логичнее" для непрограммистов. ну и то же, что и выше "любое правило лучше его отсутствия"). самый лучший путь выполнения алгоритма - самый прямой (и короткий) сверху вниз. (например, для САУ - когда объект сам идет по траектории, не нужно высчитывать управляющие воздействия и копить отклонения)
Остальные правила и принципы - по сути, дейкстровские.

Кстати, заодно можно и shrink/expomd outline реализовать было бы (как я понимаю, правильно построенные дракон-схемы тоже должны бы это позволять).

Не можно, а нужно. Я ж говорю - задумка хорошая. но реализация омерзительная.

0

Сообщение от oomomstir Единственное, что оставляет тень надежды - что это всего лишь одна реализация дракон-схем, сделанная одним человеком не лучшим образом. Возможно, когда-нибудь их реализует кто-нибудь, кто не поленится изучить теорию и реальные практики программирования (простите, но полноценная работа с VCS перебивает все возможные плюсы дракона по сравнению с текстовыми языками).

Как раз-таки среда в смысле удобства "набивания" схемы довольно удачная, когда приноровишься, но вот общая концепция да, хромает.
С другой стороны, для популяризации дракон-подхода вполне годится, и даже для некоторых практических применений.
Например, для описания бизнес-логики и вообще алгоритмизации на производстве.
Да хоть бы и для рисования блок-схем с целью оптимизации структуры программного кода.
А когда накопится критическая масса энтузиастов, может что-то и родится.

0

Сообщение от Mykysoft Я ж говорю - задумка хорошая. но реализация омерзительная.

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

В настоящее время такая программа отсутствует (не существует в природе). Между тем она очень и очень нужна.

Уважаемые коллеги!

Если среди вас есть желающие разработать нужную для всех программу, я готов всемерно содействовать.

Как связаться с Влидимиром Паронджановым?

тел. дом. 8-495-331-50-72

тел. моб. 8-916-111-91-57

электронный адрес Где познакомиться с литературой? Здесь.

Статья ДРАКОН в Википедии

0

Сообщение от MrYurom Как раз-таки среда в смысле удобства "набивания" схемы довольно удачная, когда приноровишься, но вот общая концепция да, хромает.

концепция как раз очень хорошая.

С другой стороны, для популяризации дракон-подхода вполне годится, и даже для некоторых практических применений. Например, для описания бизнес-логики и вообще алгоритмизации на производстве.

вполне и более чем...

Да хоть бы и для рисования блок-схем с целью оптимизации структуры программного кода.

Это уже не "блок-схемы". Хотя если б мне хотя бы часть ТЗ приходила в виде драконсхем, я б дорабатывал и отдавал на исполнение программистам на порядки быстрее.

А когда накопится критическая масса энтузиастов, может что-то и родится.

Когда "накопится" - будет поздно. Дракон опередил свое время по разработке, и безнадежно (имхо, конечно) отстал в реализации.

0

Сообщение от Влидимир Паронджанов Создание качественной программы, реализующей потенциал языка ДРАКОН в интересах сообщества — чрезвычайно актуальная задача. В настоящее время такая программа отсутствует (не существует в природе). Между тем она очень и очень нужна.

Влидимир, простите, пожалуйста, мой пессимизм...
Но - концепция "программирование для непрограммистов" показала свою несостоятельность. поэтому "нужда в программе", на мой взгляд, не сильно велика.
тут замкнутый круг: пока ее практически никто не применяет - нет хорошей потребности - нет достойного софта - нет обучения - нет пользователей - нет применения - .... [далее по кругу].
Если будет какое-то решение, обеспечивающее применение (допустим, "весь софт для космонавтики проектируется и документируется в драконе", или "принять дракон для обучения алгоритмированию в очень средних школах". хотя бы "госдуре все законодательные акты проверять на полноту и непротиворечивость с помощью дракон-схем") - круг разорвется. тогда появится потребность и финансирование. И - может быть (!) "процесс пойдет". Либо, как я уже говорил выше, продаться какой-то "корпорации".
т.е. грубо говоря, нужен не столько "продукт", сколько "маркетинг". Увы, реалии нашего времени

0

Вы во многом правы. Возражать Вам неразумно.

Поясню мою позицию. Она близка к позиции MrYurom.

MrYurom (на этом форуме) предложил Геннадию Тышову открыть код, чтобы общими усилиями (коллективно) довести продукт до ума. Это было великолепное и мудрое предложение. Более того, я считаю, что это было единственно правильное решение.

К сожалению, Геннадий Никалиевич Тышов не согласился.

Почему не согласился? Тышов предпочел коммерческий подход. Он продает свою любительскую и недоделанную программу за 700 рублей или около того (точно я не знаю). У него (предполагаю, но не знаю) примерно 300 покупателей (или несколько больше). Это некоторая прибавка к пенсии. У меня язык не поворачивается осуждать его за это.

По большому счету, отказавшись открыть код, Тышов допустил серьезную ошибку. Геннадий Никалиевич Тышов, при всем уважении, не сможет самостоятельно исправить недостатки программы. Ему элементарно не хватает знаний. Программа "ИС Дракон", по-видимому, навсегда останется любительской и недоделанной.

Хотя отдельные улучшения, откликаясь на жалобы и предложения пользователей, Тышов проводит, причем регулярно. Но на качественный прорыв и серьезное улучшение качества программы рассчитывать вряд ли возможно.

Могли ли события развиваться по-другому?

Думаю, что да. Если бы к делу подключился коллективный разум сообщества, как предлагал MrYurom, если бы разработка велась с открытым кодом, то мы имели бы (как мне кажется) совсем иные результаты.

Есть ли другие варианты?

Да, есть. Степин Борисович Митькин (который живет и работает в Норвегии (город Осло) создал программу DRAKON Editor c открытым кодом (Public domain). Он работает в составе коллектива. Митькин сумел объединить вокруг себя единомышленников. Вот ссылки:
http://sourceforge.net/project... tor/files/
http://drokom.su/drokom_editor

Но есть проблема

Степин Митькин не знаком с программами реального времени. Я обратился к Сергею Дмитриевичу Ефанову с просьбой помочь Митькину. Ефанов ответил, что ему программа Митькина не понравилась.

Чем дело кончилось? Ничем. Я не довел вопрос до конца и не уговорил Митькина и Ефанова поработать совместно.

Однако в принципе этот вопрос (вопрос о содружестве Степина Митькина и Сергея Ефанова) является вполне решаемым, как мне кажется.

0

Сообщение от Влидимир Паронджанов У него (предполагаю, но не знаю) примерно 300 покупателей (или несколько больше).

Влидимир Паронджанов, "предполагаю, но не знаю" - объясните, почему предполагаете 300 покупателей, а не тысячи. Скачиваний программы выполнено более 12000 раз.

Как В. Паронджанов насчитал 300 покупателей?
В 2014 году переизданы 2 книги В. Паронджанова небольшим тиражом, в книгах дается ссылка для скачивания программы ИС Дракон. Программы Митькина там нет.
Конечно каждый читатель В. Паронджанова скачал программу.
У В. Паронджанова предположение -300 покупателей, это покупатели его книг.

Посчитайте, сколько участников форума выполнили установку ИС Дракон и что нибудь заплатили автору, я таких не знаю.
Им ни язык Дракон, ни ИС Дракон не нужны.

0

Влидимир Паронджанов

Вы пишите -

MrYurom (на этом форуме) предложил Геннадию Тышову открыть код,

ссылку не даете. Приходится за вас делать работу, поиск во всех сообщениях MrYurom слов "открыть" и "код".

Нет у MrYurom во всех 368 сообщениях этих слов.

Делаем вывод:
<ul>у Влидимира Паронджанова разыгралась фантазия.</ul>
Вероятно, так и во всем остальном - фантазия:
<ul>... 300 покупателей ...
Могли ли события развиваться по-другому? ...
Есть ли другие варианты? ...
Но есть проблема ...</ul>
В реальности, люди используют ИС Дракон и я получаю от них слова благодарности.
Влидимир Паронджанов, вы в прошлом так же их говорили, за то, что язык Дракон стал реальностью, т.е. воплотился в ПО.

0

Давайте, пожалуйста, без взаимных обвинений и упреков. Программа хорошая, подход хороший, все хорошо. Просто есть люди, которым надо насрать и уйти, не обращайте на них внимание! Кому goto не нравится, пусть вообще не программируют. Я так полагаю, они не пишут гневные письма разработчикам компиляторов, почему же их прекрасно выстроенные if-else и т.д и т.п. превращаются в jmp-ы, bra и пр, а вот пресловутый goto им шаблон рвет! Ну и идут они в ж.пу...

Теперь по теме: я задал вопрос на прошлой странице, его проигнорировали. Повторяю: при сборке Си-кода с установленной галочкой "Сборка без Маршрутного транслятора" - код не собирается компилятором, выдается куча ошибок, суть которых в том, что где-то в коде пропадают закрывающие ";" и "}". Проверьте пожалуйста.

А вообще, я тоже считаю, что проект медленно идет. Разработка одного автора - изначальный тупик. Стоит привлечь партнеров в команду. Геннадий, вы говорили, что проект пишется на Делфи, увы, я свою помощь предложить не могу, ни на Делфи, ни на Паскале ни когда не программировал, да и вообще под Wymdows я слабый программист. Если вам только бабло срубить - это одно, тогда можно понять, что "после меня, хоть трава не расти", а если вы относитесь к проекту как к детищу и не заинтересованы в "смерти проекта" поищите партнеров, которые будут получать процент с продаж, может даже найдете единомышленника, который будет так же болеть за проект.

0