DRAKON.SU

На сайте OberonCore есть форум "О зашоренности".
Хвост этого форума по инициативе Петра Алмазова посвящен Дракону.

Даю ссылку на сообщение Петра Алмазова и последующие
viewtopic.php?p=72346#p72346

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

Петр был остроумен - ему оставался только 1 шаг до фразы:
"Сторонники Дракона - когнитивные кроты".

По поводу моей фразы:
(+ на идеи в области создания визуального интерфейса,
которые в настоящий момент еще не сформулированы или только начинают
проходить свою экспериментальную обкатку в каких-нибудь почти никому
не известных сейчас инновационных компьютерных фирмах)

Трудно сказать, каким будет интерфейс с компьютером лет через 5.
Возможны варианты от сравнительно локальных изменений типа
touch-screen, параллельной работы с 2-мя мышами, введения и
стандартизации новых, не используемых сейчас элементов визуального
интерфейса до интерфейса с использованием жестов, движений глаз,
голоса и даже (чего только не может быть в будущем!) при помощи
мыслеуправления.
Я считаю, что в таких условиях вопрос стандартизации текстовой формы
техноязыка, в том числе для записи декларативных знаний, по-прежнему
остается актуальным.

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

Решил прокомментировать следующее замечание TAU:



Удалось случайно выделить день для просмотрщика и вот что получилось
(конечно недоделка, но это сейчас не важно):

А чем Вам замечание TAU не нравится (шутка )?
Как раз Ваш пример показывает всё то же - "когнитивная слепота" не в том, что в принципе пытаются получать граф-схему (в частности, императивную на техноязыке) по тексту. А в том, что при этом игнорируют тот факт, что эта схема уже есть представление обычно более формальное. Об этом хорошо сказал в своё время А. Куликов: Ряд вещей в том же посте вызвали, скажем так, вопросы - посему пришлось разобрать здесь: viewtopic.php?p=66483#p66483. Но вот с этим согласен.

И это как раз ещё к непренебрежимости уровнями процесса формализации/моделирования (чем у нас, как обнаружилось по любезному указанию В.Д., и академики, по-видимому, пренебрегать пытаются - см. здесь: viewtopic.php?p=69519#p69519 )... Среди которых есть уровни информатически строгие - рассчитанные на исполнителя типа "языковая машина", деятельность которого есть алгоритмический процесс.

Конкретно - Куликов прямо указывает, что само приложение техноязыка как системы записи импер-части отчуждаемого знания, более формальной, чем естественный язык, уже выводит сочинителя на более строгую формализацию. Где надо "вытащить из текста алгоритм/систему взаимодействующих алгоритмов". А одновременно - также "вытащить" систему определений объектов (как абстрактных/"конкретных" типов). И определение исполнителя алгоритмов над объектами... Т.е., то, что у Кауфмана в Гл. 3 - абстракции операций, данных и связывания для планирования деятельности исполнителя. Образующие целостный базис. И требующие, между прочим, не игнорировать текст как разметку схемы, а наложить на него некие требования строгости, адекватные строгости, налагаемой формализованным графом как основой схемы...

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

У Вас, Дмитрий, в примере производящий язык для схемы - псевдокод. Т.е. адекватный по строгости. Там и алгоритм уже "вытащен", и состав объектов, и "репертуар" действий (проверять величины на равенство, делать что-нибудь и бить баклуши). Здесь многообразие уже сведено к трактовке конкретным исполнителем в конкретной ситуации действия "делать что-нибудь". Очевидным исполнителем является человек. Если мы полагаемся на его здравый смысл - то такое многобразие допустимо. Иначе следует формализовать более строго смысл уже этого действия. Что, очевидно, приведёт к частной модели его как алгопроцесса...

В общем, сочинитель д.б. незашорен на том, чтобы просто "разнести неформальный текст по вершинам". А д.б. готов сразу идти дальше по уровням формализации. Тогда "когнитивной слепоты" не будет. И, между прочим, выявится то самое, о чём говорил Куликов - что сама попытка "разнести" у нормально мыслящего человека выявит направления уточнения представления о предмете... Между прочим, как раз через подведение его под систему тех самых паттернов. Взятых либо поодиночке, либо, если ограничиться импер-частью отчуждаемого знания - в композиции цепочек/циклов (даже без ветвлений - согласно теореме Бёма-Джакопини ). А среди одиночных паттернов ведущим будет как раз цикл Дейкстры (ну и Ваш ЦС-эквивалент, который снова использован в примере).

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

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

Псевдокод у меня в примере приведен для простоты.
Меня, естественно, интересует более практический аспект:

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

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

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

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

В общем, реальные критерии "когнитивной слепоты" прежде всего в том, что:

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

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

Хорошая критика. В качестве конструктивного зерна предлагаю извлечь:
1. ФАКТОР(байт) = <число байт текста в Дракон-редакторе> / <число байт инвариантной/сгенеренной программы>
2. ФАКТОР(время) - <время отрисовки Дракон-схемы в редакторе> / <время набора программы в текстовом редакторе>
можно брать методики оценки Дж.Раскина по временам работы графического интерфейса.

А потом оценить редакторы и кодогенераторы.

Я бы предложил оценивать время разработки алгоритма.
Но не знаю : ) как это сделать.
Поскольку дважды в одну реку не зайти ...

