DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 17:23

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Суббота, 02 Ноябрь, 2013 13:40 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Владимир Паронджанов писал(а):
Что такое ДРАКОН?

Это не один язык, а семейство языков, то есть множество языков.

Семейство содержит:

— Язык моделирования ДРАКОН.

— Язык программирования ДРАКОН специального назначения, используемый в НПЦАП (ГРАФИТ-ФЛОКС). Это закрытый язык программирования и закрытая технология, предназначенные для программирования на компьютере Бисер, разработанном в НПЦАП и устанавливаемом на борту ракеты.

Получается что термином "Язык моделирования ДРАКОН" Вы обозначаете всё-таки гибридные языки, причём отличные от ГРАФИТ-ФЛОКС, который Вы относите к "Языку программирования ДРАКОН специального назначения".
Вся путаница происходит от того, что слово "Дракон" используется для обозначения разных вещей. Путаницы можно было бы избежать, для этого следовало в самом начале выполнить два пункта:
1. Строго специфицировать язык ДРАКОН.
2. Разработать и выпустить компилятор хотя бы для одного гибридного языка.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Воскресенье, 03 Ноябрь, 2013 06:42 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ну что ж, начнём теперь с "контекста продвижения"...

1. Вот здесь:
Владимир Паронджанов в viewtopic.php?p=83297#p83297 писал(а):
Владислав Жаринов писал(а):
для признания его (Дракона) языком программирования необходимо иметь средства описания данных. - тогда как это не так
Это неверно
- Паронджанов возражает не мне, что было бы очевидно, приведи он адекватную цитату (мой формат некорректностей организации сообщений):
Владислав Жаринов в viewtopic.php?p=83256#p83256 писал(а):
Да, вот о чём и речь, что тон автора объясняется, скорее всего, тем, что по "контексту продвижения" ДРАКОНа у него сложилось такое впечатление:
Цитата:
... Если считать алгоритмическую полноту «Дракона» доказанной, то для признания его языком программирования необходимо иметь средства описания данных. Но «Дракон» подобен флюсу: полнота его односторонняя (почти по Пруткову).

Однако В.Пароджанов преподносит свой «Дракон» как самодостаточную вещь.
- тогда как это не так... но так сразу этого не поймёшь... :)

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

2. Почему же получается, что "так сразу не поймёшь"? Вот здесь:
igor в viewtopic.php?p=83328#p83328 писал(а):
Владимир Паронджанов писал(а):
Что такое ДРАКОН?

Это не один язык, а семейство языков, то есть множество языков.

Семейство содержит:

— Язык моделирования ДРАКОН.

— Язык программирования ДРАКОН специального назначения, используемый в НПЦАП (ГРАФИТ-ФЛОКС). Это закрытый язык программирования и закрытая технология, предназначенные для программирования на компьютере Бисер, разработанном в НПЦАП и устанавливаемом на борту ракеты.

Получается что термином "Язык моделирования ДРАКОН" Вы обозначаете всё-таки гибридные языки, причём отличные от ГРАФИТ-ФЛОКС, который Вы относите к "Языку программирования ДРАКОН специального назначения".
Вся путаница происходит от того, что слово "Дракон" используется для обозначения разных вещей. Путаницы можно было бы избежать, для этого следовало в самом начале выполнить два пункта:
1. Строго специфицировать язык ДРАКОН.
2. Разработать и выпустить компилятор хотя бы для одного гибридного языка.
...
- полагаю, вполне это представлено.
А именно, если следовать доступным материалам:
    * "ДРАКОН" в ГРАФИТ-ФЛОКС - язык "алгоритмических чертежей" программных процедур для "Бисера", употребляемый в связке с языком "сущностных (величинных) таблиц" ФЛОКС;
    * "ДРАКОН" в популяризации В.Д. - это язык "слепышей" некоей топологии, предлагаемых в интерпретации потока управления любых алгоритмических процессов (не только программируемых не только для "Бисера").
Класс топологии был конкретизирован Ермаковым и коллегами как устремлённая (сводимая) с дополнительным требованием планарности. Синтаксис класса м.б. задан предлагаемым шампур-методом как "исчислением икон", а реально - неразмеченных устремлённых графов с возможностью планаризации путём укладки в "силуэт".
Что на возможные интерпретации не влияет само по себе - для всего, что по результатам системного анализа конкретных предметных областей м.б. структурировано как "устремлённое", можно выводить структуру шампур-методом.

Но тогда в конкретной предметике информатизации деятельности и надо вспомнить про сказанное здесь (формат мой):
http://compiler.su/programmirovanie-bez-programmistov-eto-meditsina-bez-vrachej.php, п. «Дракон» = программа — данные писал(а):
...
«В вашем языке статическая или динамическая типизация?» «Где уместно применить сильные стороны ООП и есть ли им место в «Драконе»?» «Поддерживает ли он обобщённое программирование?» «Какое управление памятью в «Драконе» — явное или неявное?» «Есть ли в нём чистые функции, замыкания и программирование в стиле продолжений?»
...
- а именно к тому, что алгоритмический процесс (процедура типа программной) не сводится только к своей структуре управления...

