DRAKON.SU

Текущее время: Четверг, 17 Июнь, 2021 11:31

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




Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
СообщениеДобавлено: Воскресенье, 17 Май, 2015 22:15 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
Сегодня я заглянул в "подвал" экрана, чтобы посмотреть, есть ли посетители на нашем форуме. Я увидел нечто удивительное.
Цитата:
Кто сейчас на конференции
Сейчас этот форум просматривают: Владимир Паронджанов и гости: 20

Это значит, что сегодня 15 мая 2015 года в 23.15 по Москве на форуме присутствовали 20 гостей. Я вижу такие цифры впервые.

Поздравляю всех друзей ДРАКОНа!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 20 Май, 2015 18:09 

Зарегистрирован: Четверг, 10 Январь, 2013 16:59
Сообщения: 70
Владимир Паронджанов писал(а):
на форуме присутствовали 20 гостей.

Поздравляю всех друзей ДРАКОНа!


    Поздравления - это уместно ... если не забывать о недостатках:

1.
Насколько авторитетны те гости? Форум до сих пор вообще не имеет инструментальных средств для оценки профессионализма и нравственности.

Часто, читая здесь сообщения, возникает инстинктивное желание поблагодарить какого-либо автора. И не нахожу соответствующей кнопочки! :( ))

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

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


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

Спорить о недостатках сейчас нет сил и времени. Если мой пост мешает, просто удалите его.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 20 Июнь, 2015 12:22 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
__1__ писал(а):
Дракон имеет уйму недостатков... , причём, некоторые из них фундаментальны ... Спорить о недостатках сейчас нет сил и времени.

Какие недостатки имеются в виду?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 20 Июнь, 2015 13:27 

Зарегистрирован: Четверг, 23 Май, 2013 05:13
Сообщения: 400
__1__ писал(а):
Дракон имеет уйму недостатков... , причём, некоторые из них фундаментальны. А это значит, что без усилий программиста(ов), и без внесения теоретических поправок в Ваши книги Дракон уже сейчас смотрит в тупик, и будет заменён аналогами (скорее всего, иностранными), как только они появятся.

Спорить о недостатках сейчас нет сил и времени. Если мой пост мешает, просто удалите его.

Можно не спорить. Можно просто их перечислить.
Вот С.Митькин очень хорошо перечислил достоинства Дракона: http://forum.oberoncore.ru/viewtopic.php?p=90639#p90639
Я этот текст без изменений часто использую в материалах по Дракону.
Если Вы приведёте свой список недостатков и он будет таким же понятным и наглядным, то готов использовать его в дальнейшем как конструктивную критику, над которой надо работать.
Честное слово: альтернативное аргументированное мнение всегда очень полезно и интересно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Август, 2015 15:28 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
Лично я вижу недостаток Дракона в том, что на нем можно отобразить любой неструктурный алгоритм. Таким образом, язык Дракон содержит в себе аналог goto, который много раз критиковали.


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
Rifat писал(а):
недостаток Дракона в том, что на нем можно отобразить любой неструктурный алгоритм

Рифат, это совсем не так. Правила Дракона ЗАПРЕЩАЮТ изображать "любой неструктурный алгоритм".

Ваша ошибка в том, что Вы мыслите в рамках текстового программирования. И полагаете, что постулаты текстового программирования вечны и неизменны.

Но это не так. Сейчас развивается визуальное программирование. Правила структурного текстового программирования неоптимальны для визуального программирования.

Поэтому пришлось создать новые правила — правила структурного программирования для визуального случая. На эту тему Илья Ермаков написал статью:
Цитата:
Ермаков И. Е., Жигуненко Н. А. Двумерное структурное программирование; класс устремлённых графов. (Теоретические изыскания из опыта языка «ДРАКОН»). — М.: МГУ им. М. В. Ломоносова, 2010. — С. 452—461. — (Сборник трудов V Международной конференции «Инновационные информационно-педагогические технологии в системе ИТ-образования»).
http://2010.it-edu.ru/docs/C4/a4a%20Ермаков%20И.Е1287620722076198.doc