21 студент и 4 задачи.
1. 20 студентов решают задачу 1 методом Текст.
2. 20 студентов решают задачу 2 методом Граф.
3. Разбиваем студентов на две группы по 10, уравнивая результаты по обоим методам.
4. Группа 1 решает задачу 3 методом Текст и задачу 4 методом Граф.
5. Группа 2 решает задачу 4 методом Текст и задачу 3 методом Граф.
6. Студент-психолог по своим стандартным методикам считает вашу реку.
(кстати, ему это можно пустить курсовичком)

Ну, по-простому уже предыдущий оратор показал, как. А общие принципы ИП-экспериментов можно найти у Смирнова и Тинькова здесь: viewtopic.php?p=57423#p57423. Но, как я подозреваю, Вы не о столь масштабном думали... Так что конкретнее можно поступить, как говорил Лаптев: viewtopic.php?p=71345#p71345. Т.е. надо, чтобы была возможность сбора статистики рабты с приложением (в данном случае - и на время, а не только на действия).

Но. Есть и факторы субъективные, не сводимые к метрикам "в попугаях". Уже писал об этом:

Потому там рядом с "Методами ИП" и Бестужев-Лада рулит...

И о метрике кода. Во-первых, надо понять - число байт текста на каком языке записи? Видимо, на том самом стандартном, о котором Дмитрий_ВБ говорит? и который сначала ещё д.б. реализован "каждой лошадью, участвующей в забеге"?..
Во-вторых - есть "хитрости" формального синтаксиса (на котором можно стандарт определить). Которые я понял уже по Свердлову - а потом нашёл подтверждение у Мейера (Гл. 11 - в выдержки не вошла). Он там как раз пишет, что нужно корректно строить определение грамматики, чтобы использовать его как меру сложности языка.

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

* неформальный, "эскизный", уровень - "родные" типа языков пошагового уточнения, перечисленных в этом подразделе - но с фиксацией структуры текста, примерно как здесь задано;
Определение ЯПУ по Потопахину (неформальное) можно найти в его "Решении...".
* уровень спецификаций - типа Д-языка, описанного в выдержке здесь (п. 3.3.1);
* уровень программирования - Promela+never-LTL - то же самое, что Д-язык, только с параллелизмом и программизмом (и с явными БП - чтоб никому не обидно...).

К первым двум уровням надо как раз ту самую деклар-часть, о которой Дмитрий_ВБ говорил. Третий - полноценный ЯП, но со слабой системой типов данных. Так что надо ещё в текстовом виде "скрестить"... ну хотя бы с О-07... Получится нечто вроде языка для структурного редактора В. Лаптева.

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

Какие ещё будут мнения?

Сравнивать нужно не на специальных простых примерах, под которые заточен Дракон. Но я сильно сомневаюсь, что всё, что возможно, скажем, на C#, возможно и на Драконе с автоматической трансляцией в исполнимый код (или в целевой язык программирования).

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