И, если мы хотим в схемной форме ответить на вопросы автора сайта, то недостаточно того, что:
"Для описания данных служит икона "полка". ...
Можно предложить и другой способ: описание данных выносят за рамки дракон-схемы и помещают в специальную таблицу." (Как улучшить..., с. 183)

А что для этого требуется - выскажусь далее.


Последний раз редактировалось Владислав Жаринов Воскресенье, 03 Ноябрь, 2013 07:19, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Воскресенье, 03 Ноябрь, 2013 07:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Выскажусь теперь насчёт этого:
igor в viewtopic.php?p=83328#p83328 писал(а):
...
Путаницы можно было бы избежать, для этого следовало в самом начале выполнить два пункта:
1. Строго специфицировать язык ДРАКОН.
2. Разработать и выпустить компилятор хотя бы для одного гибридного языка.

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

Другой способ продумал Ярослав Романченко в проекте Д2О для Активного Оберона - и, как можно понять его выводы, АО-сущности по отдельности можно описать строками таблиц различных форматов. Однако также нужно как-то эти таблицы структурировать в модели АО-программы.

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

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

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

Мало того, не проявляется и взаимодействие процедур в программе. То, что Барановский назвал "программной логикой верхнего уровня". В этом посте он предложил требования к ней.
Один из аспектов этого обозначил и автор сайта:
http://compiler.su/programmirovanie-bez-programmistov-eto-meditsina-bez-vrachej.php, п. О чём помалкивают предлагающие нам поумнеть писал(а):
...
P.S. Цикл «for each» давно не новинка в программировании. Но почему такого цикла нет в «Драконе»? Не потому ли, что цикл «for each» уменьшает количество стрелок в блок-схеме? Т.е. уменьшает «визуальность» программирования и уменьшает потребность в «Драконе»?

P.P.S. К сожалению, В.Паронджанов очень мало пишет об иконке «вставка». Было бы интересно посмотреть на «вставку» перегружаемых или виртуальных функций. Или рекурсивную «вставку».
- где, по сути, поставлены два вопроса в топик ветки:

P.S. - цикл по множеству элементов предполагает обращение к составляющим множества. А если они неэлементарного типа - то ко внутренней структуре элементов. Что есть предмет именно типизации данных. Мало того, есть вопросы представления этого множества как целого. Прежде всего позиционирования на элементах (и на границах множества) - об этом у Мейера хорошо написано...
    И да, форич может упрощать структуру потока управления на ЯВУ. Перенося значительный смысл на структуру данных... и не просто в статике "по объявлению", а в динамике...

P.P.S. - а это уже ко взаимодействию процедур. И тут оправданно вспомнить Усова:
alexus в viewtopic.php?p=69216#p69216 писал(а):
...
Собственно, множества (диапазонов) значений множества переменных/элементов системы и образуют состояния системы. Эти состояния проверяются инвариантами. Вполне очевидно, что было бы правильнее определить/задать состояния системы на этапе её проектирования и для каждого состояния написать свой вариант метода, если он чувствителен к данному состоянию. В таком случае система могла бы безошибочно запускать тот вариант метода, который соответствует её текущему состоянию. Можно построить такую простую аналогию. Как известно, объект некоторого класса (в процедурно-объектных языках) обладает своей VMT (virtual method table). В системе таких VMT несколько, по одной на каждое из её состояний (полиморфизм у одного объекта). В таком случае, переход системы из одного состояния в другое связан с простым переключением со "старой" VMT на "новую", которая становится активной для нового состояния. (VMT - как правило, не лучшее, но простое и наглядное решение). Другими словами VMT становится двумерной. По одной стороне по-прежнему идут виртуальные методы, а по другой состояния системы (j-ый метод в i-ом состоянии). При этом никаких проверок состояний, т.е. инвариантов, внутри методов, конечно, делать не нужно. Поэтому я и называю инварианты в ООП "костылями" и суррогатами.
...
- кстати, он тоже обсуждает здесь подход Мейера... только уже к "объектности"...

И ставит более общую проблему:
alexus в viewtopic.php?p=69216#p69216 писал(а):
...
Но введение/оценка/переключение состояний это только небольшая часть проблемы повышения размера/роста/развития систем. Следующий шаг связан с самооценкой, самоидентификацией... оценкой состояния внешней среды, выбор оптимального поведения/самоуправления... И т.д. Это динамический процесс, поэтому надо особенно... тщательно выбирать решения, положенные в основу.
- а в связи опять-таки с ДРАКОНом пояснял и своё решение:
alexus в viewtopic.php?p=63435#p63435 писал(а):
... Здесь уже обсуждался вопрос о том, что Дракон можно использовать для описания алгоритмов, но для описания систем он не слишком подходит. Это первое.
Второе. Вопрос реализации, при разработке систем, вторичен. Как правило, первичен вопрос концепции, архитектуры. А именно этого нет (и не может быть в Дракон-схемах). Без качественной концепции, Вы обречены... на рефакторинг, то есть, на то чтобы стать пожизненным рабом своих собственных реализаций. Если не возражаете, я поясню простым примером, на основе Вашей первой схемы. Общеизвестно (со времен К. Маркса и Ф. Энгельса), что в основе любого(!) производства лежат три сущности:
1. Предмет труда (от сырья и полуфабрикатов до продукции);
2. Средства труда (инструменты, оборудование);
3. Живой труд (физический, умственный...).
Разумно предположить, что единичным элементом производства является операция, и, следовательно, операция должна включать в себя все три перечисленных выше сущности (ведь производство может состоять и из одной операции). В случае многопередельного производства, то есть, производства, состоящего из нескольких операций, операции связываются направленным графом (орграф). В полученном орграфе, который называется "технологический процесс/маршрут", вершинами являются операции, а ребрами - передачи полуфабрикатов(*) с одной операции на другую.
..., каждая операция характеризуется тремя видами нормативов:
1. Нормы производства/выработки;
2. Нормы использования оборудования и инструментов;
3. Нормы использования персонала.
Нормы расходов могут параметризовываться, например, условиями труда, ...
Помимо перечисленных нормативных характеристик операций есть и другие: рабочее время операции, время смены заготовки, время перехода на другую продукцию (время переналадки).
Далее. Сами операции могут быть обязательными или факультативными. Обязательные операции выполняются всегда, факультативные выполняются при некоторых условиях, например, по желанию заказчика или при низком качестве исходного сырья, или ...


