Денис Будяк.
Конструктивная критика языка ДРАКОНЦитата:
Здравствуйте, Владимир Данилович!
Я уже и до этого понял, что Дракон имеет определённую популярность. Очень коротко мой отзыв:
Действительно, графическое представление очень эффективно. Но есть определённые проблемы.
1. Графическое представление хорошо, когда его можно окинуть взглядом зараз. Т.е. граф, который полностью помещается на экран или лист бумаги. В случае текста это тоже важно.
Но когда граф перестаёт помещаться на экран, то нужно прокручивать в двух измерениях и масштабировать. Т.е. сразу получаем три степени свободы.
С т.з. простоты и удобства просмотра это гораздо сложнее, чем только прокручивать текст "сверху вниз". Поэтому для графического представления критично разбивать алгоритмы на куски, помещающиеся на экран или другой носитель.
Для текстов это тоже важно, но требование менее жёсткое.
Может быть, если сделать стандарт, по которому графы будут иметь фиксированную ширину, разница уменьшится. Хотя всё равно, в графе вверх и вниз за границу экрана может уходить N стрелок, а в случае текста - лишь один поток текста.
Т.е. в любом случае, неудобство от чтения графа через маленькое окошко может оказаться серьёзнее, чем неудобство от чтения текста через такое же окошко.
Именно по этой причине я не люблю работать с графическими представлениями.
Например, в СУБД есть средства рисования графов. Они становятся неудобны, когда количество таблиц достигает десятка. Или нужен экран размером со стену.
Т.е., может быть, что время графического представления ещё не пришло (ведь сегодня стало модно иметь доступ ко всему даже через смартфон с крошечным экраном).
Ситуация усугубляется такими задачами, как сравнение версий. Для текста кое-как выработаны программы, подобные windiff, которые показывают две версии текста рядом и цветом выделяют изменения.
Широкий экран позволяет работать с различиями более-менее эффективно - текст в две колонки помещается.
Как сравнивать два графа? Операция сравнения - это одна из ключевых операций в развитии сложных проектов, от её эффективности напрямую зависит безошибочность всей деятельности по поддержке и развитию.
Если их уменьшить, текст в квадратах станет нечитаемым и будет постоянное увеличение-уменьшение масштаба пользователем. Очень неэффективная операция.
2. По мере развития продукта, как этот граф будет эволюционировать? Сила графического представления во многом (как я думаю) основана на том, что человек запоминает общий вид графа и знает, где находятся те или иные части.
Если же продукт меняется, то и вид графа будет меняться. Сейчас мерчендайзеры в магазинах взяли моду всё время переставлять товары. Идёшь в молочный отдел - а там колготки женские. Соответственно, если у нас есть стандарт качественного размещения (нормализации) графа, каждое изменение будет приводить к перевёрстке графа и бить по производительности труда читающего.
Конечно, для текста этого удобства вообще нет, так что это не особо важное замечание.
С другой стороны, если мы привыкли к удобству, его поломка будет приводить к более заметному провалу эффективности труда и к бОльшему дискомфорту, чем если у нас есть изначально неудобный текст.
Связанный с этим вопрос - как эффективно и автоматически верстать графовое представление.
Потому что для текста автоматическая вёрстка тривиальна, а для графа это целая задача, на которую можно непроизводительно тратить время, если она решается вручную. Может быть, эта задача уже решена вашими коллегами - я в это не вникал.
3. Текстовая информация в каждом блоке имеет разное количество букв. Соответственно, получаем тяжёлый случай многоколоночной вёрстки. В этой ситуации требование на то, чтобы граф помещался на экран и был нормализован, ещё утяжеляется.
Таким образом, графическое представление блестяще справляется в одних местах и ковыляет в других.
Текст же не хватает звёзд с неба, но более-менее равномерно справляется с разными классами задач.
4. Есть ещё один аспект - текст универсален. Его можно скопировать в любой другой текстовый редактор.
Графы не столь универсальны. Из одной программы в другую просто так граф не скопируешь.
Поэтому, если с текстом мы можем работать множеством разных инструментов, для графа мы привязаны к одному "родному". Это резко снижает выбор доступных средств.
5. Касаемо конкретно Дракона. Он не является ЯП в полном смысле слова, например, нельзя определить переменную.
Если мы хотим говорить о Драконе как о полноценном ЯП, а не как о части гибридного ЯП, то нужно расширить нотацию.
Другой вариант - если речь пойдёт о двухоконном интерфейсе, когда слева мы видим текст программы, а справа текущая строчка показывается в том логическом квадрате, к которому она относится.
Правда, здесь тоже не всё "Слава Богу", потому что современные IDE и так уже занимают весь экран и им не хватает.
Т.е. графическое представление будет здесь лишь одним из окон, которое конкурирует за место на экране с другими окнами.
Здесь нельзя говорить о графическом языке программирования, а лишь можно говорить о графическом представлении текста, помогающем понять этот текст. Ведь текст отображает смысл программы целиком, а сгенерированная Дракон-диаграмма - лишь логическую структуру, т.е. она неполна.
6. Это уже не критика, а скорее возможность для дальнейшего развития. Если уж мы за графику, то логика - это не всё, что нужно представлять графически.
Структура связей модулей, отношения между сущностями, потоки данных и серверы - всё это требует своей нотации и такая нотация в западных аналогах есть.
7. Если говорить о языке медицины, то мне кажется, Вы несколько искажаете терминологию.
Язык всё же предназначен для речи, т.е. для линейного изложения. Представьте себе хирурга, который делает операцию. Рот у него свободен, а нарисовать Дракон-диаграмму ему нечем, т.к. руки заняты.
Я согласен, что дракон-схемы могут помочь в медицине, но это не язык, а что-то иное. Я бы аккуратнее обходился на Вашем месте с терминологией в этом случае.
8. Я думаю, что Вы захотите ответить на критику.
К сожалению, я всё время в жёстком цейтноте, поэтому смогу отвечать только маленькими порциями. Что касается русификации, я пока по сути не смог сделать достаточно хорошее обоснование для реформы ИТ в плане русификации,
Оказывается на это нужно очень много времени и много знаний из совершенно разных областей. Я всё это делаю в любительском режиме и это может затянуться на годы. Поэтому сейчас идёт обдумывание, как поступить дальше.
Вы уже оказали содействие информацией про русскоязычность программ для ракет, написанных с применением Дракона. Если Вы можете помочь чем-то ещё, то чем?