Кстати, создатели Дракона не задумывались над обратной задачей: генерировать дракон-схемы по коду на ЯВУ - в качестве иллюстрации при головоломной передаче управления? Обычные блок-схемы генерятся - я сам такую программку опробовал. Иллюстративные возможности Дракона не грех использовать, в отличие от попыток программировать непосредственно на Драконе. Эта задача проще, так как блок-схема не обязана быть однозначно понятной компьютеру. Лишь бы человек разобрался.

Ну, обычный техноязык - возможно. Но его можно и расширить на ассемблер... типа как здесь...
Кстати, Вы, наверное, о чём-то типа агентов/делегатов? У Мейера в Гл.17 это неплохо объяснено... и оттуда можно извлечь идеи схемного представления. Только там понятно другое - не что линией это не изобразишь, а что к графу только императивному (т.е. дракон-схеме) не сведёшь...
Да вот уже задумываются: viewtopic.php?p=72498#p72498.

Это неизбежно. Сколько бы поклонники Дракона не пытались собрать швейную машинку из деталей, спертых с оружейного завода, всё равно получится пулемет. В любом промышленном визуальном средстве программирования не обойтись без (частично) текстовой и/или древовидно-табличной записи алгоритма и декларативной части. И обведение текстовых операторов рамочками не меняет этого факта. Но собственно визуальная часть в Драконе гораздо беднее по возможностям и менее эргономичная, чем, например, в PureBuilder.

Я уже так и вижу, как в ответ кто-то из "поклонников Дракона" пишет: "а вот, например, в PureBuilder..." и далее следует какой-нибудь образец спецпропаганды... вроде разобранного здесь или здесь...
А если серьёзно и сохраняя нейтральность - то Вы утверждаете всё-таки не то, что имели в виду сторонники техноязыка. И это как раз можно показать, привлекая эквивалентные текстовые языки. Т.е. нормальная визуализация - это не просто "обведение текста рамочками". Это как вначале "просто текст" перевести на более формальный язык. Скажем, ЯПУ Потопахина. В результате чего в нём появляется структура. Выраженная ключевыми словами (если мы выявляем структуру в импер-части - то маршрутными). И остальной текст становится более строгим. Потому что начинает играть роль атрибутов структурных элементов.

А уже затем эту запись мы превращаем в схему. Где "рамочки и линии" не "обводят текст" (исходный - так надо понимать) - а замещают собой маршрутную лексику в ЯПУ-тексте. Просто опытный сочинитель может сразу в уме делать более более строгое представление и в виде уже схемы...

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

Только боже упаси реализовывать преобразование "иллюстрация на Драконе" -> "исходный код, в т.ч. в структурном редакторе", при котором пару раз пересаженная лиана приведет к полной кастрюле GOTO-лапши в исходном коде.

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

Ерничают, когда нечего возразить по существу. Уже сейчас есть более десятка визуальных средств разработки типа Scratch, которые по своим возможностям и эргономике многократно превосходят Дракон. А то, что перспективные идеи в этом направлении еще не реализованы - это не их недостаток. От того, что Дракон реализован (кстати, далеко не полностью), ничего по большому счету не изменилось.

Не знаю уж, как работают студентки у кого, но мне довелось поставить эксперимент, где этот фактор как раз исключился: viewtopic.php?p=40397#p40397. Результат приводил здесь. Так уж получилось, что девушки (некоторые) лучше всех справились (в т.ч. ребят). И не у кого было им списывать (кроме Паронджанова ).
Почему так? Уже Валерий говорил: viewtopic.php?p=57317#p57317 - в силу образности мышления.
В то же время, как можно видеть, результат "сырой". О причинах этого тоже сказано: viewtopic.php?p=64991#p64991. И выводы были сделаны - приведены здесь: viewtopic.php?p=65075#p65075 (а реализованы ещё раньше).

К этому, кстати, имеет отношение и следующее Ваше замечание:
Вполне согласен. Поэтому и предлагал только атомарный вывод - как здесь описан.

Не понял, что за комментированный блок. Свёртывать можно и саму запись - как текстовую, так и граф-базированную. Впрочем, они д.б. "двумя сторонами одной медали" (т.е. вьюшками от одного файла проекта). Как, скажем, в "Ракетном дизайнере кода"...

Т.о. студентки не только списывать могут... но и сделать нечто, что студентам впору списать... Главное - чтобы удобно думать было... в частности, и по форме...

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