А как построить такое решение (например, используя ДРАКОН в своей части)? Как обычно при системном подходе:
alexus в viewtopic.php?p=63435#p63435 писал(а):
...
И здесь мы подходим к основному вопросу... Исходная идея, о создании подобного программного обеспечения, должна получить концептуальную основу. Концепция - это конкретизированная идея, показывающая принципиальную возможность ее реализации. На основе концепции строится концептуальная модель, которая является основой для последующего проектного решения. Если сделать проекцию на строительство, то концепция - это общее эскизное решение архитектора. Концептуальное решение - это решение архитектора привязанное к местности, местным условиям. Проектное решение - это формальная модель, то есть такая модель, которая не допускает неоднозначного понимания. Для получения формальной модели, концептуальная модель перекладывается на некий формальный аппарат (описывается на формальном языке). Вы же идете с противоположного конца, незрелую идею Вы пытаетесь втиснуть в "прокрустово ложе" формального языка. Это тупик...
Идея, доросшая до концепции, сама конкретизирует средство своего формального описания... как правило (правда, бывают ситуации, когда необходимых средств формального описания просто нет). Например, я бы не взялся реализовывать представленное мной описание на Драконе, не потому, что я плохо знаю Дракон, и не потому, что Дракон плохой язык... Дракон - хороший язык для описания алгоритмов (хотя он явно делает попытки выйти за эти рамки... зря, IMHO), но он бесполезный язык для описания систем.
...


К чему это? А к тому, что и в ГРАФИТ-ФЛОКСе есть такая концепция (которую в силу закрытости технологии мы можем выявить лишь примерно, основываясь на сообщениях открытых сведений). И у любой известной реализации, использующей ДРАКОН для тех или иных целей. И в любой методологии формализации/моделирования - SADT, ARIS, ЕСКД...
И для любой версии "гибридного программирования" такой концепцией нужно задаться. И она на уровне "программно строгой" формализации будет следовать... ну, например, этому:
Владислав Жаринов в viewtopic.php?p=78120#p78120 писал(а):
...
Тут, кстати, Виталий Валерьевич подсказывает решение по поддержке:
на с. 20 писал(а):
... Работу программы т.о. можно воспринимать как передвижение набора данных между программными блоками.
..., процедура - это средство структурирования программы. ... имя процедуры - некоторая метка, поясняющая, какая подзадача в данной точке текста программы д.б. решена. Это, в свою очередь, позволяет разделить процесс разработки на различные уровни абстракции с определённой последовательностью передачи управления и структур данных.
- имея в виду, что структуры данных передаются, конечно, преобразованными в результате исполнения операций по структуре управления.
...

А на "верхнем уровне логики"- например, тому, что сказал Дмитрий_ВБ...

Итак, на сегодня вышеприведённые пункты выполнены только в первом приближении. Целесообразное их выполнение с использованием именно исходного ДРАКОНа начато отдельными участниками.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Воскресенье, 03 Ноябрь, 2013 11:53 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владислав Жаринов писал(а):
http://compiler.su/programmirovanie-bez-programmistov-eto-meditsina-bez-vrachej.php, п. О чём помалкивают предлагающие нам поумнеть писал(а):
...
P.S. Цикл «for each» давно не новинка в программировании. Но почему такого цикла нет в «Драконе»? Не потому ли, что цикл «for each» уменьшает количество стрелок в блок-схеме? Т.е. уменьшает «визуальность» программирования и уменьшает потребность в «Драконе»?

Иконы для цикла "for each" таки есть в ДРАКОНе : )
Вложение:
у.png
у.png [ 13.48 КБ | Просмотров: 10442 ]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Воскресенье, 03 Ноябрь, 2013 12:29 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владислав Жаринов писал(а):
http://compiler.su/programmirovanie-bez-programmistov-eto-meditsina-bez-vrachej.php, п. О чём помалкивают предлагающие нам поумнеть писал(а):
...
P.P.S. К сожалению, В.Паронджанов очень мало пишет об иконке «вставка». Было бы интересно посмотреть на «вставку» перегружаемых или виртуальных функций. Или рекурсивную «вставку».

