DRAKON.SU

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

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




Начать новую тему Ответить на тему  [ Сообщений: 58 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 12:59 

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

В любом случае, если мы говорим об эргономичности. То неструктурные схемы не являются эргономичными, мое мнение такое.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 13:10 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Спасибо Рифату, LKom и Алексею за картинки.

Рифат! В чем Вы видите недостаток этой последней схемы? Я очень заинтересован в том, чтобы понять ваши аргументы. Я понял, что эта схема Вам не нравится, но не понял почему.

Желательно не употреблять слова структурный - неструктурный.
Есть ли какие-то аргументы, которые можно привести, не употребляя этих слов? Или таких аргументов нет?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 13:10 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Rifat писал(а):
неструктурные схему не являются эргономичными
Ну а попробуйте сделать этот алгоритм эргономично! То есть учитывая, что действия должны быть именно такими.
Для этого можно использовать хорошо известные способы преобразования схем, при которых в данном случае неизбежно появится дублирование одного из действий.
Дублирования можно избежать, вынося его в третье измерение - в отдельный алгоритм и делая на преобразованной схеме две вставки:
Вложение:
тест1.png
тест1.png [ 6.4 КБ | Просмотров: 13266 ]

Ну и чем это стало эргономично? Увы, ничем. Стало только хуже.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 13:47 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
Владимир Паронджанов писал(а):
Спасибо Рифату, LKom и Алексею за картинки.

Рифат! В чем Вы видите недостаток этой последней схемы? Я очень заинтересован в том, чтобы понять ваши аргументы. Я понял, что эта схема Вам не нравится, но не понял почему.

Желательно не употреблять слова структурный - неструктурный.
Есть ли какие-то аргументы, которые можно привести, не употребляя этих слов? Или таких аргументов нет?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 14:08 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Rifat писал(а):
Для неструктурных схем метод Хоара практически не работает
Прошу не забывать, что мы в данный момент говорим о когнитивной эргономике!
Хоар, методы доказательства и прочие высокие материи часто лично вами используются при анализе какого-нибудь рабочего кода?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 14:27 

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 14:29 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 239
Откуда: Россия, Стерлитамак
Alexey_Donskoy писал(а):
плюс выпадение из контекста при переходе к внешнему алгоритму...

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 14:43 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Rifat писал(а):
Не соглашусь с вами, что если меньше блоков на схеме, то это эргономичнее.
Эргономичнее потому, что одно действие и должно быть одно. Два прямоугольника воспринимаются как два РАЗНЫХ действия.

И более серьёзный момент: путь исполнителя кода должен проходить там, где он реально и проходит. Если мы знаем, что вот через эту ключевую точку надо пройти, вопрос решается на уровне маршрутной схемы легко.
Но если есть дублирование, то с уровня схемы приходится нырять ВНУТРЬ КАЖДОГО блока, чтобы убедиться, что это он там делает и проходит ли через ключевую точку.

Другими словами, если действие в ключевой ТОЧКЕ, то мы можем палец в неё поставить и гулять по маршруту. Что удобно.
Если точка дублируется, то нам придётся пальцы одновременно на несколько точек поставить, что неудобно. Да и пальцев (читай внимания, оперативной памяти человека) может не хватить.

adva писал(а):
Но опять же, экспериментов не то никто не ставил
Вот об этом и речь!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 14:53 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 219
Откуда: Казань
Экспериментов было довольно много. Поищите в гугле experiment structured programming.
Большинство экспериментов было в годах 70-х, 80-х (возможно есть и современные).
И подавляющее большинство экспериментов было в пользу структурного программирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 15:11 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Rifat писал(а):
Экспериментов было довольно много.
Вот так всегда. Сначала привести конкретный пример, а потом, не обращая внимания на аргументацию, высказать совсем другой тезис, к этому примеру наверняка слабо относящийся. :facepalm:

Но ещё раз напоминаю, что изначальный вопрос был не в том, чтобы рассматривать плюсы и минусы Дракона!!!
Что за свойство такое у народа - неумение сосредоточиться на теме? Или это специальный увод в сторону?

Вопрос был таков: стоит ли поддерживать закрепление Дракона в качестве стандарта?

Моё мнение: НЕТ.
Моё мнение: На основе данного опыта необходимо научное проектирование эргономичного инструмента.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 15:31 

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

Думаю, если отказаться от неструктурных схем, то ракеты будут взрываться реже, жизнь будет лучше :) хотя и будет тратится чуть больше места на экране или бумаге за счет дублирования :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 16:30 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Alexey_Donskoy писал(а):
Но ещё раз напоминаю, что изначальный вопрос был не в том, чтобы рассматривать плюсы и минусы Дракона!!!
Что за свойство такое у народа - неумение сосредоточиться на теме? Или это специальный увод в сторону?

