DRAKON.SU

Текущее время: Понедельник, 25 Март, 2019 06:23

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




Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Среда, 25 Апрель, 2012 09:09 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4053
Откуда: Москва
На сайте OberonCore есть форум "О зашоренности".
Хвост этого форума по инициативе Петра Алмазова посвящен Дракону.

Даю ссылку на сообщение Петра Алмазова и последующие
viewtopic.php?p=72346#p72346

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Апрель, 2012 09:51 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Петр был остроумен - ему оставался только 1 шаг до фразы:
"Сторонники Дракона - когнитивные кроты".

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Апрель, 2012 10:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Ну, если снять излишнюю грубость формулировок - то можно извлечь из сказанного вполне практическое замечание. Что пользоваться императивными (декларативными и иными частными представлениями) нужно не просто, чтобы перевести ЕЯ-текст в схему и на этом остановиться. Но чтобы переходить на более глубокие уровни формализации - математический и далее. Но что-то подобное и делал, скажем, Эдуард... так что всех и в любых случаях обвинять в "когнитивной слепоте" не следует... А в данном случае, есно, такой шаг сделал-то уже Степан и сейчас...


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

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Решил прокомментировать следующее замечание TAU:

Цитата:
TAU
 Заголовок сообщения: Re: О зашоренности
Добавлено: Среда, 25 Апрель, 2012 20:00 

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

Да, ненаглядным. А вы что же - будете называть черное белым (набор из сотен мелких значков на экране - наглядным)?

Peter Almazov писал(а):
Если все это растянуть по вертикали

Согласитесь, что это - уже заметное преобразование.

Peter Almazov писал(а):
обвести в рамочку и соединить их вертикальными линиями

Здесь уже получается принципиально иной объект, нежели текст, разве нет?


Удалось случайно выделить день для просмотрщика и вот что получилось
(конечно недоделка, но это сейчас не важно):

Код:
АЛГОРИТМ.3 заголовок
   * цикл-силуэт
      * если ветка = 1
         * делаем что-нибудь  РИС.12
         * ветка := 2
           qqqqqqqqqqqqqq
           wwwwwwwwwwwwwwww
           eeeeeeeeeeeee
      * иначе если ветка = 2
        эта ветка очень важна для
        понимания алгоритма !
         * бъем баклуши
         dddddddddddddddddd
         aaaaaaaaaaaaaa
         * ветка := 3
      * иначе если ветка = 3
         * бъем баклуши
         * ветка := 4
      * иначе если ветка = 4
         * бъем баклуши
         * ветка := 5
      * иначе если ветка = 5
         * бъем баклуши
         * ветка := 0
      * конец
   * конец цикла-силуэта   
   * выход
КОНЕЦ АЛГОРИТМА

Вложение:
dal2view.JPG
dal2view.JPG [ 77.31 КБ | Просмотров: 8602 ]


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
А чем Вам замечание TAU не нравится (шутка :))?
Как раз Ваш пример показывает всё то же - "когнитивная слепота" не в том, что в принципе пытаются получать граф-схему (в частности, императивную на техноязыке) по тексту. А в том, что при этом игнорируют тот факт, что эта схема уже есть представление обычно более формальное. Об этом хорошо сказал в своё время А. Куликов:
...
Многим ДРАКОН не нравится, потому что на нем трудно описать мысли запутавшегося в задаче. ДРАКОН требует искать условие, отвечать, и строить правильное ветвление логики. Но наши легионеры привыкли из логической структуры делать слипшиеся спагетти. Как же это понравится человеку, который как и всякий бурбакист, гордится, что у него ни одного геометрического чертежа, а всё получилось манипуляциями с символами. И при этом через три месяца он не может пояснить того, что же хотел сказать, когда писал этот кусок кода.
...
Ряд вещей в том же посте вызвали, скажем так, вопросы - посему пришлось разобрать здесь: viewtopic.php?p=66483#p66483. Но вот с этим согласен.