Элементарно... : )
Вложение:
д.png
д.png [ 16.82 КБ | Просмотров: 10438 ]

где
Вложение:
ре.png
ре.png [ 47.73 КБ | Просмотров: 10438 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Ноябрь, 2013 15:14 

Зарегистрирован: Понедельник, 04 Ноябрь, 2013 13:53
Сообщения: 5
Наконец-то мне удалось зарегистрироваться на этом форуме. Две давнишние попытки заканчивались сообщением: «После активации вашей учётной записи вам придёт ещё одно сообщение». Не пришло.

Это я являюсь автором всего того, на что здесь ссылаются. Хотелось бы ещё раз обозначить своё мнение по «Дракону».

1) Когда-то я тоже рисовал блок-схемы. В начале своего профессионального пути они мне помогали. Но чем дальше, тем проще без них стало обходиться. Потом рисование блок-схем стало лишним: алгоритмы и так держатся в голове, а рисовать их на бумаге – неудобно: практической пользы – никакой, а время отнимают.

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

3) Краткость кода важна как с содержательной, так и с визуальной точки зрения. Визуальная компактность даёт возможность быстро просматривать и осмысливать код, не прибегая к мышке и клавишам. Ради неё даже сменил стиль написания кода. Если раньше я писал
Код:
int func(…)
{
   if (…)
   {
      что-то
   }
};
// ---------------

то теперь пишу в Питон-стиле:
Код:
int  func(…) {
           if (…) {
                        что-то }
}; // --------------------

4) Блок-схемы и «Дракон» не позволяют писать визуально компактный код. Код в «Драконе» занимает больше места на экране. Рыхлый код менее эргономичен.

5) Есть другие способы улучшить визуальное восприятие теста программы, о них я писал на своём сайте. Приведу пример:
Условные операторы,
Переключатель,
Циклы,
Продолжение цикла и выход из него.
Добавлю к написанному там, что хотелось бы сделать синтаксическую раскраску более «продвинутой». В C++, к примеру, приоритет операций меняется от 0 до 15, и в тексте программы не всегда очевидно, что в каком порядке выполняется. Синтаксическая раскраска должна подсказать это программисту. Или взять такое уродство, как венгерская нотация. Типы объектов лучше отображать прямо в IDE условными значками. Пока это на уровне идей и до практической реализации далеко. Но такое вряд ли предвидится в «Драконе», ведь он показывает лишь маршруты. «Дракон» - это надстройка над языками, в которой нет лексического/синтаксического/семантического анализа. Синтаксическая раскраска в нём станет возможной тогда, когда компилятор станет его частью.

По моей задумке, графическое оформление кода, его синтаксическая раскраска должна формировать IDE по мере ввода теста. Т.е. с этим не должно быть связано никаких дополнительных усилий со стороны программиста. Ну это как если бы программист вводил текст, а «Дракон-схема» формировалась бы сама. Чтобы не создавать иконку «условное выражение» и вписывать туда текст, а написать «if (…) …» и наблюдать, как это всё поместится в внутри возникшей иконки.

6) Блок-схемы вообще и «Дракон» в частности могли быть полезными для начинающих программистов или тех, для кого программирование не является их профессией,. Но есть сомнения, что они останутся столь же полезным по мере овладения профессией.

7) Зачастую алгоритм вторичен по отношению к данным. Я уже писал, что у Дональда Кнута схемы данных встречаются в 11 раз чаще, чем схемы алгоритмов. Возьмём, к примеру, схему, которая иллюстрирует связь между таблицами в БД (отношение «один-ко-многим»):
Изображение
Что в этом плане может предложить «Дракон»?

8 ) Мне известны попытки разработки блок схем для ремонта типовой электроники. Расписывались контрольные точки, а далее алгоритм: «померь напряжение в точке А; если такое напряжение – переход одну точку алгоритма, если другое – в другую точку». Но дальше НИР это не пошло.

9) По поводу цитаты обо мне: «Автор не имеет допуска к первоисточникам, не располагает достоверной информацией». То есть, иными словами, я не специалист. Я действительно не специалист и сужу об аварии «Протона» по конечному результату. Как человек, который выходит из кафе или парикмахерской, и, не разбираясь в технологиях службы сервиса, делает своё заключение – вкусно ли его покормили и хорошо ли его постригли. Но я двумя руками «за», чтобы каждым делом занимался свой специалист. Чтобы программировали программисты, собирали электронику электронщики, а запускали ракету ракетчики. Поэтому считаю, что «программирование без программистов» и «электроника без электронщиков» глубоко порочны. Но принять работу специалистов (возможно, с техзаданием на руках) на выходе может и неспециалист по принципу «работает – не работает», «хорошо – плохо». Как в кафе или парикмахерской.

10) На свете есть немалое количество программистов, которые известны и уважаемы, которые писали книги и делились секретами своей профессии. Алексей Степанов и Никлаус Вирт, Андрей Ершов и Дональд Кнут. Высоты, которых они достигли в программировании, общеизвестны. Это были люди, которые возвышались над нами. Но ни один из них не писал книг, названия которых намекали бы нам об их умственном превосходстве. Владимир Паронджанов же, чей след в программировании я вообще не заметил, ничтоже сумняшеся даёт такое название своей книге, которое ставит на разные ступени ум автора и ум читателей. Читателям предлагается, «как улучшить работу ума». Поэтому «Программирование без программистов — это медицина без врачей» - это эмоциональный ответ за тех, кто считает такие названия неуместными.