Вопрос был таков: стоит ли поддерживать закрепление Дракона в качестве стандарта?

Моё мнение: НЕТ.
Моё мнение: На основе данного опыта необходимо научное проектирование эргономичного инструмента.

Внимательно слежу за ходом дискуссии - не встреваю пока.
Однако:
Цитата:
Но ещё раз напоминаю, что изначальный вопрос был не в том, чтобы рассматривать плюсы и минусы Дракона!!!

Вопрос был таков: стоит ли поддерживать закрепление Дракона в качестве стандарта?
Откуда взялся такой вопрос?
Из какого-то внешнего контекста?

Изначально был вопрос как раз - и он в заголовке темы:
Цитата:
Владимир Паронджанов писал(а):
Концепция Паронджанова:
достоинства и недостатки


Цитата:
Резюме:
Дракон вынесен в массы преждевременно.
Следовало бы сначала решить основную задачу силами специалистов - программистов, психофизиологов и т.д., и только потом заниматься продвижением в массы.
Пройдут годы, десятилетия, ... . :D
А хороший язык (плюсы + неизбежные минусы) будет прокисать в спорах и пререканиях (неизвестных) специалистов.
А массы будут что деталь - бить копытами? :D

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

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

И не сводить задачу структурных построений (блок-схем, например) алгоритмов
только к какому-то классу "правильных" структур.
Которые, структуры то есть, именуются "структурными" (структурами),
а все прочие структуры - "неструктурными" (структурами). :roll: :roll: :roll:

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 16:51 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
http://forum.oberoncore.ru/viewtopic.php?p=98385#p98385
Alexey_Donskoy писал(а):
Вопрос был таков: стоит ли поддерживать закрепление Дракона в качестве стандарта?

Моё мнение: НЕТ.
Моё мнение: На основе данного опыта необходимо научное проектирование эргономичного инструмента.

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

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

Но ведь - лучше синица в руках, чем журавль в небе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 16:56 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
andr писал(а):
Откуда взялся такой вопрос? Из какого-то внешнего контекста?
Вопрос взялся из всего десятка лет нашего знакомства с Паронджановым и споров на этом форуме.
Поскольку Автор предложил к обсуждению мои тезисы, я счёл себя вправе их конкретизировать.

Мне очень и очень нравится, что Паронджанов привлёк внимание общественности к вопросам когнитивной эргономики.
Очень хорошо, что он также предложил Дракон как ОДИН ИЗ ВОЗМОЖНЫХ инструментов для иллюстрации, причём достаточно проработанный на практике.

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

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

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

Цитата:
Пройдут годы, десятилетия
А это уже от нашей с вами мотивации зависит!

Цитата:
В параллельных алгоритмах одними только "структурными" структурами не обойтись.
Есть такой момент.
И есть и другие мнения на сей счёт.
У меня тут пока нейтралитет. Не зря за прошедшие два десятилетия в Software Engineering радикальных изменений не произошло, а многочисленные CASE-инструменты и методологии так и не превратились в "серебряные пули"...


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 16:58 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
http://forum.oberoncore.ru/viewtopic.php?p=98373#p98373
Самого Alexey_Donskoy давно, с 2011г., устраивает ИС Дракон.