И это как раз ещё к непренебрежимости уровнями процесса формализации/моделирования (чем у нас, как обнаружилось по любезному указанию В.Д., и академики, по-видимому, пренебрегать пытаются - см. здесь: viewtopic.php?p=69519#p69519 :))... Среди которых есть уровни информатически строгие - рассчитанные на исполнителя типа "языковая машина", деятельность которого есть алгоритмический процесс.
    Конкретно - Куликов прямо указывает, что само приложение техноязыка как системы записи импер-части отчуждаемого знания, более формальной, чем естественный язык, уже выводит сочинителя на более строгую формализацию. Где надо "вытащить из текста алгоритм/систему взаимодействующих алгоритмов". А одновременно - также "вытащить" систему определений объектов (как абстрактных/"конкретных" типов). И определение исполнителя алгоритмов над объектами... Т.е., то, что у Кауфмана в Гл. 3 - абстракции операций, данных и связывания для планирования деятельности исполнителя. Образующие целостный базис. И требующие, между прочим, не игнорировать текст как разметку схемы, а наложить на него некие требования строгости, адекватные строгости, налагаемой формализованным графом как основой схемы...

А когда дело ограничивается этим:
Peter Almazov в viewtopic.php?p=72346#p72346 писал(а):
... все это растянуть по вертикали, каждый абзац обвести в рамочку и соединить их вертикальными линиями,...
- то степень "незапутанности" начинает определяться текстом вершин (и рёбер, если предусмотрена их содержательная разметка).
И может получиться, что цель формально-графового представления, сформулированная здесь:
Илья Ермаков в viewtopic.php?p=72439#p72439 писал(а):
...

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

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

У Вас, Дмитрий, в примере производящий язык для схемы - псевдокод. Т.е. адекватный по строгости. Там и алгоритм уже "вытащен", и состав объектов, и "репертуар" действий (проверять величины на равенство, делать что-нибудь и бить баклуши). Здесь многообразие уже сведено к трактовке конкретным исполнителем в конкретной ситуации действия "делать что-нибудь". :) Очевидным исполнителем является человек. Если мы полагаемся на его здравый смысл - то такое многобразие допустимо. Иначе следует формализовать более строго смысл уже этого действия. Что, очевидно, приведёт к частной модели его как алгопроцесса... :)

В общем, сочинитель д.б. незашорен на том, чтобы просто "разнести неформальный текст по вершинам". А д.б. готов сразу идти дальше по уровням формализации. Тогда "когнитивной слепоты" не будет. И, между прочим, выявится то самое, о чём говорил Куликов - что сама попытка "разнести" у нормально мыслящего человека выявит направления уточнения представления о предмете... Между прочим, как раз через подведение его под систему тех самых паттернов. Взятых либо поодиночке, либо, если ограничиться импер-частью отчуждаемого знания - в композиции цепочек/циклов (даже без ветвлений - согласно теореме Бёма-Джакопини :)). А среди одиночных паттернов ведущим будет как раз цикл Дейкстры (ну и Ваш ЦС-эквивалент, который снова использован в примере).

М.б. в силу сходного понимания Пётр Алмазов и не сделал шаг до высказанного Вами утверждения... :) А указал некие условия, при коих "любитель Дракона" "демонстрирует пример когнитивной слепоты".

И тут сказанное, что:
Дмитрий_ВБ в viewtopic.php?p=72370#p72370 писал(а):
... в таких условиях вопрос стандартизации текстовой формы техноязыка, в том числе для записи декларативных знаний, по-прежнему остается актуальным.
- важно. Тока стандартов-то д.б. семейство - как минимум из классов "родных" и "программных". Не говоря уже о том, что формы записи деклар-части - это вообще отдельный род графических языков. Описания на которых, конечно, связываются с техноязыковыми... И за ними тоже должны свои паттерны стоять... У меня были сформированы конкретные предлжения - но всегда интереснее познакомиться с конструктивом от других...


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

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Цитата:
Владислав Жаринов пишет:
У Вас, Дмитрий, в примере производящий язык для схемы - псевдокод. Т.е. адекватный по строгости. Там и алгоритм уже "вытащен", и состав объектов, и "репертуар" действий (проверять величины на равенство, делать что-нибудь и бить баклуши).