11) Реклама «Дракона» агрессивна, и она началась до того, как добровольцы самостоятельно (без участия Владимира Паронджанова) сделали этот продукт реальным. Вообще не предпринято каких-либо попыток критически взглянуть на блок-схемы и «Дракон». Ведь блок-схемы применялись с 50-х или 60-х годов. Но потом вышли из обихода. По времени это примерно совпало с началом широкого использования дисплеев взамен перфокарт. Может, лёгкая доступность текстов для редактирования и сгубило блок-схемы? Может ли автор «Дракона» проанализировать причины ухода в небытие блок-схем? Может объяснить, почему 99,99…% программ создано без блок-схем при том, что все о них знают? В Википедии о «Драконе» написано, что его недостаток – малая известность среди разработчиков. Но ведь о его прародителе все знают, и почему-то не используют. Ведь аналоги «Дракона» давно существуют – для тех, кому блок-схемы нужны в электронном виде. И обучение программированию до сих пор начинают с блок-схем. Но потом программисты считают, что уже выросли из коротких штанишек блок-схем. Как найти этому объяснение? Заговор, косность, недальновидность? Или существует рациональное объяснение? Люди с аналитическим складом ума всё-таки должны давать ответы на такие вопросы.

Если бы мы видели попытку какого-то беспристрастного анализа – информация о «Драконе» внушала бы доверие. Но у автора в ходу рекламные штампы: «камикадзе умственного труда», «математический терроризм». Не видно попыток сравнения: «с «Драконом» такая эффективность, а без него – эдакая». Поэтому статья «Программирование без программистов — это медицина без врачей» – это некий противовес рекламе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Ноябрь, 2013 16:42 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
communicay писал(а):
Но потом программисты считают, что уже выросли из коротких штанишек блок-схем. Как найти этому объяснение? Заговор, косность, недальновидность? Или существует рациональное объяснение? Люди с аналитическим складом ума всё-таки должны давать ответы на такие вопросы.


Я думаю, что попытки как пропагандировать, так и критиковать ДРАКОН, некорректны без разделения на разные целевые ниши:
- информационного характера алгоритмы (с которыми сталкиваются те 90% программистов - и которые решаются хорошей декомпозицией, часто даже управляющая логика уходит на ООП-виртуализацию - т.е. вместо IF работает полиморфизм, и т.п.);

- системный анализ, алгоритмы в предметных областях (где ДРАКОН как раз и пошёл, как видим, сейчас "в гору");

- алгоритмы управляющего (reactive, реагирующего) характера - совершенно специфичного характера код.. Где, например, декомпозиция не всегда желательна, иногда расслоение принятия решения по уровням усложняет дело.
Замечу, что выделение отдельного класса алгоритмов - реагирующих - является общепринятым. Кроме западных источников, такую классификацию - и анализ отличий - делал, например, Шалыто (см. Шалыто "Алгоритмизация и программирование в задачах логического управления", например).
Что мы имеем в этой области?
- графические языки стандартов МЭК;
- подход конечных автоматов в визуализуемом варианте (как у европейцев - косм. агентство INRIA, так и у того же Шалыто со SWITCH-технологией);
- широко распространённый LabVIEW;
- Microsoft Robotics Studio;
- LEGO Mindstorm - кажется, тоже.
Т.е. как раз-таки для этой ниши графические языки в порядке вещей...
Именно из-за специфики задач...
Кстати, кроме всякого управляющего и бортового ПО, есть фрагменты кода и в "обычном" ПО, имеющие такой характер.
Пример, допустим, из моей практики: в финансовой системе может быть блок принятия решения о выдаче/отказе в кредите. С массой ветвлений и проч. ДРАКОН там гораздо лучше смотрится, чем обычный код, в котором ногу сломишь.... Да, есть, конечно, и таблицы решений, но тут по ситуации...

Кстати, если говорить об источниках алгоритмических ошибок, то для правильно обученного (владеющего методом Дейкстры и упрощёнными, базовыми паттернами циклов - viewforum.php?f=82) программиста те же циклы вообще перестают быть источником ошибок; а вот развесистое принятие решений с кучей условий никакими методами, кроме смысловой проверки, не поборешь. И нужно представление алогоритма в какой-либо форме, облегчающей "аудит кода"..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Воскресенье, 10 Ноябрь, 2013 16:44 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
communicay писал(а):
Наконец-то мне удалось зарегистрироваться на этом форуме.
...
Поэтому статья «Программирование без программистов — это медицина без врачей» – это некий противовес рекламе.

Приветствуем Вас на форуме языка Дракон.

Вы критично настроены и Вам удалось высказаться.

Получается, Вы программист не новатор, закостенелый.

