DRAKON.SU

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

Меня заинтересовало следующее:



Prospero78 выдвинул два тезиса:

Тезис 1. Серебряной пули не существует.
Тезис 2. Язык Дракон вряд ли найдёт широкое применение.

Мой комментарий (и мои возражения) состоят в следующем.

1. Тезис о том, что "Серебряной пули не существует", относится к программированию. Я согласен с prospero78, что язык ДРАКОН пока что в области программирования не проявил себя и не получил признания среди программистов-практиков.

2. Но. По моему глубокому убеждению, программирование и алгоритмизация — разные вещи. Число людей, которым нужно знать и уметь использовать алгоритмы, на порядок (или на два порядка) превышает число людей, которым надо знать программирование.

3. Алгоритмы — это не только математически строгие алгоритмы, но и "алгоритмические предписания" (по Н.Н. Непейвода"). Сюда относятся не только flowcharts, но и workflows, и медицинские алгоритмы, и бизнес-процессы.

4. В таком понимании алгоритмы — это огромная вселенная, которая пока еще не имеет своего собственного, удобного и эргономичного алгоритмического языка. Как писал Маяковский:

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

6. Конкурентами языка ДРАКОН являются следующие графические средства:
— международный стандарт ISO 5807:85 и его калька ГОСТ 19.701—90.
— диаграммы поведения языка UML, в частности:

— диаграмма деятельности (activity diagram),
— диаграмма состояний (UML state machine)
— некоторые диаграммы взаимодействия, например, диаграмма синхронизации (timing diagram).

— средства описания бизнес-процессов: IDEF, BPMN и др.
— другими аналогами дракон-схем являются диаграмма Насси-Шнейдермана, псевдокод (язык описания алгоритмов) и др.
— графический язык системы 1C:Предприятие

=====================

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

Уважаемый Паронджанов! ))
Из приведённых моих цитат для LKom следует:
1. Программирование и алгоритмизация -- разные виды деятельности.
2. Программирование лишь одна из сфер деятельности человека, где алгоритмы торчат непосредственно. В других -- об алгоритмах не говорится явно, но фактически они есть.
Тот же, гори он синим пламенем, упомянутый 300-страничный документ минобра нуждается в построении AST. Уверен, что дебажить этот документ бесполезно, время потраченное на попытку построить AST из этого документа будет потрачено зря. Его либо надо выкинуть вообще, либо написать с чистого листа заново.

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

А теперь в защиту тезиса о том, что серебряной пули не существует.
Есть уже весьма развитый раздел знаний, как "нечёткая логика". Как следует из названия, обеспечить строго детерминированный ход логики не получится. Придётся вводить семантику внешнего воздействия. Как-то графически обозначить, конечно, можно. Но как отобразить в графической схеме взаимодействие нескольких объектов? А если у них ещё сложные интерфейсы? Диаграммы Гранта, UML, состояний, переходов и много чего ещё, о чём я не имею ни малейшего понятия -- народ уже столько всего понавыдумывал, что изучать это можно всю оставшуюся жизнь. И не написать при этом ни строчки кода.

Какое графическое представление использовать -- зависит от ситуации. Одно дело -- я разработчик ПО в виде архитектора. Графическая визуализация в виде дракон-схем может не подходить именно из-за возможной двунаправленной связи глобальных объектов. Другое дело, если я программист-исполнитель: дракон-схема поможет наглядно отобразить, например, протокол обмена основной программы с базой данных. Третий случай, когда я руководитель проекта, и мне нужно принять решение о том, какую цену выкатить заказчику: мне потребуется знать, на сколько сложен код. Мне не важна алгоритмика, мне важны отношения, мне важна сложность объектов внутренняя и агрегатная. Дракон-схема тут будет малополезна, хотя дракон-схема, содержащая алгоритм принятия решения по оценке сложности проекта на основе внешних данных -- может оказаться полезной.

Ну, и есть такие ситуации, например мать и маленький ребёнок, где интуиция окажется выше любого алгоритма. У меня и моей гражданской жены ОЧЕНЬ часто совпадает ход мыслей, желаний и т.п. Даже есть две ходовые пословицы:"Ты слишком громко думал" и "Хватит копаться в моей голове". Дракон-схемы в таких ситуациях просто не успевают)
Хотя возможны.

http://forum.oberoncore.ru/viewtopic.php?p=97672#p97672