DRAKON.SU

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

Думаю, что программа может предоставить возможность оптимизировать линии, также как это реализовано в редакторах для текстовых языков программирования: нажал кнопку -> текст выстроился согласно правил оформления отступов.

Вопрос неправильно поставлен.
Графические редакторы можно разделить на два типа.

Тип 1. Пользователь указывает две графические фигуры (или две точки), между которыми надо провести линию. Или даже непосредственно проводит линию.

Тип 2. При построении ДРАКОН-схем пользователю запрещено проводить линии. Все линии проводит правильно построенная программа ДРАКОН-конструктор.

Что значит "правильно построенная программа"? Это значит, что она реализует исчисление икон. То есть из двух визуальных аксиом (аксиомы-примитив и аксиомы-силуэт) строит ДРАКОН-схему методом визуального логического вывода.

Некоторые существующие ДРАКОН-конструкторы не являются правильно построенными. Тогда получается, как говорит LKom, редактор-хлам.

Такой редактор необходимо доработать, чтобы исправить ошибку.

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

Я рассматриваю ДРАКОН как коммуникативное средство, и поэтому не опираюсь на свойства редакторов. Важнее способность выразить идею, мысль, процесс.

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

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

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

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

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

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

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

Разработчику надо помогать!
А что может быть важнее и полезнее НАДЁЖНОСТИ системы программирования?
В понятие надёжности входит, помимо всего прочего, и НЕВОЗМОЖНОСТЬ совершить синтаксическую ошибку.
Не возможность поиска ошибок, а именно невозможность их совершения!

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

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

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

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

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

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

Разработать качественный ДРАКОН-конструктор очень трудно. Чрезвычайно трудно.

В настоящее время ни один ДРАКОН-конструктор не удовлетворяет полностью поставленным мною требованиям.

Нужно понять принципы работы ДРАКОН-конструктора. Это не просто. Боюсь, что Вы не понимаете.


Не могу согласиться.
Программа ИС Дракон работает по-другому. И это правильно.
Программа ИС Дракон работает лучше.

Редактор можно назвать удовлетворительным, если им начинают пользоваться люди.
Можно ли сказать, что программа DrakonBar пользуется известностью? Увы, так сказать нельзя.

Если это "отличный механизм", то почему программой DrakonBar никто не пользуется, кроме вас?


Это явное недоразумение. Ничего подобного я не говорил даже близко.

В таких случаях полагается приводить цитаты и ссылаться на источники. Иначе получается голословное, ни на чем не основанное утверждение.

Дмитрий, вам просто не хватает знаний о принципах построения ДРАКОН-редакторов. Эти принципы подробно описаны в книге "Учись писать, читать и понимать алгоритмы".


Вы правы, формальные правила — это диктат. Ваше высказывание ставит под вопрос формализацию.

Например, "Математическая логика при анализе высказывания естественного языка абстрагируется от смысла высказываний и оставляет только одно значение".

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

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

Вы не сможете нарисовать в безошибочном дракон-редакторе иллюстрацию к ошибке "висячий хвост". Он вам не даст. Значит будете искать стороннее средство. Можно такую ситуацию представить для текстового редактора?

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

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

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

Запретный механизм работает и в ИС Дракон, и в DRAKONHUB. И мне они оба не подходят, когда я хочу описать учебное задание для ученика. Эти редакторы слишком узкие для моей практики.
А DrakonBar - позволяет. Потому использую его. Хотя возможность включить в нем "безошибочность" была бы полезна, не скрою. Тогда он стал бы еще замечательнее для меня. Однако, пока это лишь планы.
Скажу больше: если бы первым ДРАКОН-редактором в моем случае стал ИС Дракон, а не редактор С.Митькина, то я бы не стал им заниматься в плане преподавания, пилил бы для себя поделки и не пытался преобразовать мир. ИС Дракон, на мой взгляд, "жуткий самолет" для новичка. Работал бы с чем-то другим, наверняка.

Рисовать сложную дракон-схему на бумаге или на доске очень трудно, потому что надо помнить большое количество правил ДРАКОНа.

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

Человек скорее всего забудет одно или несколько правил.
И допустит неточность или ошибку.
Правильно построенный ДРАКОН-конструктор подобные ошибки не допускает.

К тому же ручное рисование почти всегда выполняется неаккуратно и даже коряво.

ДРАКОН-конструктор рисует дракон-схему точно и красиво.

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