http://forum.oberoncore.ru/viewtopic.php?p=98250#p98250
ИС Дракон устраивает сейчас и специалистов ГНЦ ФГУП "Центр Келдыша".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 30 Сентябрь, 2016 18:48 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Рифат, Вам не нравится дракон-схема Силуэт, потому что в языке ДРАКОН используется оператор goto.

Что Вы имеете в виду?

Если смотреть на Силуэт, то увидеть goto невозможно. В дракон-схеме Силуэт нет оператора goto. Совсем нет. Его нельзя увидеть даже под микроскопом.

Оператор goto отсутствует в исходном коде языка ДРАКОН (то есть он отсутствует в дракон-схеме). Он появляется только после трансляции.
В программе "ИС Дракон" он появляется только на выходе маршрутного транслятора. Таким образом, разработчик исходного кода (= разработчик дракон-схемы) не видит goto. Почему его надо бояться?

Что Вы об этом думаете?

Поясню. В текстовых языках высокого уровня рекомендуют отказаться от оператора goto в исходном коде. В исполняемом (executable) коде он все равно присутствует в том или ином виде (jump).

Но ДРАКОН визуальный язык, а не текстовый. В языке ДРАКОН в исходном коде оператор goto отсутствует.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 01 Октябрь, 2016 00:41 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
LKom писал(а):
Самого Alexey_Donskoy давно, с 2011г., устраивает ИС Дракон.
Называется "используй то, что под рукою". Не передёргивайте. На сегодня ни одна ИС меня не устраивает.

Владимир Паронджанов писал(а):
Оператор goto отсутствует в исходном коде языка ДРАКОН
"Если на клетке слона увидишь надпись "буйвол" - не верь глазам своим!"

goto там есть в самом что ни на есть явном виде - адресных переходов в силуэте.

Равно как и в неструктурных переходах предыдущего примера.

Другое дело, что я не уверен во вреде goto в рассмотренном примере :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 01 Октябрь, 2016 07:46 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Владимир Паронджанов писал(а):
Оператор goto отсутствует в исходном коде языка ДРАКОН

Alexey_Donskoy писал(а):
goto там есть в самом что ни на есть явном виде - адресных переходов в силуэте.

Равно как и в неструктурных переходах предыдущего примера.
Вы правы. Только это не исходник. Исходник — это дракон-схема. В ней goto отсутствует.

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

Маршрутную трансляцию выполняет программа "Маршрутный транслятор", предусмотренная в "ИС Дракон". Наличие "Маршрутного транслятора" — принципиальное отличие визуального языка ДРАКОН от текстовых языков высокого уровня.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 01 Октябрь, 2016 07:55 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Alexey_Donskoy писал(а):
Цитата:
Изначально был вопрос как раз - и он в заголовке темы: концепция Паронджанова: достоинства и недостатки
Вот как раз уход от вопроса, подмена тезиса.
И сформулировано-то слишком расплывчато - что значит "концепция"?
Когнитивной эргономики? Синтаксиса Дракона? Чего-нибудь ещё?
Хороший вопрос:
что означает термин "концепция Паронджанова"?

Википедия. Статья "Концепция"
[url]https://ru.wikipedia.org/wiki/Концепция[/url]
Цитата:
Конце́пция (от лат. conceptio — «понимание», «система»):

1)
Определённый способ понимания, трактовки каких-либо явлений;
основная точка зрения, руководящая идея для их освещения[1];
2)
Система взглядов на явления — в мире, природе, обществе[2];
3)
Ведущий замысел, конструктивный принцип — в научной, художественной, технической, политической и других видах деятельности;
4)
Комплекс взглядов, связанных между собой и вытекающих один из другого;
5)
Система путей решения задачи;
6)
Способ понимания, различения и трактовки каких-либо явлений, порождающий присущие только ему соображения и выводы[3].