Можно узнать:
какие книги по языку Дракон Вы прочитали,
какая среда языка Дракон Вам знакома или освоена,
как Вы общаетесь с заказчиком, заказчик понимает Ваш программный код,
как пользователь работает с Вашей программой,
какую часть в Ваших программах занимает описание прикладной проблемы,
сколько Вам лет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Понедельник, 11 Ноябрь, 2013 09:11 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
1.Мне очень нравится статья "Программирование без программиста - это медицина без врачей", аргументы хорошие, написано живо и профессионально. От такой замечательной критики не стоит "отбиваться", лучше поместить ее как предисловие к очередной книге Паронджанова :wink: .
И лозунг хорош, у многих возникает желание продолжить, как Вам такое:
Зимний пуск - без автомеханика
За рубеж - без компетентного сопровождающего
Уже и смыслы интересные появляются...

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

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

4. А над предложением о синтаксическом, а то и семантическом(кто знает?) анализе стоит подумать.

Так что Добро Пожаловать!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Понедельник, 11 Ноябрь, 2013 13:02 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Прежде всего следует разграничить понятия "собственно Дракон" и "гибридный язык Дракон+ХХХХ". И то и другое какбЭ Дракон, что является источником недоразумений.
Собственно, объектом разработки явился Дракон в первом смысле. А второе - это результат композиции (или симбиоза) Дракона и настоящего языка программирования. Причём, эта композиция не является безупречной. Как минимум она не ортогональна. Дракон дублирует некоторые средства, которые в текстовом языке и так уже есть.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Понедельник, 11 Ноябрь, 2013 13:29 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Чтобы снять недоразумения, уточняю про "гибрид с текстовым языком". Это не Дракон с кодогенератором текстового файла на языке XXX. Это программная система, написанная на языке ХХХ, имеющая в составе средства работы с Драконом: отображение, редактирование, создание исполняемого модуля. Даже, если 90% на текстовом языке и 10% на Драконе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Ноябрь, 2013 16:49 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
communicay писал(а):
7) Зачастую алгоритм вторичен по отношению к данным. Я уже писал, что у Дональда Кнута схемы данных встречаются в 11 раз чаще, чем схемы алгоритмов. Возьмём, к примеру, схему, которая иллюстрирует связь между таблицами в БД (отношение «один-ко-многим»):
Изображение
Что в этом плане может предложить «Дракон»?

Это интересное замечание.

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

Тем не менее, структура данных действительно важна. Иногда даже больше, чем алгоритм.
К счастью, в настоящее время на секретных заводах куют новую версию DRAKON Editor'а.

Там будет редактор структуры.

Я придумал графический язык для описания структуры данных.
Назовём его ERIL. (Entity-Relationship and Inheritance, чтоб никто не догадался).

Будущий редактор структуры в DRAKON Editor реализует этот самый язык ERIL.

ERIL основан на:
1. Диаграмме сущность-связь
2. Диаграмме наследования
3. Эргономических принципах ДРАКОНа.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 11 Ноябрь, 2013 16:53 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
communicay писал(а):
«Программирование без программистов — это медицина без врачей» - это эмоциональный ответ за тех, кто считает такие названия неуместными.

Программирование без программистов — это здоровье без врачей.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Ноябрь, 2013 07:50 

Зарегистрирован: Четверг, 21 Январь, 2010 18:06
Сообщения: 63
Откуда: Нижний Новгород
communicay писал(а):
6) Блок-схемы вообще и «Дракон» в частности могли быть полезными для начинающих программистов или тех, для кого программирование не является их профессией,. Но есть сомнения, что они останутся столь же полезным по мере овладения профессией.


У меня родился еще один, м.б. смешной, аргумент в пользу визуального программирования.

При разработке/редактировании кода (алгоритма) рассматриваю Дракон схему как картинку, т.е. ассоциативно. Каждый алгоритм имеет собственный рисунок.

Между прочим, радисты принимают код Морзе не по точкам и тире, а по мелодии...

Работаю с И.С. DRAKON около трех лет и не собираюсь возвращаться на текст.
Однако с декларативной частью оооооооооочень не просто...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Вторник, 12 Ноябрь, 2013 07:57 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Петр Приклонский писал(а):
Работаю с И.С. DRAKON около трех лет и не собираюсь возвращаться на текст.
Однако с декларативной частью оооооооооочень не просто...

Почему зависли на старом выпуске и не переходите на новый?

Есть оператор //Include - позволяет переносить часть программного кода в визуальную часть иконы, это будет решением -
визуализации декларативной части кода,
многократного использования декларативной части кода, при однократном описании,
вложения операторов //Include друг в друга.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Вторник, 12 Ноябрь, 2013 08:14 

Зарегистрирован: Четверг, 21 Январь, 2010 18:06
Сообщения: 63
Откуда: Нижний Новгород
Геннадий Тышов писал(а):
Почему зависли на старом выпуске и не переходите на новый?


Во первых консервативность... Руки привыкли к старому управлению ис (тоже ассоциация :) ).

На самом деле для деклараций широко использую "ГНОМ". Не хватает многооконности, "дерева" листа и пр. прелестей, которые есть в "виндусовых" IDEшках.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Вторник, 12 Ноябрь, 2013 08:18 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Не хватает ..., возможно и не надо. При этом, минимальность не отвлекает, нет необходимости присваивать схемам наименование.

