DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 20:09

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




Начать новую тему Ответить на тему  [ Сообщений: 376 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8 ... 19  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 14 Март, 2008 11:38 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Что-то я не припомню, чтобы я такое доказывал. Вообще эта мысль сформулирована непонятно.

Это было на Королевстве Дельфи, где Вы оспоривали необходимость какого-либо формального описания (спецификации) графики, говоря, что каждая конкретная программа графич. "программирования" - сама себе спецификация.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Март, 2008 00:28 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Для повышения "производительности и безошибочности" нужно повышения уровня абстракции. Выше 3GL-языка (поясню во избежание споров, что ФП я тоже подразумеваю в этой группе) без потери универсальности повышать, в общем, этот уровень особенно некуда. А в конкретных аспектах (например, описание архитектуры или параллелизма) - да, резерв ещё есть. Вполне возможно и даже скорее всего, что графика здесь окажется полезной. Но это будет именно графический язык, под которым будет лежать вполне формальное, математическое основание. Эргономика и соображения "юзабилити" могут и должны накладываться сверху, но только сверху. Построить хороший инструмент, идя только со стороны его пользователя, а не от задачи и её формализации, невозможно.


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Март, 2008 07:43 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 53
Сергей Прохоренко писал(а):
Поскольку со второй частью вполне справляются 3GL-языки, то теперь надо обратить внимание на первую часть - на эргономику - она "слабое место".
Вероятно не так хорошо, как хотелось бы. Впрочем в этой теме обсуждается не эргономика, а язык. Если Вас интересует интерфейс, то видимо этот интерес здесь не будет удовлетворен, если только почему-то кто-то не решит его здесь удовлетворить. Кстати, сам по себе вопрос действительно заслуживает прояснения. А обсуждение его здесь будет уводить в сторону от задуманного Паронджановым выяснения применимости свойств разработанных схем к практике конструирования и распространения визуальных алгоритмов. В данном аспекте мне интересно, действительно ли они в существующих реализациях редакторов отвечают требованиям спецификации Дракон, или же разработки опирались на собственный взгляд на эти спецификации. В последнем случае ничем кроме пропаганды, указанные спецификации не являются.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Март, 2008 12:51 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 234
Откуда: Украина, Киев
Сергей Прохоренко писал(а):
Цитата:
Блок-схемы ничуть не более наглядны, а проблем с их построением, редактированием и отображением в ограниченном пространстве - сколько угодно. Блок-схемы - это позапрошлый век графического интерфейса.

На самом деле Дракон очень мало имеет общего с "привычными" блок-схемами.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Март, 2008 17:13 

Зарегистрирован: Среда, 19 Март, 2008 23:02
Сообщения: 2
Собственно, я по-спринтерски читал эту книгу, пока не остановился в шестой главе на четвертом рисунке. Я посмотрел на трубу, которая соединяла внизу "джампы". Туда что-то падало, труба направлялась наверх и соединяла адреса. И всё понял.

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

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

ВОт отсюда мой вопрос В.П. Что можно предложить для двумерного представления структур данных? Как визуально связать двумерные структуры данных с двумерными структурами исполняемого кода? Реально остаться в 2D?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Март, 2008 19:03 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
В этом сообщении изложена Часть 4.
Примерно через десять дней последует Часть 5, в которой я продолжу отвечать на вопросы и критические замечания.

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

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

Илья Ермаков Среда, 18 Июль, 2007 23:42

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

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

Уважаемый Илья! В Вашем комментарии я выделил для себя фразу: «Неужели что-то GOTO-подобное? Но как-то не вяжется с общей идеологией языка…». Именно эту фразу я попытаюсь прокомментировать.

Согласен, что оператор GOTO при неразумном употреблении может привести к неприятностям.
Но давайте сделаем «диковатое» предположение. Давайте вообразим, что у нас в руках волшебная палочка, которая гарантирует, что в данной программе GOTO ни при каких обстоятельствах не может вызвать ошибку. Проще говоря, волшебная палочка дает 100%-ю уверенность, что GOTO полностью безвреден. Кроме того, волшебная палочка делает оператор GOTO невидимым (для прикладного программиста). Как будто его (оператора GOTO) и вовсе нет.
При таком «диковатом» предположении становится совершенно безразлично, есть GOTO в программе, или он в ней отсутствует. Это значит, что в рамках моего предположения у нас нет никаких оснований испытывать «священный трепет» перед оператором GOTO.

Что же является волшебной палочкой, которая исключает ошибки при использовании GOTO? Такой палочкой служит дракон-редактор, который на 100% исключает ошибки подобного рода.
Предлагаемая мной «волшебная палочка» вовсе не является экзотическим исключением. В самом деле, после трансляции стандартных структурных конструкций (if—then—else, while—do, repeat—until и т.д. мы обнаружим в ассемблерной программе немало операторов перехода (о существовании которых многие программисты даже не догадываются). Прелесть в том, что эти операторы, будучи скрыты от программиста, не приносят никакого вреда.
Чтобы сделать эту мысль более убедительной, приведу заключительную часть главы 16 из моей книги (стр. 264—266)

Почему самолет не машет крыльями?

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

Поясним сказанное. При визуальном структурном программировании программист работает только с чертежом программы, не обращаясь к ее тексту, подобно тому, как программист, работающий, скажем, на Паскале, не обращается к ассемблеру и машинному коду — они для него просто не существуют!
Это значит, что столь тщательно обоснованная Дейкстрой коллекция ключевых слов структурного кодирования (if, then, else, case, of, while, do, repeat, until, begin, end [2]) при переходе к визуальному программированию становится ненужной — для программиста она просто перестает существовать! В равной степени становятся лишними и отмирают и другие ключевые слова, используемые оппонентами Дейкстры в различных вариантах расширения структурного кодирования: goto, continue, break, exit и т. д.

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

Предвижу возражения: хотя названные ключевые слова действительно исчезают, однако выражаемые ими понятия сохраняют силу и для визуального программирования. Например, две видеопрограммы на рис. 27 можно построить с помощью понятий if-then-else и goto. Данное возражение нельзя принять, поскольку произошла подмена предмета обсуждения. С помощью указанных понятий можно построить не видеопрограммы, а текстовые программы, эквивалентные видеопрограммам на рис. 27.

Что касается собственно видеопрограмм, то они, будучи “выполнимой графикой”, строятся из “выполняемых” икон и “выполняемых” соединительных линий. Причем — подчеркнем еще раз — в процессе построения (которое реализуется с помощью ДРАКОН-редактора) пользователь не применяет понятия if-then-else и goto, ибо в этом нет никакой необходимости.

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

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

Очевидно, что использование понятий, выражаемых ключевыми словами классического структурного программирования, не является самоцелью, а служит лишь для того, чтобы “делать наши программы разумными, понятными и разумно управляемыми” [22]. Указанные понятия решают эту задачу не во всех случаях, а только в рамках текстового программирования.

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

Поэтому высказываемое иногда критическое замечание: “недостаток шампур-метода в том, что он не удовлетворяет требованиям структурного программирования” является логически неправомерным. Нельзя упрекать самолет за то, что он не машет крыльями.

ВЫВОДЫ

    1. Визуальное структурное программирование (шампур-метод) и текстовое структурное программирование несоизмеримы (в куновском смысле слова), они опираются на разные системы понятий, которые по-разному расчленяют действительность.
    2. Текстовое структурное программирование решило стоявшие перед ним исторические задачи, исчерпало свои эвристические возможности и, выполнив свою миссию, потеряло актуальность. В настоящее время точкой роста научного знания является визуальное структурное программирование.
    3. При использовании шампур-метода набор ключевых слов классического структурного программирования становится ненужным. Благодаря этому создаются предпосылки, которые в будущем, возможно, позволят исключить ключевые слова и тем самым устранить путающий всех разнобой ключевых слов и структурных конструкций в разных языках программирования.
    4. В отличие от текстового структурного программирования шампур-метод является полностью формальным.
    5. По эргономическим показателям визуальное структурное программирование существенно превосходит свой текстовый аналог.
    6. Широко распространенное мнение о несовместимости блок-схем и структурного программирования является мифом, нелепой ошибкой, основанной на невнимательном прочтении классической работы Э. Дейкстры “Заметки по структурному программированию”.
    7. Дальнейшее использование неструктурных, неформальных и неэргономичных блок-схем во всех случаях следует признать нецелесообразным.
    8. Существующая литература по блок-схемам, включая международные и национальные стандарты, на 99% устарела.
    9. Современные стандарты на блок-схемы объективно содействуют снижению качества соответствующей интеллектуальной продукции. Указанные стандарты игнорируют три важнейших принципа: структуризации, формализации и эргономизации.
    10. Актуальной задачей является разработка новой системы международных и национальных стандартов на блок-схемы, свободных от перечисленных недостатков. В основу проекта новых стандартов целесообразно положить изложенные в этой книге правила визуального структурного программирования. Дракон-схемы наследуют все или почти все достоинства блок-схем и устраняют их недостатки.

Конец цитаты из книги Паронджанова

AVC Пятница, 29 Февраль, 2008 15:10

Владимир Паронджанов писал: «Конструкция на рис. 26б не считается «структурной управляющей конструкцией». Поэтому она запрещена.

AVC возражает: А так ли это?
Насколько я понимаю, речь идет о рисунке справа на стр.116.
Вот я пишу

Код
if C or D or E or F or G or H then
B
else
A
end;

и получаю те же 2 ветки, что и на указанном рисунке.

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

Уважаемый AVC! Большое спасибо за Ваш вопрос. Он особенно дорог тем, что имеет предельно КОНКРЕТНЫЙ характер. Именно такие вопросы, как Ваш, позволяют наглядно продемонстрировать особенности Дракона.
Теперь по существу. Прежде всего, скажу, что, я, к сожалению, не могу с Вами согласиться. Причину изложу в виде 5 пунктов

:arrow: Пункт 1. Сделаем обратное преобразование — преобразуем Ваш код в графическую форму. Ваша схема будет существенно отличаться от моего рисунка.
В самом деле, на рисунке справа на странице 116 имеются 6 икон «вопрос». А в Вашей схеме только одна икона «вопрос».
На рисунке справа на странице 116 имеются 6 развилок. А в Вашей схеме только одна развилка. Так что налицо важное графическое отличие.
Правда, с логической точки зрения обе схемы эквивалентны. Это, конечно, хорошо. Но этого мало.

:arrow: Пункт 2. Схемы бывают не только хорошие (понятные), но и плохие (непонятные). При сравнении графических схем важна не только логика, НО И ЭРГОНОМИКА. А с эргономической точки зрения две рассматриваемые схемы различаются, как небо и земля. Ваша схема ТРУДНЕЕ для понимания. А схема на рисунке справа на странице 116 НАМНОГО ЛЕГЧЕ ДЛЯ ВОСПРИЯТИЯ (говорю не экспромтом, а на основании обширного многолетнего опыта).

Задача языка Дракон — выразить заданное смысловое содержание как можно проще. Чтобы было понятно даже ежу. Это значит: надо стремиться к тому, чтобы дракон-схемы были понятны не только программистам, но и непрограммирующим специалистам. Чтобы они могли проектировать алгоритмы по принципу «программирование без программистов».

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

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

:arrow: Пункт 3. Но это не все. Предлагаемое Вами логическое выражение
C or D or E or F or G or H, с логической точки зрения, является безукоризненно правильным.
Но, если мы хотим облегчить работу непрограммирующего специалиста, читающего или пишущего алгоритм или программу, мы должны позаботиться о нем. И убрать с его дороги все коварные ловушки, рытвины, буераки и колдобины.

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

Чтобы выявить суть возникающей здесь эргономической проблемы, я ввел понятие «главный вопрос условного оператора» (см. стр. 159—164 моей книги).
Главный вопрос — это тот самый вопрос, который мы пишем в иконе «вопрос» и на который надо ответить «да или «нет». Этот вопрос желательно записывать в явном виде — четко, ясно и недвусмысленно.
Если мы пишем в иконе вопрос логическое выражение, мы тем самым уничтожаем главный вопрос. Он исчезает, ускользает, улетучивается. И это плохо. (Подробнее см. главы 9 и 10 моей книги).

:arrow: Пункт 4. Еще одна немаловажная деталь. Рисунок справа на странице 116 отличается высокой степенью абстракции. Поэтому он допускает двоякое толкование. До сих пор я придерживался того толкования, которое (на вполне законном основании) выбрал уважаемый AVC.

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

Чтобы устранить двоякое толкование, надо на рисунке справа на странице 116 добавить слова «да» и «нет». Сделать это можно двумя способами.

1-й способ [«да» справа (6 раз), «нет» снизу (6 раз)]. Именно этот способ выбрал уважаемый AVC.

2-й способ [«да» снизу (6 раз), «нет» справа (6 раз)].

В последнем случае уважаемый AVC написал бы свой код по-другому:

Код

if C and D and E and F and G and H then
A
else
B
end;

Такой способ является более предпочтительным, так как схема описывается по стандартному правилу слева направо (сначала А, потом В).

:arrow: Пункт 5. Если строго соблюдать правило слева направо, то графические формулы для конъюнкции и дизъюнкции приобретают строго определенное, раз навсегда заданное графическое начертание (см., например, рис. 56 справа и рис. 59 справа.
Это значит, что бросив беглый взгляд на дракон-схему, мы сразу видим, где схема «И», а где схема «ИЛИ».



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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Март, 2008 21:27 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 189
Откуда: Россия, Санкт-Петербург
Хорошо излагаете. Даже захотелось написать ДРАКОН-редактор для Оберона.
Книга где-то есть в электронном свободном доступе?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Март, 2008 22:25 
Модератор
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Март, 2008 22:27 
Модератор
Аватара пользователя

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

"Как улучшить работу ума" - есть вот здесь:
http://www.transhumanism-russia.ru/docu ... a_Word.rar


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 14:05 

Зарегистрирован: Пятница, 21 Март, 2008 11:23
Сообщения: 4
Во-первых я восхищен ДРАКОНом, будучи сторонником визуальных методов.

Но по прочтении ".. улучшить работу ума" возникли вопросы.

Введено смутное понятие "эргономика" как почти ключевое.
Не является ли это квазирешением? Вместо одной проблемы - другая.
Почему не надо пересечений - эргономичнее, а что такое эргономичнее...

Отсутствие пересечений и (см. Рис.13) для распутывания всего одного пересечения получаем усложнение схемы.
А как усложнится, если по логике задачи требуется, например, ввести связь с G на F?
Требование отсутствия пересечений понятно и позитивно без сомнения, но вот бы без фанатизьма так же как уже требование сортировки...
Допустить одно пересечение на тридцать(?) элементов с его спецобозначением?

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

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

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

Ещё раз выражаю поддержку.
Этот твердый, талантливо поданый шаг вперед в визуальных методах.
И харизма налицо, и флаги яркие :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 14:11 
Модератор
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 18:20 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 112
Откуда: Беларусь, Минск
Александр Ильин писал(а):
Хорошо излагаете. Даже захотелось написать ДРАКОН-редактор для Оберона.
Книга где-то есть в электронном свободном доступе?
Я ещё не читал книгу, но всё-таки берут сомнения, что получится написать простой и полный транслятор с языка программирования, отрицающего подход Дейкстры на язык, максимально его поддерживающий.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 18:52 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 20:35 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Зачем ДРАКОНУ две головы?

Хороший рекламный лозунг. Самое главное, что обращается он не к уму, а к чувствам. Которые в основном и рулят хомо сапиенсом, несмотря на всю его сапиенсность.
Цитата:
Вы правы. Язык программирования — ваш враг.
Но ДРАКОН — не язык программирования.
ДРАКОН — ваш друг

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

Сначала нужно:
- составить программу действий (разложить всю последовательность действий по полочкам, детализировать описание до команд исполнителя) (1);
- записать программу действий на понятном для исполнителя языке (2).

Например, исполнитель=ЭВМ, языки={имеющиеся на данный момент текстовые языки}. В основном эти языки ориентированы на исполнителя - ЭВМ (так уж сложились обстоятельства из взаимного развития). Программист (в смысле Автора) - тот кто знает и понимает свойства специфического* исполнителя-ЭВМ, а следовательно, хорошо усваивает (ориентированный на ЭВМ) язык и, т. о. может записать (2) программы для ЭВМ.

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

Если же "не-программисту" дать в руки спец. набор команд конкретного исполнителя (например, ракетного двигателя) и язык ДРАКОН (ориентированный не на ЭВМ, а на человека => легко изучаемый) для записи последовательности действий из этих команд, то получаем лозунг "ПРОГРАММИРОВАНИЕ БЕЗ ПРОГРАММИСТОВ". Не забываем при этом об (1) (без чего никакой ДРАКОН не поможет).

Теперь, возьмём исполнитель=человек. Новый рабочий на заводе. Набор команд = действия с токарным станком. Опытный рабочий должен объяснить ему, как выточить деталь (задача-цель: получить деталь, программа: последовательность операций с токарным станком, записанная на русском языке или ДРАКОНЕ или...).
Цитата:
Отсутствие удобного языка для описания структуры деятельности сильно затрудняет обучение. Многие важные сведения вообще не зафиксированы в документах и передаются как эпос по принципу "из уст в уста".
Однако, однако. Прежде чем записать программу (2) её надо составить (1). Вполне может оказаться, что опытный рабочий не в состоянии это сделать, и, скорее всего, он использует принцип: "смотри на меня, делай как я". Если так, то опять же, и ДРАКОН не помошник. А ведь составление такой программы даёт нам ПРОГРАММИРОВАНИЕ БЕЗ КОМПЬЮТЕРА.

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

При этом, я понимаю программирование здесь в широком смысле, когда исполнитель={человек, ЭВМ, ...} и когда основная цель обучения - научить (1), что, на мой взгляд можно записать и так:
Цитата:
! решение учебных задач: обучение навыкам алгоритмизации, программирования и автоформализации знаний в предельно сжатые сроки
Считаю, что именно так трактовал программирование и Ершов, говоря "программирование - вторая грамотность". И врят ли Автор не знал этого, или хотя бы не догадывался.

Не хорошо извращать хорошие принципы ради собственной выгоды (рекламы ДРАКОНА). Хорошие вещи не рекламируют. Они сами говорят за себя - "СПРАВКА О СОСТОЯНИИ ДЕЛ".

P.S. Не порознь, а вместе. Не две головы, которые смотрят на 90% и на 10%, а одна, которая смотрит на всех. ДРАКОН, как более "эргономичный" язык, вполне может способствовать лучшему и скорейшему воплощению слов Ершова на практике.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 21:46 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Андрей КСП писал(а):
А ветка это не эквивалент процедуры?
А петля силуэта это не аналог шинной архитектуры, когда топология с пересечиниями "распиливается" на вызов набора процедур (входы веток с возвратом в подвал)?

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


Мне кажется, что "ветка" вполне может быть выражена примерно такой конструкцией:
Код:
PROCEDURE Branches …

CASE state OF
“0”: Branch0
| “1”: Branch1

| “N”: BranchN
ELSE RETURN
END

PROCEDURE Branch0 …

state := “1”

Branches
END

PROCEDURE Branch1 …

state := “2”

Branches
END

PROCEDURE BranchN …

state := “z”

Branches
END


Таким образом, "ветка" есть элемент процесса, состоящий из трех частей:
1. Вызов "ветки", соответствующей состоянию
2. Шаг алгоритма BEGIN ... END, содержащийся в "ветке"
3. Проверка состояния

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 22:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей, ну да, про что и сказано уже сто раз - конечный автомат. Вы написали как раз его реализацию на Обероне.
Только ветки в Драконе гораздо значимее - они к тому же выполняют декомпозицию процедуры на логические части и позволяют одним взглядом на шапку эти части вычленить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 22:52 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Илья Ермаков писал(а):
Сергей, ну да, про что и сказано уже сто раз - конечный автомат. Вы написали как раз его реализацию на Обероне.
Только ветки в Драконе гораздо значимее - они к тому же выполняют декомпозицию процедуры на логические части и позволяют одним взглядом на шапку эти части вычленить.


Я считаю, что шапка в Драконе имеет два существенных недостатка:
1. Не позволяет изобразить больше, чем 10 состояний (Ширина листа/видимой области экрана ограниченна, поэтому состояния лучше задавать в форме списков - одно под другим.)
2. Возможные переходы между состояниями заслоняются содержимым "веток" (Лучше содержимое веток скрывать "по умолчанию" с возможностью отображения, когда это необходимо. Но для этого нужен не графический язык, а графический интерфейс программирования. Либо содержимое веток должно описываться в другом месте - отдельно от описания переходов между состояниями.)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 23:05 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Короче, уже наворотов не хватает. Шо хоть у человеков такая любовь сразу искать, чего доклепать для собственного счастья... которое почему-то связано с удовлетворением бурной фантазии . :-)

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

Не обижайтесь, это общие мысли, не личное ни в коем случае.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Март, 2008 23:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
1. Не позволяет изобразить больше, чем 10 состояний (Ширина листа/видимой области экрана ограниченна, поэтому состояния лучше задавать в форме списков - одно под другим.)

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

Цитата:
2. Возможные переходы между состояниями заслоняются содержимым "веток"

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Март, 2008 12:18 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Евгений Темиргалеев писал(а):
Считаю, что именно так трактовал программирование и Ершов, говоря "программирование - вторая грамотность". И врят ли Автор не знал этого, или хотя бы не догадывался.
Вот и подтверждение из 18 главы:
Цитата:
Уместно привести мнение академика А. Ершова: “Человек неизмеримо усилит свой интеллект, если сделает частью своей натуры способность планировать свои действия, вырабатывать общие правила и способ их применения к конкретной ситуации, организовывать эти правила в осознанную и выразимую структуру, — одним словом, сделается программистом”. Ясно однако, что задача улучшения работы ума должна решаться не только применительно к программистам, но и к миллионам других людей.
"Ясно однако", что Ершов говорил о всех, а не о "касте программистов".

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

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


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

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


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

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


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

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