Концепция определяет стратегию действий.

Различным концепциям соответствует свой терминологический аппарат.


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

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

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

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

У каждого обитателя этого форума есть, конечно, какие-то преставления по этому поводу,
но у каждого свои, и более или менее ясные или смутные.
Желательно было бы более или менее согласовать, что мы обсуждаем.

При этом на самом деле таких концепций может быть несколько, например:

1)
Концепция визуального алгоритмического языка Дракон
(для документирования алгоритмов и программ).
Четко выделяются две части (две стадии):
1.1)
Концепция визуального алгоритмического языка последовательных алгоритмов (и программ).
Это, безусловно, достаточно хорошо продвинутая часть.
1.2)
Концепция визуального алгоритмического языка параллельных алгоритмов (и программ):
Это значительно менее разработанная часть.

2)
Концепция некоторой эргономики - в ее реализации визуальным алгоритмическим языком Дракон.

3)
Концепция продвижение языка Дракон в народные массы
(и некоторые их частные группировки - например в медицине).

--------------------------
У кого будут предложения по этому поводу.
И что может подсказать нам сам автор "концепции Паронджанова".



=========================
Интересная информация из философской энциклопедии - для формирования концепции:
[url]http://dic.academic.ru/dic.nsf/enc_philosophy/2537/КОНЦЕПЦИЯ[/url]

Цитата:
КОНЦЕПЦИЯ (от лат. conceptio — схватывание) — термин философского дискурса, который выражает
или акт схватывания, понимания и постижения смыслов в ходе речевого обсуждения и конфликта интерпретаций,
или их результат, представленный в многообразии концептов, не отлагающихся в однозначных и общезначимых формах понятий.

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

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

Концепции коррелируют не с объектами,
а с вопросами и с ответами, выраженными в речи,
и смысловыми “общими голосами”, признаваемыми участниками диалога.

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

===============
Теперь появилась новая морока:
что такое "концепт" как устойчивое смысловое сгущение ... . :shock:
Википедия, стья "Концепт"
[url]https://ru.wikipedia.org/wiki/Концепт[/url]
В частности:
Цитата:
Концепт — инновационная идея, содержащая в себе созидательный смысл;
Продукт, демонстрирующий эту идею, называют концепт-продукт,
то есть выпускаемая производителем в единственном экземпляре модель,
предназначенная для демонстрации общественности.
Пример: концепт-кар.

Цитата:
Концепт в концептно-ориентированном программировании — конструкция,
состоящая из одного класса объектов и одного класса ссылок.


Последний раз редактировалось andr Суббота, 01 Октябрь, 2016 08:35, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 01 Октябрь, 2016 08:32 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Владимир Паронджанов писал(а):
Исходник — это дракон-схема. В ней goto отсутствует.
Ещё раз.
Аналог goto в визуальных языках - это:
а) разрыв маршрутной линии;
б) соединение нескольких линий в общую шину.


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


andr писал(а):
Хороший вопрос: что означает термин "концепция Паронджанова"?
Меня это мало интересует в контексте данной темы, ибо подмена тезиса.
Смотрим ещё раз исходный вопрос:

Владимир Паронджанов писал(а):
В сообщении viewtopic.php?p=98333#p98333 Alexey_Donskoy писал(а):
Главная заслуга Паронджанова в том, что он громко сказал и настойчиво повторяет: "Правила эргономики надо соблюдать!"

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

Желательно, чтобы участники форума высказали свое мнение о достоинствах и недостатках (или, как говорит Алексей Донской, а заслугах и бедах).

Согласны ли вы с суждением Алексея Николаевича Донского?
Или у Вас другое мнение?


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

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


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

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


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

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