В новых выпусках, переключение между схемами на листе производится по нажатию клавиш Влево, Вправо, т.к. схемы размещены линейно и последовательно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 12 Ноябрь, 2013 16:54 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В сообщении viewtopic.php?p=83732#p83732 Степан Борисович Митькин писал(а):
Я придумал графический язык для описания структуры данных.
Назовём его ERIL. (Entity-Relationship and Inheritance Language).

Будущий редактор структуры в DRAKON Editor реализует этот самый язык ERIL.

ERIL основан на:
1. Диаграмме сущность-связь
2. Диаграмме наследования
3. Эргономических принципах ДРАКОНа.

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

Даю ссылку на тему по языку ERIL
viewtopic.php?f=62&t=3821&hilit=eril


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Среда, 13 Ноябрь, 2013 21:04 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Цитата:
...
Кстати, если говорить об источниках алгоритмических ошибок, то для правильно обученного (владеющего методом Дейкстры и упрощёнными, базовыми паттернами циклов - viewforum.php?f=82) программиста те же циклы вообще перестают быть источником ошибок; а вот развесистое принятие решений с кучей условий никакими методами, кроме смысловой проверки, не поборешь. И нужно представление алогоритма в какой-либо форме, облегчающей "аудит кода"..

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

Рекомендую глянуть на проект LiveScript - это развитие популярного CoffeeScript - фактически, это препроцессор для генерации кода на JavaScript. Его цель - удобное наглядное представление кода, императивное с "функциональными" мотивами. Во-первых, это пример "когнитивного" кода, без лишнего информационного шума (пусть пока потенциально, в этом языке имеются проблемы, и речь идёт не только о синтаксическом сахаре, которого кушать нужно тоже в меру. И на сайте удобно показано сравнение с "классическим" кодом). И, во-вторых, это база для ряда алгоритмических техник, которые оправдали себя на практике (не только в этом языке).

Несколько простых примеров. Сейчас в императивном коде всё больше и больше "драконовский поезд" по развилкам "схлопывается" в базовые элементарные линейные структуры, как-то так:
Код:
# "if" как вычислительное выражение (а не оператор) + постфиксная форма:

var1 = value1
var2 = value2_1 if param1 > 0 else value2_2
var3 = value3

# "Elvis"-оператор:

x = param?.field?.value

# что аналогично:

if (param <> null) and (param.field <> null) then
    x = param.field.value
else
    x = null

Есть потенциал делать менее развесистыми и управляющие алгоритмы. Картинка ниже взята из статьи Ермаков И. Е., Жигуненко Н. А. "Двумерное структурное программирование; класс устремлённых графов. (Теоретические изыскания из опыта языка «ДРАКОН»)", здесь: Ермаков, Жигуненко. Двумерное структурное программирование:
Вложение:
alg_pusk.PNG
alg_pusk.PNG [ 41.44 КБ | Просмотров: 10166 ]

Алгоритм (рис. 1а) представлен в двух текстовых вариантах (рис. 1б и 1в), добавим третий:
Код:
Пуск = () -> try
                OK = Напряжение в норме
                Выдать питание на силовую шину
                OK = Нагрузка силовой шины в норме
                Запуск генератора ВЧ
                OK = Параметры сигнала в норме
                Пуск системы
             catch
                Отказ от пуска

В этом коде выражения вида "OK = ..." являются не операторами присваивания, а сопоставление с образцом ("pattern matching" в ФП). Результат функции (например, "Напряжение в норме") мы сопоставляем с атомом/enum (и т.п. конструктором данных) "OK", и если результат иной ("Cancel", "Error" и т.п., согласно декларации функции), то поток выполнения прерывается, и срабатывает обработка ошибок в секции "catch". Транслятор а-ля LiveScript в таких случаях будет генерировать код необязательно через реальные исключения, на выхлопе могут быть те же классические "if"-ы, goto, jump и т.д., что нужно на целевой платформе.
При сопоставлении могут быть переменные, защитные выражения:
Код:
OK x | x > 0 = some_func(...)

# где функция some_func() возвращает кортеж, указывающий или на успех + данные, или на ошибку:

some_func:  (...) -> OK data | Error message

# а так мы можем сопоставлять результат функции с содержимым переменной:

OK x | x > 0 = some_func(...)  # в "x" сохранили результат
...
^x = other_func(...)           # результат ф-ции other_func сопоставляем с результатом предыдущего
                               # вызова ф-ции some_func

Конечно, управляющий алгоритм выше (насчёт "пуск"-а) - это простой код, собственно, как и исходная Дракон-схема. При множестве исходов работы функций будут добавляться и другие ветки сопоставления результатов (примеры использования "pattern matching" есть на странице LiveScript), что усложнит логику и представление алгоритма, но эффект будет тот же и для Дракон-схемы, причём соизмеримый.

Далее. В рамках снижения ветвления кода можно посмотреть в сторону языка Go, где применяют "отложенные" или "упреждающие" вычисления (не путать с "ленивыми", lazy evaluation, это несколько иное), примерно по таким мотивам:
Код:
load_data = (file_name) ->
    OK file = file_open(file_name)   # открываем файл
    defer file_close(file)           # "откладываем" закрытие файла
    ...
    data = load_file(file)           # как-то используем файл
    ...