Подробнее см. здесь


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Август, 2015 16:46 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
Не соглашусь с вам. В силуэте можно произвольно назначать адреса для перехода веткам, таким образом, это является аналогом goto, а то, что при этом схема не содержит пересекающихся прямых, то это и является небольшим облегчением при рассмотрении алгоритма, но не является фундаментальным свойством структурности самого алгоритма.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Август, 2015 17:05 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
Rifat писал(а):
Не соглашусь с вам. В силуэте можно произвольно назначать адреса для перехода веткам, таким образом, это является аналогом goto, а то, что при этом схема не содержит пересекающихся прямых, то это и является небольшим облегчением при рассмотрении алгоритма, но не является фундаментальным свойством структурности самого алгоритма.


В силуэте НЕЛЬЗЯ назначать произвольные адреса. Можно лишь назначать разрешенные адреса. Число разрешенных адресов равно числу веток.

При использовании goto Вы можете прыгнуть в ПРОИЗВОЛЬНУЮ точку. В силуэте этого сделать никак нельзя.
Разрешенные адреса позволяют перейти только в начало ветки. И больше никуда.

=================

Рифат, Вас интересует доказательное программирование, цель которого — исключить ошибки.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Август, 2015 17:16 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
Формулировка была не совсем точна, пусть нельзя прыгнуть в любую точку, но можно прыгнуть в начало ЛЮБОЙ ветки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Август, 2015 17:52 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
Rifat писал(а):
Формулировка была не совсем точна, пусть нельзя прыгнуть в любую точку, но можно прыгнуть в начало ЛЮБОЙ ветки.
Рифат, Вы частично правы.

Вы полностью правы в том, что можно прыгнуть в начало ЛЮБОЙ ветки. Впрочем, нет. Не любой ветки, а только ветки данного силуэта. Адрес не может указывать на ветку ДРУГОГО силуэта.

Почему ВЫ частично правы? Потому что goto имеет два недостатка:
1. goto может осуществить переход в ЛЮБОЕ место.
2. goto можно вставить в ЛЮБОЕ место;

Рифат, Вы не упомянули о том, что икону "Адрес" ДРАКОНа нельзя вставить в ЛЮБОЕ место (и в этом второе отличие от goto).

Но это не все мои аргументы. Иконы "Имя ветки" и "Адрес" находятся на самом виду. Они под неусыпным контролем.

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

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

Цитата:
Начиная с 1970-х годов оператор безусловного перехода goto оказался в центре систематической и всевозрастающей критики. Неправильное и необдуманное использование оператора goto в исходном тексте программы приводит к получению запутанного, неудобочитаемого «спагетти-кода». По тексту такого кода практически невозможно понять порядок исполнения и взаимозависимость фрагментов.

Впервые эта точка зрения была отражена в статье Эдсгера Дейкстры «Оператор Go To считается вредным»[9][3]. Дейкстра заметил, что качество программного кода обратно пропорционально количеству операторов goto в нём. Статья приобрела широкую известность, в результате чего взгляды на использование оператора goto были существенно пересмотрены.

В работе «Заметки по структурному программированию»[10] Дейкстра обосновал тот факт, что для кода без goto намного легче проверить формальную корректность.

Код с goto трудно форматировать, так как он может нарушать иерархичность выполнения (парадигму структурного программирования) и потому отступы, призванные отображать структуру программы, не всегда могут быть выставлены правильно. Кроме того, оператор goto мешает оптимизации компиляторами управляющих структур[11].

Некоторые способы применения goto могут создавать проблемы с логикой исполнения программы:

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

Передача управления внутрь тела цикла приводит к пропуску кода инициализации цикла или первоначальной проверки условия.

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

Доводы против оператора goto оказались столь серьёзными, что в структурном программировании его стали рассматривать как крайне нежелательный.

Это нашло отражение при проектировании новых языков программирования. Например, goto запрещён в Java и Ruby. В ряде современных языков он всё же оставлен из соображений эффективности в тех редких случаях, когда применение goto оправданно. Так, goto сохранился в Аде — одном из наиболее продуманных с точки зрения архитектуры языков за всю историю[12].

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



