DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 15:06

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




Начать новую тему Ответить на тему  [ Сообщений: 3 ] 
Автор Сообщение
СообщениеДобавлено: Вторник, 18 Декабрь, 2018 13:25 

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


Цитата:
Здравствуйте, Владимир Данилович!

Я уже и до этого понял, что Дракон имеет определённую популярность. Очень коротко мой отзыв:

Действительно, графическое представление очень эффективно. Но есть определённые проблемы.

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

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

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

Для текстов это тоже важно, но требование менее жёсткое.

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

Т.е. в любом случае, неудобство от чтения графа через маленькое окошко может оказаться серьёзнее, чем неудобство от чтения текста через такое же окошко.

Именно по этой причине я не люблю работать с графическими представлениями.

Например, в СУБД есть средства рисования графов. Они становятся неудобны, когда количество таблиц достигает десятка. Или нужен экран размером со стену.

Т.е., может быть, что время графического представления ещё не пришло (ведь сегодня стало модно иметь доступ ко всему даже через смартфон с крошечным экраном).

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

Широкий экран позволяет работать с различиями более-менее эффективно - текст в две колонки помещается.

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

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

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

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

Конечно, для текста этого удобства вообще нет, так что это не особо важное замечание.

С другой стороны, если мы привыкли к удобству, его поломка будет приводить к более заметному провалу эффективности труда и к бОльшему дискомфорту, чем если у нас есть изначально неудобный текст.

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

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

3. Текстовая информация в каждом блоке имеет разное количество букв. Соответственно, получаем тяжёлый случай многоколоночной вёрстки. В этой ситуации требование на то, чтобы граф помещался на экран и был нормализован, ещё утяжеляется.

Таким образом, графическое представление блестяще справляется в одних местах и ковыляет в других.
Текст же не хватает звёзд с неба, но более-менее равномерно справляется с разными классами задач.

4. Есть ещё один аспект - текст универсален. Его можно скопировать в любой другой текстовый редактор.

Графы не столь универсальны. Из одной программы в другую просто так граф не скопируешь.

Поэтому, если с текстом мы можем работать множеством разных инструментов, для графа мы привязаны к одному "родному". Это резко снижает выбор доступных средств.

5. Касаемо конкретно Дракона. Он не является ЯП в полном смысле слова, например, нельзя определить переменную.

Если мы хотим говорить о Драконе как о полноценном ЯП, а не как о части гибридного ЯП, то нужно расширить нотацию.

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

Правда, здесь тоже не всё "Слава Богу", потому что современные IDE и так уже занимают весь экран и им не хватает.

Т.е. графическое представление будет здесь лишь одним из окон, которое конкурирует за место на экране с другими окнами.

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

6. Это уже не критика, а скорее возможность для дальнейшего развития. Если уж мы за графику, то логика - это не всё, что нужно представлять графически.

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

7. Если говорить о языке медицины, то мне кажется, Вы несколько искажаете терминологию.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Декабрь, 2018 14:36 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
1-й ответ на критику

Денис Будяк писал(а):
1. Графическое представление хорошо, когда его можно окинуть взглядом зараз. Т.е. граф, который полностью помещается на экран или лист бумаги. В случае текста это тоже важно.

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

Это не так.
Первое. Дракон-схема по высоте может и должна помещаться на экран. Это достигается с помощью специальных приемов, позволяющих дробить ветки и повысить понятность веток.

См. главу 31. "Как повысить понятность веток" стр. 377-392
https://drakon.su/_media/biblioteka/01._uchis_2.pdf

Второе. По горизонтали Дракон-схема может быть широкой. Например, дракон-схема может иметь до 50 веток. Каждая ветка содержит в среднем 12 икон. (Данные предоставил Сергей Ефанов).

Значит, надо иметь горизонтальный скроллинг, прокручивание схемы по горизонтали.

НЕ ТРЕБУЕТСЯ вертикальный скроллинг и масштабирование.
То есть нужна всего ОДНА степень свободы, а никак не ТРИ.

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

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

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

2) Нет необходимости разбивать дракон-схемы на куски, помещающиеся на экран.

3) При выпуске бумажной документации необходимо разбивать чертежи дракон-схем на части согласно нормативам ЕСКД. Двадцатилетняя практика использования языка ДРАКОН в НПЦАП им. Пилюгина с учетом требований нормализационного контроля показала, что проблемы при этом не возникают.

У Ефанова в большой дракон-схеме 48 веток, 607 икон, 12, 6 икон на ветку


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Комментарий Сергея Ефанова

Сергей Ефанов писал(а):
Дискутировать не буду, поделюсь только своим опытом больбы с громоздкостью Дракон схем.
Если их рисовать так, что схему нужно прокручивать влево-вправо, и вверх-вниз, то это ОЧЕНЬ плохо.

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

В итоге, известное правило "алгоритм должен умещаться на одном экране" у меня трансформировалось в "ветка должна умещаться на одном экране.

Этого достаточно для работы с любым алгоритмом.

Потому что всё равно я не смогу анализировать алгоритм "в целом". Я его буду "есть по частям".

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

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

Тем самым мне вообще без разницы, какой ширины получается схема.

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

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


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

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


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

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


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

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