DRAKON.SU

Слишом общее заявление:
По каким возможностям ? Управлять в реальном времени реальными объектами
управления со сложным поведением (стартующая ракета, роботизированный
заводской конвейер и т.п.) Какой "Дракон" ? CASE "ГРАФИТ-ФЛОКС" ? или
описание языка Дракон из книги "Как улушить работу ума ?" или ИС Дракон
Г.Тышова ? или Дракон-редактор С.Митькина ?
Как Вы определяете эргономические параметры ? Возможность раскраски
текста, обведения его цветным контуром сложной формы, вставки красивых
рисунков и значков ? Вы уверены, что это сильно облегчает понимание по
сравнению с суховато-производственной графической нотацией языка ДРАКОН ?
(Кстати, вся техническая документация до сих пор остается черно-белой,
а ведь в ней - 100-летний опыт стремления к наиболее четкому выражению на
бумаге технической мысли. А программирование - это одна из областей
технического знания)
А нужна ли обычным пользователям-программистам реализация всех возможностей
языка Дракон как они были описаны в книге "Как улушить работу ума?"


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

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

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

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

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

На странице PureBuilder внизу есть ссылки на множество визуальных средств разработки. Часть из них обладает всеми достоинствами Дракона, которые Вы описываете.



Разумеется, всё это не важно. Главное - формирование программного кода из готовых визуальных шаблонов и невозможность синтаксических ошибок. Но это только первый слой визуализации программы. Более сложные средства визуализации описаны в PureBuilder. Кстати, в PureBuilder нет цветовой раскраски текста, но есть выделение ключевых слов жирным шрифтом - как в книгах.

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

4) Программа строится как схема (возможно 3D) из блоков, сдержимое которых может задаваться
текстом, голосом, мыслью или путем выбора из меню.
Возможно так Вы видите будущее развитие PureBuilder-а.
И драконоподобные среды стремятся в этом же направлении.

Ну и в чем тогда неразрешимое противоречие ?

Видимо, так: viewtopic.php?p=72527#p72527 ?.. Т.е., если "кубики" правильные - то и их композиция будет правильной?..

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

Т.е. это вариант содержания блока - как "управленческое приложение" в Ты-среде?..

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

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

Противоречие в том, что PureBuilder - это программирование в структурной парадигме в форме 1D с отступами (ветвями) (кроме автоматически генерируемых 2D схем межмодульного взаимодействия и т.п.), а Дракон - это блок-схема 2D, манипулирование которой неоправданно трудоемко (вдобавок тесно связанная с GOTO).

3D - это вообще завиральное детище режиссеров киберпанка. Мне нравится этот жанр, но иногда он вызывает смех.

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

2) Чтобы приспособить силуэт к документированию структурного исходного кода, я
отвязался от GOTO.
Ввод визуальной схемы в программе dal_vjaz_2 (выложена в теме "AB_VJAZ и DAL_VJAZ" 17.03.2012)
выполняется при помощи структурно-текстового интерфейса, заимствованного из интерфейса
структурных редакторов.
А перевод из одномерной логической структуры процедуры (аналог структурной записи в
структурном редакторе) в визуальную схему 2D программа выполняет сама.

Преобразование "исходный код" -> "Дракон" не требует существования GOTO (поэтому я не возражаю против использования Дракона в иллюстративных целях). Но обратное преобразование "Дракон" -> "исходный код" в общем случае требует существования GOTO.

Я использовал подмножество маршрутных операторов ДРАКОНа, в которое GOTO не входит.
При генерации исходного кода в него вставляются служебные комментарии, например
(*i*) if ( ...

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

В общем случае (многоадресный силуэт и/или неатомарно пересаженные лианы в теле примитива/ветки силуэта) - да, требует. Но если не пользуемся этими возможностями - то нет. А межветочные БП в одноадресном силуэте убираются элементарно. Если многоадресный силуэт сделан исключительно для укладки петель циклов в петлю силуэта - то дело ненамного сложнее чисто логически(межветочные БП превращаются в точках начала ВМЦ в начальные соединители обычных циклов). Но алгоритмически реализовать, наверное, м.б. не так просто.
Ну и как у Дмитрия_ВБ - эмулируем ЦД - можно и с силуэтом имеющимся поступить. Но это уже работа для сочинителя скорее...

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

Ну, как цифр, так и ответов на пункты вопросников... которые всё равно надо составлять...
Насчёт заявления - тут нужно уточнить, что понимается под визуальной частью. Помнится, Сергей писал: А также:

Похоже, это всё в основном не предмет техноязыка (кроме последовательностей инструкций - т.е. потока управления). Хотя м.б. и взгляды Сергея в чём-то изменились?..
Нужно, правда, иметь в виду и такое замечание: viewtopic.php?p=47521#p47521.

Вот, кстати, к вопросу о структуризации - интересны источники отсюда: viewtopic.php?p=28927#p28927 (и последующее обсуждение).