Здесь "defer file_close(file)" - это вызов встроенной ф-ции defer, где в качестве аргумента передаётся блок кода (лямбда), который будет исполнен позже, после завершения текущего основного блока (всей функции в данном случае). Т.е. закрытие файла выполнится как бы в конце функции, в любом случае даже при вылете по исключению. Причём вызов "defer" явно определяет точку, когда именно "включаются" отложенные вычисления. Т.е. в данном примере если открытие файла не будет успешным (отрицательный результат сопоставления в первой строке ф-ции), то следующая строка (defer) не будет исполнена, соответственно не будет и закрытия файла в дальнейшем.
Такая техника похожа на некие явные управляемые "деструкторы", но позволяет "по месту" указывать необходимые контекстные действия, что нагляднее, чем выносить их в отдельные процедуры. Плюс такой подход уменьшает потребность в реализации библиотечных деструкторов, когда речь идёт о разовых специализированных алгоритмах (и не обязательно в контексте освобождения ресурсов), и нет нужды оформлять код для многократного применения, при этом создавать класс/объект/интерфейс/миксин/класс_типа и т.д. по вкусу, фактически, только для деструктора. С одной стороны, вроде как, на первый взгляд - это серьёзная почва для усложнения кода, но практика показала обратное (благодаря отложенным вычислениям в Go нет дополнительных управляющих инструкций для обработки исключений вида try/except/catch/with/finally и т.п., встречается и критика "defer", но больше именно в контексте имеющихся принципов обработки ошибок, а сами "defer", вроде как, "народ принял").

Что ещё можно подкинуть... Всё больше и больше в императив приходят отработанные техники из ФП, в т.ч. и комбинаторы, т.е. построение алгоритмов из комбинаций функций (и операторов), которые жонглируют блоками кода в качестве аргументов. А вот с наглядными структурными блоками кода у Дракона те же проблемы, что и у блок-схем, особенно когда необходимо локализовать блок "по месту", в контексте текущего алгоритма (как блоки для "defer" выше). Эта особенность затронута, например, здесь: ДРАКОН и лямбда-выражения.
И, кстати, о примере первичного исходного кода из этой темы:
Код:
# Исходный пример на Erlang:

SelectedValues = lists:map(
        fun(key) ->
                value = dict:fetch(key, SomeDictionary),
                string:to_upper(value)
        end,
        Keys)

# здесь имеется неэргономичность в том плане, что "лямбда" находится внутри скобок в качестве аргумента
# для map, да ещё за ней следует второй аргумент Keys. Это результат такого объявления ф-ции map:

    map: (item -> res, list) -> list

# так удобно для каррирования:
   
    upper_list' = map to_upper(it)       # каррируем ф-цию, передаём только лямбду "to_upper(it)"
    ...
    upper_list = upper_list' some_list   # применяем для какого-то списка

# для полного вызова удобно вынести лямбду (первый аргумент) за пределы скобок (в данном случае
# получится инвертирование аргументов). В некоторых языках используют для этого, например, "do":

    SelectedValues = do lists:map Keys, key ->
                            value = dict:fetch(key, SomeDictionary)
                            string:to_upper(value)


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

В общем, я в двух словах хотел показать, что и в рамках текстового представления есть средства для управления сложностью, кроме декомпозиции, причём речь идёт о средствах поближе к "ручному управлению" на месте, тут же, локально, не отходя от кассы (от контекста текущего алгоритма). И ключевой момент не в сравнении визуального и текстового представления (нужны все), основной посыл в том, что явная визуализация потока выполнения имеет предел (причём не такой уж и высокий), до которого дракон-поезд помогает, дальше уже помогает слабо, или не работает вовсе, или ещё больше затрудняет. Поэтому и появляются регулярно темы форума, по мотивам указанных выше ("Преобразование графов", "ДРАКОН и лямбда-выражения" и многие другие). И вполне не беспочвенны желания наблюдать и наглядный "поезд", и наглядную структуру алгоритма, особенно там, где поезд ездить не может. Отсюда и нередки подобные темы: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ (интересующимся: там затронуты несколько технологий). И есть попытки совместить драконовские граф-маршруты с декларативными алго-описаниями, например, здесь: ДРАКОН и функциональные языки программирования.
И, кстати, выкладываю картинку, где пример алгоритма из этой темы, в виде Дракон-схемы, гибридной схемы с элементами FBD и в виде эквивалентного функционального текстового описания:
Вложение:
first_upper.PNG
first_upper.PNG [ 55.61 КБ | Просмотров: 10166 ]

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

И добавлю ещё одно сравнение (источник здесь):
Вложение:
states.PNG
states.PNG [ 25.91 КБ | Просмотров: 10166 ]

Здесь примерчик модели автомата в виде UML-диаграммы и два варианта её текстовой декларации (синтаксис авторский в соответствии с используемой программной платформой). Текстовая форма приведена всего лишь для ремарки: с текстом не всё так уж и плохо, особенно учитывая интерактивные средства для работы с ним. А вот графика...

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


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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: «Дракон» = программа — данные
СообщениеДобавлено: Четверг, 14 Ноябрь, 2013 11:35 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Интересное сообщение, спасибо, ряд новых моментов Вы поведали.

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 16


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB