DRAKON.SU

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

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

Так вроде Дейкстра его в некотором смысле вывел как необходимое для своего формализма. (про лисп знаем...)

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

Совершенно согласен, мне сейчас в голову тоже пришло именно такое сравнение (с маш. кодом)... ;о)

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

В этом и есть его главная проблема -- программеры в массе своей очень консервативны и мировоззрение своё менять просто не хотят... :о)

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

Кстати, а что Вы думаете о функциональном/декларативном программировании? Можно ли это как-то совместить с Дракон-технологией? Является ли Дракон сугубо императивным, что явно войдёт в противоречие с принципами ФП/ДП?

Если честно, я не знал.

Да, и у Гриса "Наука программирования" (книга считается "учебником" на основе "научного откровения" Дейкстры) сразу в исчисление предикатов добавляются cand и cor (тьфу, забьют некоторые голову со своими лиспами - чуть не написал car и cdr ).

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

А где можно достать упомянутый выше Дракон-редоктор? У меня не получилось его найти...

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

А также автомат Калашникова и кирзовые сапоги...

При всём уважении...
Ну нет в летящей ракете места GUI, MPG-плеерам и клиентам ICQ...
Зато возможные катасрофические последствия от "зевка" разработчика ПО для ракет, авиационной, "асутэпэшной" или медицинской техники - на порядки больше. И в материальном, и в моральном, и в экологическом смыслах, и в, не дай Боже, количественно-людском смыслах...
"Шелухи" - меньше.

В этом сообщении изложена Часть 3, которая содержит мои ответы на замечания, изложенные на форуме до 24 февраля 2008 года (то есть до моего первого сообщения).
Примерно через десять дней последует Часть 4, в которой я продолжу отвечать на вопросы и критические замечания.

С глубоким уважением Владимир Паронджанов

Часть 3. Ответы Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», представленные до 24 февраля 2008 года.
Замечания обсуждаются в том порядке, в каком они появились на форуме.

Ярослав Романченко Четверг, 31 Май, 2007 16:15

Почему бы не сделать гремучую смесь Дракон+Оберон?

Ответ Паронджанова

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

GUEST Четверг, 19 Июль, 2007 17:41

Насколько я понимаю, всё дело в редакторе. Пока его нет, интересоваться действительно нечем.

Ответ Паронджанова

Уважаемый GUEST! Не могу с Вами согласиться. Мне кажется, Вы слишком осторожны и проявляете чрезмерный пессимизм. In my humble opinion, дело обстоит несколько иначе. Моя точка зрения такова.
Поскольку в открытом доступе дракон-редактор отсутствует, можно занять две существенно разные позиции:

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

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

Конечно, если нет желания тратить на подобную работу драгоценное время, тогда другое дело. На нет и суда нет.
Подробный ответ на вопрос: «Как сделать дракон-редактор?» дан в моей книге (см. главы 14 и 15). Если возникнут вопросы, я, разумеется, всегда готов помочь.

Уважаемый GUEST! Допускаю, что мои аргументы могут показаться неубедительными. Поэтому сделаю добавление. Мне известны два случая, когда люди проявляли инициативу и создавали редактор.

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

http://old.osp.ru/w2k/cgi-bin/forum.cgi?action=thread&id=1808

В каком состоянии его проект сегодня? Мне кажется, на этот вопрос должен ответить он сам.

Борис Рюмшин Четверг, 19 Июль, 2007 18:39

В вычислительных задачах графические схемы бесполезны. Там формул вполне хватает и они намного выразительнее.

Ответ Паронджанова

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

Для убедительности приведу пример из жизни. В начале 1990-х годов в Институте повышения квалификации руководящих работников и специалистов нашей ракетно-космической отрасли я и мои коллеги организовали курсы по изучению языка Дракон (двухнедельный курс с отрывом от производства). Каждый слушатель обязан был сделать выпускную работу. Откуда взять тему выпускной работы? Тему мы не навязывали. И говорили слушателям: вы на работе что-то делаете? Вот и опишите свою производственную задачу на Драконе. Слушатели так и поступали.

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

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

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

Уважаемый Борис! Вы правы, но при одном условии. При условии, что ЯСНОСТЬ И ПОНЯТНОСТЬ алгоритмов и программ для вычислительных задач НИКОМУ НЕ НУЖНЫ. В таком случае Драконом можно пренебречь.
Но если ясность и понятность являются главным требованием, Дракон, безусловно, полезен.
По моему мнению, там, где требование УДОБОПОНЯТНОСТИ процедурного программирования выходит на передний план, язык Дракон не имеет конкурентов.
Впрочем, если Вы со мной не согласитесь, я буду уважать Ваше решение.

Илья Ермаков Четверг, 19 Июль, 2007 19:06

По реализациям Дракона в сети глухо... Ловить на "ДРАКОН" слишком общо, попробовал на конкретные реализации из книжки: Дракон-Модула, Дракон-Си...

Ответ Паронджанова

Это не совсем точно. Выражение «конкретные реализации» здесь не очень подходит. Я имею в виду, что Дракон-Модула и Дракон-Си нельзя считать «конкретными реализациями».
На сегодня (в нашем Научно-производственном центре) существует и успешно эксплуатируется только одна реализация языка Дракон — это технология Графит-Флокс.

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

Иван Кузьмицкий Вторник, 24 Июль, 2007 12:55

Ага, у них там введены серьёзные топологические ограничения, сразу напомнило Оберон.
Формализации содержимого икон я что-то не приметил, надо будет плотно подойти к вопросу. Отчего бы формальным схемам не выливаться в исходный текст на Обероне, а оберон-программам не отображаться в формальную схему? Автоматически.

Ответ Паронджанова

Благодарю за чрезвычайно интересное замечание. В Вашем высказывании содержатся три важные мысли. Я отвечу на каждую мысль отдельно.

Первая мысль Ивана Кузьмицкого

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

Ответ Паронджанова на первую мысль Кузьмицкого

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

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

В самом деле, выбор «заготовки-примитив» и операции «Ввод атома» позволяет создать структурную программу в традиционном смысле слова (то есть в соответствии с требованиями Дейкстры).

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

Вторая мысль Ивана Кузьмицкого

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

Ответ Паронджанова на вторую мысль Кузьмицкого

Вы не заметили формализацию содержимого икон? Все правильно. Такой формализации в книге нет. Это принципиальный момент. Я предлагаю только графический синтаксис. Про текстовый синтаксис я молчу. Моя книга — это обращение к пытливым умам. Ребята! Если вам по душе идея Дракона, создайте такой текстовый синтаксис, какой посчитаете нужным.
Мы, конечно, создали текстовый синтаксис для себя. Но он годится только для ракет. Для ваших целей он не подходит.

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

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

Третья мысль Ивана Кузьмицкого

Отчего бы формальным схемам не выливаться в исходный текст на Обероне, а оберон-программам не отображаться в формальную схему? Автоматически.

Ответ Паронджанова на третью мысль Кузьмицкого

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

Думаю, если Вы, уважаемый Иван, сумеете реализовать «туда-сюда» преобразование, это будет просто здорово! Восхищаюсь Вашим дерзким предложением!

Конец ответов Паронджанова на предложения Кузьмицкого

Добавление Паронджанова к ответу на замечание GUEST Четверг, 19 Июль, 2007 17:41

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

Ниже приведены начало и конец статьи (середина опущена).

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

Статья опубликована в журнале «Приборостроение и средства автоматизации. Энциклопедический справочник №10 2003г». Стр.57—60.

Название статьи: Средство визуального программирования «Силуэт»

Авторы статьи: Д.А.Щелкунов, П.В. Павлов, И.А.Князев


В настоящее время разработка компьютерных программ подразумевает знание хотя бы одного алгоритмического языка, а в большинстве случаев и знание современных технологий программирования. Естественно, это отпугивает многих специалистов-предметников (инженеров, технологов и т.д.) от написания собственных программ из своей предметной области. Так, по мнению В.Д. Паронджанова [1], сложность явилась камнем преткновения информатики, которая превратила формализацию профессиональных знаний и разработку сложных компьютерных программ в сверхтрудный интеллектуальный процесс, доступный сравнительно узкой социальной прослойке и недоступный всем остальным. Сегодня, несмотря на все усилия, значительная часть специалистов, не научившись разбираться в языках программирования, оказалась отстраненной от плодотворного взаимодействия с программным обеспечением компьютера, что не позволяет им эффективно обрабатывать собственные и чужие профессиональные знания.
Исходя из классической формулировки Н.Вирта, по которой любую программу можно интерпретировать как «Алгоритм + Структуры данных» [2], мы считаем, что одним из способов повышения эффективности программирования является придание визуальной образности формам спецификации данных и описанию алгоритмов. Неслучайно, что в настоящее время делается много попыток создания средств визуального программирования.

В Международном центре по информатике и электронике (ИнтерЭВМ) разработано средство визуального программирования (СВП) «Силуэт», в котором способ программирования приближен к образному способу визуального мышления человека.

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

Графическое представление алгоритма

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

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

Раздел «Объектное представление данных»
Раздел «Архитектура СВП «Силуэт»»
Раздел «Пример разработки программы с помощью СВП «Силуэт»»
Раздел «Генерация кода и компиляция»
Раздел «Отладка программы»

Примечание Паронджанова. Ниже приведены заключительные разделы статьи:

Сохранение файла проекта

На любом этапе можно сохранить проект программы. Файлы проекта записываются на ХML-подобном языке с сохранением той вложенной структуры, которую образуют элементы схем и объекты данных в памяти компьютера. Каждый элемент схемы и сам объект сохраняет и считывает то, что ему нужно и может руководить сохранением и загрузкой тех объектов, которые расположены в нем.

Расширяемость СВП «Силуэт»

Программное ядро СВП «Силуэт» реализовано таким образом, что для добавления нового объекта данных или элемента схемы достаточно просто скопировать специальным образом подготовленную динамическую библиотеку в нужную директорию. Средство автоматически «подцепит» эту библиотеку.
Программные интерфейсы, определенные в ядре СВП «Силуэт» являются достаточно универсальными, что позволяет при необходимости реализовать различные графические представления алгоритма. Версии СВП «Силуэт» разработаны с использованием кросс-платформенной библиотеки Qt и могут работать под управлением операционных систем Windows и Linux.

Перспективы СВП «Силуэт»

Представленный в данной статье пример использует минимальные возможности СВП «Силуэт». В настоящее время разрабатывается большой набор библиотек объектов, связанных с GUI, базами данных, математикой и другими направлениями.
Особо перспективным направлением является создание средства моделирования на базе ядра СВП «Силуэт». Предполагается, что в данном средстве пользователь сможет составлять некую сцену из объектов, задавать их поведение, после чего средство будет эту модель проигрывать. Примером таких моделей могут быть системы массового обслуживания, технологические процессы и др.
СВП «Силуэт» расширяет «армию труда» в сфере программирования, поскольку к узкому кругу профессиональных программистов, в новых условиях, подключается большое количество «любителей», способных разрабатывать качественные программы на этом средстве программирования.
По мнению разработчиков, СВП "Силуэт" может оказаться очень полезным специалистам в различных научных, производственных и других областях.

Литература

1. Паронджанов В.Д. Как улучшить работу ума: алгоритмы без программистов — это очень просто! — М.: Дело, 2001.
2. Вирт Н. Систематическое программирование. Введение. — М.: Мир, 1977.

Конец статьи.

Примечание Паронджанова. Эту статью в сети я не нашел. Есть лишь ссылка на оглавление журнала и название статьи
http://www.tgizd.ru/mag/spravoch/spravoch_3_10.shtml

Конец Части 3. Конец ответов Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», появившиеся до 24 февраля 2008 года.

Продолжение (Часть 4) последует примерно через 10 дней.

Да тут простой toolbar для Блэкбокса несколько лет не могли люди сделать, а когда сделали, то такая глючная штукенция получилась, что info21 отовсюду его убирает... А Вы говорите -- Дракон-редактор! "Это фантастика!" :о))
Учитывая, что главные обероняне на этом сайте не верят в полезность графических диаграммных инструментов, то... :о)

Ох....

1) Тулбар произведение не наше, а немцев
2) Нам оно не нужно (тулбар в смысле, ну нет в нем ну никакой практической ценности )

И вообще, можно ближе к контексту темы идти, не провоцируя флейм?!

Евгений, ваше ля-ля не по делу иногда надоедает.
Тулбар делали не "тут", а кто-то из "еврооберонтузиастов". Глюченная не "штукенция", а в первую очередь реализация тулбара в Винде как COM-компонента, что приходится с ним плясать с бубном в зависимости от версии Windows. На кой, извините, ляд он нужен, если понижает производительность труда (доказанный факт, Раскина читайте, по поводу механизмов внимания у человека, работающего с интерфейсами), а в школьной версии будет приучать детей работать в режиме такой вот пониженной производительности?


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

Какие мы чувствительные и нервные... :о)

Хм, а как тогда надо понимать [url=http://www.inr.ac.ru/~info21/troitsklicej/vtorojetap7.htm
]слова info21[/url]:Или Томск в Германии находится? 8-о Что-то я географию забывать стал... :о(

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

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

Вот Вы, Илья, имеете сильновыраженное невизуальное мышление -- Вы постоянно твердите, что текст для Вас куда удобнее графиков и картинок. Но почему Вы считаете, что так должно быть удобнее ДЛЯ ВСЕХ? Вы постоянно слепо проецируете свои личные физиологические особенности на всех других людей. Правильно ли это? Сомневаюсь...

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

Томск делал сборку Школьного ББ, включив туда тулбар из коллекции Зинна. А Инфо-21 не обязан помнить, где какая гадость в интернете валяется изначально, он справедливо послал нарекания тем, кто формировал сборку.


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


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

Предлагаю эту статью перевести в электронный вид, если это ещё никем не сделано.

Что-то я не припомню, чтобы я такое доказывал. Вообще эта мысль сформулирована непонятно.

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