Главное, что вы ОБЯЗАНЫ донести до детей - что АБСОЛЮТНО ЛЮБОЙ софт ДОЛЖЕН быть написан как для самолёта.
Пока вы этого не поймёте, не прочувствуете - вас нельзя допускать к образованию в области программирования.

К сожалению, о замене мыслительного процесса речь вообще не идёт.

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

Говорите о себе в единственном числе!

С этим можно было бы согласиться, но, как говорится, есть нюансы.

В том числе:
1) Понимание. У меня было написано целое учебное пособие о типовых ошибках и трудностях в программировании. Опыт преподавания вчерашним школьникам выявил, что они не понимают многих вроде бы элементарных вещей (что такое переменная и т.п.). Без этого понимания они будут падать ВСЕГДА.

2) Желание. Если не хочет - упадёт один раз и бросит. И к другим вещам по жизни отношение будет таким же.

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

Верно.
Но если не решить хотя бы указанные выше проблемы - не получится вообще ничего!

Знаете, что вы делаете рассуждениями о "праве ребёнка на ошибку"?
Вы снимаете с себя ответственность как минимум за вышеперечисленные пункты!

Но что вы будете делать потом, когда ребёнок использует своё право на ошибку - и не научится?

Не передергивайте. Я и так говорю о себе. Прочитайте предложение еще раз медленно: "Ситуация напоминает..." к Вам не относится, т.к. применимо исключительно к одному определенному лицу, автору. Вот уж не думал, что придется еще и семантику разъяснять.Вы смешиваете понятия. В музыке, в спорте, в танцах дети не работают с шаблонами. Что-то отрабатывается до автоматизма, но не так, чтобы рука бойца, например, двигалась в узком туннеле. Они там тоже ошибаются, и Учитель может им указать на ошибки, они могут разобраться в них вместе и преодолеть, сделав опытом.Укажите на моё сообщение, где я писал, что проблемы не нужно решать?
Вы вербализуете собственные страхи. Ответственность учителя остается всегда, позволяет учитель ошибаться, или не позволяет. Разговор шел не об ответственности учителя, а о потенциале технологии. Уберете возможность ошибаться - отвалится важный компонент обучения.

Везде работают с шаблонами.
В перечисленном шаблоны даже более жёсткие.

Это не так.
Весь смысл данного разговора в том, где и чему именно следует обучаться.
Можно (и, вероятно, даже полезно) обучить всему с нуля.
Скажем, взять камень, методом проб и ошибок аккуратно подвести к тому, чтобы ученик додумался привязать его к деревянной палке, и только потом в награду дать "профессиональный" молоток.
Какой процент учеников успешно пройдут такое обучение?

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

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

Вот о чём идёт речь, когда обсуждаются необходимые свойства того же Дракон-редактора.

В этом подходе есть логика, и она не противоречит моей идее: Пусть редактор обеспечивает безошибочность опционально. Если понадобилось, то можно безошибочность отключить.

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

Бездоказательно. На мой взгляд, я вполне услышал вашу позицию, и даже осознал точки соприкосновения с моей.Это логично, т.к. мне важно выяснить конкретный вопрос. Остальное может быть учтено, но мой вопрос для меня важнее.Если чужие мысли подтверждают мои собственные, почему бы нет. Имею право, не находите?
Обратимся к определению термина "фанатизм" - "Крайняя нетерпимость, свойственная фанатикам." (Источник определений: "Oxford Languages")
Вики: "Различие между фанатиком и поклонником видится в том, что поведение фанатика рассматривается как нарушение преобладающих социальных норм, тогда как поклонник эти нормы не нарушает (хотя его поведение и может казаться странным)" (Thorne, Scott; Bruner, Gordon C. An exploratory investigation of the characteristics of consumer fanaticism (англ.) )

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

ПС: И что интересно, даже не оффтоп, т.к. ошибочные рассуждения налицо.

Да вот же:
И так постоянно: красную часть вы опускаете, как будто её и нет, а на зелёную что ж не ответить.
Стандартная демагогия фанатически верующего.

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

Предметная дискуссия с таким оппонентом невозможна.
Хотя бы и именно потому, что он игнорирует нелицеприятные тезисы.
Не отвергает аргументированно, а просто игнорирует.

И это после того, как ему развернули в обсуждении все аспекты проблемы, и указали на возможные последствия, и дали рекомендации.
Всё напрасно.