Псевдокод у меня в примере приведен для простоты.
Меня, естественно, интересует более практический аспект:

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

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


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Как раз у Ильи можно найти выход на такой способ. В сказанном, что "... для задач, которые стали обыденными, есть стремление к снижению многообразия способов выразить идею". Только распространить это с "эволюции инженерных инструментов" на эволюцию предмета инженерии. И тогда получится та самая технология формализации "от эскизной к детальной", которая обсуждалась ещё в этой теме...
И также уточнить, что здесь "становление обыденности" есть именно уточнение понимания предмета. В частности, и под влиянием использования более формальных инструментов.

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

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

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


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Peter Almazov писал(а):
Если им дать простой текст из нескольких абзацев, то они, как минимум, сочтут его ненаглядным, а то и вовсе непонятным. Если все это растянуть по вертикали, каждый абзац обвести в рамочку и соединить их вертикальными линиями, то они начинают восторгаться.

Хорошая критика. В качестве конструктивного зерна предлагаю извлечь:
1. ФАКТОР(байт) = <число байт текста в Дракон-редакторе> / <число байт инвариантной/сгенеренной программы>
2. ФАКТОР(время) - <время отрисовки Дракон-схемы в редакторе> / <время набора программы в текстовом редакторе>
можно брать методики оценки Дж.Раскина по временам работы графического интерфейса.

А потом оценить редакторы и кодогенераторы.


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

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Дмитрий Дагаев писал(а):
2. ФАКТОР(время) - <время отрисовки Дракон-схемы в редакторе> / <время набора программы в текстовом редакторе>

Я бы предложил оценивать время разработки алгоритма.
Но не знаю : ) как это сделать.
Поскольку дважды в одну реку не зайти ...


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

Зарегистрирован: Среда, 30 Сентябрь, 2009 14:45
Сообщения: 10
Ильченко Эдуард писал(а):
Я бы предложил оценивать время разработки алгоритма.
Но не знаю : ) как это сделать.
Поскольку дважды в одну реку не зайти ...

21 студент и 4 задачи.
1. 20 студентов решают задачу 1 методом Текст.
2. 20 студентов решают задачу 2 методом Граф.
3. Разбиваем студентов на две группы по 10, уравнивая результаты по обоим методам.
4. Группа 1 решает задачу 3 методом Текст и задачу 4 методом Граф.
5. Группа 2 решает задачу 4 методом Текст и задачу 3 методом Граф.
6. Студент-психолог по своим стандартным методикам считает вашу реку.
(кстати, ему это можно пустить курсовичком)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Оценки сложности формализации
СообщениеДобавлено: Четверг, 03 Май, 2012 14:39 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Ну, по-простому уже предыдущий оратор показал, как. А общие принципы ИП-экспериментов можно найти у Смирнова и Тинькова здесь: viewtopic.php?p=57423#p57423. Но, как я подозреваю, Вы не о столь масштабном думали... :) Так что конкретнее можно поступить, как говорил Лаптев: viewtopic.php?p=71345#p71345. Т.е. надо, чтобы была возможность сбора статистики рабты с приложением (в данном случае - и на время, а не только на действия).

Но. Есть и факторы субъективные, не сводимые к метрикам "в попугаях". Уже писал об этом:
Владислав Жаринов в viewtopic.php?p=45991#p45991 писал(а):
...
Оцениваются же трудозатраты, как обычно, такими показателями:
    * норма времени на изготовление (здесь - двуединый процесс оформления-досочинения дракон-схемы по первоначальной задумке) - о сущности и значении этого фактора хорошо сказано у Грабина (можно посмотреть выдержку в этом сообщении).
    * сложность изделия (здесь - не когнитивная, а структурно-элементная);
    * сложность техпроцесса изготовления.
Норма времени в конечном итоге определяется сложностью обеих родов, но опосредованно - работник может по разным техпроцессам уложиться в норму на одно и то же изделие, но затратить разные усилия.
Сложность оценивается как субъективно, так и объективно (насколько возможно). Существуют способы нормирования времени изготовления от сложности программ - хотя бы методики Б. Боэма - где, кстати, есть что-то и о блок-схемах. Однако нужно развивать это для визуализации - и тогда важно иметь качественное представление о сложности именно полноценных информоделей деятельности.
...

Владислав Жаринов в viewtopic.php?p=56089#p56089 писал(а):
...
Видно, что среда рассматривалась с экономических позиций - т.е. как любой инструмент (точнее, как спецоснастка для техпроцесса визуализации знаний на станке типа "Интел-ИБМ-МС|Wine" ;)). И первым критерием здесь было - сокращает ли эта оснастка сложность работы, уменьшает ли усилия человека (не сводимые только ко внешней характеристике - норме времени, в которую можно уложиться, напр. "в приказном порядке", но слишком дорогой ценой - от чего призывает уходить и Паронджанов, говоря об "интеллектуальном терроризме")?
...

Потому там рядом с "Методами ИП" и Бестужев-Лада рулит...

И о метрике кода. Во-первых, надо понять - число байт текста на каком языке записи? Видимо, на том самом стандартном, о котором Дмитрий_ВБ говорит? и который сначала ещё д.б. реализован "каждой лошадью, участвующей в забеге"?.. :)
Во-вторых - есть "хитрости" формального синтаксиса (на котором можно стандарт определить). Которые я понял уже по Свердлову - а потом нашёл подтверждение у Мейера (Гл. 11 - в выдержки не вошла). Он там как раз пишет, что нужно корректно строить определение грамматики, чтобы использовать его как меру сложности языка.


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Теперь - к более практическим аспектам.
Тут говорилось о стандартах на языки для гибридизации (фактически - и для "реверсного" представления в редакторах-трансляторах). Возникает вопрос - что будем брать за основу? Если учесть сказанное о реалистичной сущности "когнитивной слепоты" - то вырисовывается такой состав текстовых языков:
    * неформальный, "эскизный", уровень - "родные" типа языков пошагового уточнения, перечисленных в этом подразделе - но с фиксацией структуры текста, примерно как здесь задано;
      Определение ЯПУ по Потопахину (неформальное) можно найти в его "Решении...".
    * уровень спецификаций - типа Д-языка, описанного в выдержке здесь (п. 3.3.1);
    * уровень программирования - Promela+never-LTL - то же самое, что Д-язык, только с параллелизмом и программизмом (и с явными БП - чтоб никому не обидно...). :wink:

К первым двум уровням надо как раз ту самую деклар-часть, о которой Дмитрий_ВБ говорил. Третий - полноценный ЯП, но со слабой системой типов данных. Так что надо ещё в текстовом виде "скрестить"... ну хотя бы с О-07... :) Получится нечто вроде языка для структурного редактора В. Лаптева.

На уровне спецификаций можно ещё что-нибудь ФП-шное взять. Думается, Степан с его опытом реализации в DE мог бы предложить определение.