Цитата:
Структурное программирование призвано, в частности, устранить беспорядок и ошибки в программах, вызванные трудностями чтения кода, несистематизированным, неудобным для восприятия и анализа исходным текстом программы. Такой текст нередко характеризуют как «спагетти-код».

Спагетти-код (spaghetti code) — плохо спроектированная, слабо структурированная, запутанная и трудная для понимания программа, содержащая много операторов goto (особенно переходов назад), исключений и других конструкций, ухудшающих структурированность[8]. Самый распространённый антипаттерн программирования.

Спагетти-код назван так потому, что ход выполнения программы похож на миску спагетти, то есть извилистый и запутанный. Иногда называется «кенгуру-код» (kangaroo code) из-за множества инструкций jump.

В настоящее время термин применяется не только к случаям злоупотребления goto, но и к любому «многосвязному» коду, в котором один и тот же небольшой фрагмент исполняется в большом количестве различных ситуаций и выполняет много различных логических функций[8].

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

Вся эта аргументация о вреде goto справедлива.
Но эта аргументация не имеет никакого отношения в Дракону.

Аргументы против goto никак не компрометируют Дракон.
Они про совсем другие недостатки.

Рифат, разве не так?


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

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
В Драконе возможно многое из того, что может делать обычный goto. Если все операторы алгоритма разместить по разным веткам, по одному оператору на ветку, то можно переходить с одной ветки на другую произвольным образом. Затем, если этот алгоритм перерисовать в виде обычной блок схемы, то наглядно будет видно, что алгоритм неструктурный.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Август, 2015 21:36 

Зарегистрирован: Четверг, 10 Январь, 2013 16:59
Сообщения: 70
Rifat писал(а):
Лично я вижу недостаток Дракона в том, что на нем можно отобразить любой неструктурный алгоритм. Таким образом, язык Дракон содержит в себе аналог goto, который много раз критиковали.

И не лень было критиковать? :) ...

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 31 Август, 2015 18:59 

Зарегистрирован: Четверг, 10 Январь, 2013 16:59
Сообщения: 70
Шилин Александр писал(а):
__1__ писал(а):
Дракон имеет уйму недостатков... , причём, некоторые из них фундаментальны. Спорить о них сейчас нет сил и времени.

Можно не спорить. Можно просто их перечислить.
Вот С.Митькин очень хорошо перечислил (Изображение) достоинства Дракона. Я этот текст без изменений часто использую в материалах по Дракону.
Если Вы приведёте свой список недостатков и он будет таким же понятным и наглядным, то готов использовать его в дальнейшем как конструктивную критику, над которой надо работать.
Честное слово: альтернативное аргументированное мнение всегда очень полезно и интересно.

http://intbpro.ru/hard-soft/FlowCharts/post-288.htm (чтобы там прочитать длинный пост, надо его развернуть, кликнув по стрелочке ⇩ в его шапке)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Сентябрь, 2015 10:24 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
Цитата:
По этой ссылке и Митькин в одном месте схалтурил: думаю, что далеко не всем было понятно, что такое «общая судьба» нескольких элементов.

1. Слово "схалтурил" здесь неуместно и вводит в заблуждение.

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

3. Приведу примеры.

— Все иконы "имя ветки" в данном силуэте должны иметь общий вертикальный размер НЕЗАВИСИМО от числа строк текста внутри иконы.

— Все иконы "адрес" в данном силуэте должны иметь общий вертикальный размер НЕЗАВИСИМО от числа строк текста внутри иконы.

И наоборот, разная высота указанных икон МЕШАЕТ зрительному восприятию, создает впечатление разнобоя и как бы ЗАТУШЕВЫВАЕТ неоспоримое функциональное единство указанных элементов горизонтального зрительного ряда.

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

5. Правило общей судьбы по пункту 3 в программе DRAKON Editor выполняется. Это хорошо.
А в программе ИС Дракон — не выполняется. Это плохо.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

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


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

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


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

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