Какие ещё будут мнения?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оценки сложности формализации
СообщениеДобавлено: Четверг, 03 Май, 2012 15:45 
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оценки сложности формализации
СообщениеДобавлено: Четверг, 03 Май, 2012 15:53 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Сергей Прохоренко писал(а):
...
Современные алгоритмы включают в себя гораздо более сложные вещи, чем просто передача управления от одного оператора к другому, которое можно изобразить линией на блок-схеме. Пример - присвоение значений переменной процедурного типа (только вчера увидел у сына - студента). Передача управления в этом случае происходит скрыто - на уровне ассемблера. Линией на блок-схеме это не изобразишь. Никаких специальных выразительных средств для таких операторов Дракон не имеет,...
Ну, обычный техноязык - возможно. Но его можно и расширить на ассемблер... типа как здесь...
Кстати, Вы, наверное, о чём-то типа агентов/делегатов? У Мейера в Гл.17 это неплохо объяснено... и оттуда можно извлечь идеи схемного представления. Только там понятно другое - не что линией это не изобразишь, а что к графу только императивному (т.е. дракон-схеме) не сведёшь...
Сергей Прохоренко писал(а):
...
Кстати, создатели Дракона не задумывались над обратной задачей: генерировать дракон-схемы по коду на ЯВУ - в качестве иллюстрации при головоломной передаче управления? Обычные блок-схемы генерятся - я сам такую программку опробовал. Иллюстративные возможности Дракона не грех использовать, в отличие от попыток программировать непосредственно на Драконе. Эта задача проще, так как блок-схема не обязана быть однозначно понятной компьютеру. Лишь бы человек разобрался.
Да вот уже задумываются: viewtopic.php?p=72498#p72498.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Май, 2012 15:58 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Владислав Жаринов писал(а):
Так что надо ещё в текстовом виде "скрестить"... ну хотя бы с О-07... :) Получится нечто вроде языка для структурного редактора В. Лаптева.


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


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Я уже так и вижу, как в ответ кто-то из "поклонников Дракона" пишет: "а вот, например, в PureBuilder..." и далее следует какой-нибудь образец спецпропаганды... вроде разобранного здесь или здесь... :wink:
А если серьёзно и сохраняя нейтральность - то Вы утверждаете всё-таки не то, что имели в виду сторонники техноязыка. И это как раз можно показать, привлекая эквивалентные текстовые языки. Т.е. нормальная визуализация - это не просто "обведение текста рамочками". Это как вначале "просто текст" перевести на более формальный язык. Скажем, ЯПУ Потопахина. В результате чего в нём появляется структура. Выраженная ключевыми словами (если мы выявляем структуру в импер-части - то маршрутными). И остальной текст становится более строгим. Потому что начинает играть роль атрибутов структурных элементов.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Май, 2012 17:32 
Аватара пользователя

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

Только боже упаси реализовывать преобразование "иллюстрация на Драконе" -> "исходный код, в т.ч. в структурном редакторе", при котором пару раз пересаженная лиана приведет к полной кастрюле GOTO-лапши в исходном коде.


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

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 28
Откуда: Ленинград, Емельянов Алексей Николаевич
Сергей Прохоренко писал(а):
... Но собственно визуальная часть в Драконе гораздо беднее по возможностям и менее эргономичная, чем, например, в PureBuilder.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Май, 2012 09:05 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 82
Откуда: Москва
Axcel писал(а):
Сергей Прохоренко писал(а):
... Но собственно визуальная часть в Драконе гораздо беднее по возможностям и менее эргономичная, чем, например, в PureBuilder.


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


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Май, 2012 09:53 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Сергей Прохоренко писал(а):
Для решения задачи преобразования "исходный код, в т.ч. в структурном редакторе" -> "иллюстрация на Драконе" можно в исходный язык программирования добавить конструкцию "комментированный блок". Тогда при указанном выше преобразовании всякие ненужные подробности исходного кода превратятся в соответствующий комментарий в рамочке, а студенткам, о которых писал В.Лаптев, станет понятен алгоритм в списанной у однокурсников лабе. :D
Не знаю уж, как работают студентки у кого, но мне довелось поставить эксперимент, где этот фактор как раз исключился: viewtopic.php?p=40397#p40397. Результат приводил здесь. Так уж получилось, что девушки (некоторые) лучше всех справились (в т.ч. ребят). И не у кого было им списывать (кроме Паронджанова :) ).
Почему так? Уже Валерий говорил: viewtopic.php?p=57317#p57317 - в силу образности мышления.
В то же время, как можно видеть, результат "сырой". О причинах этого тоже сказано: viewtopic.php?p=64991#p64991. И выводы были сделаны - приведены здесь: viewtopic.php?p=65075#p65075 (а реализованы ещё раньше).

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

Не понял, что за комментированный блок. Свёртывать можно и саму запись - как текстовую, так и граф-базированную. Впрочем, они д.б. "двумя сторонами одной медали" (т.е. вьюшками от одного файла проекта). Как, скажем, в "Ракетном дизайнере кода"...

Т.о. студентки не только списывать могут... но и сделать нечто, что студентам впору списать... :wink: Главное - чтобы удобно думать было... в частности, и по форме...

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


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

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


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

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


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

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