Эпиграф: Нет ни одного открытия ни в технологии, ни в методах управления, одно только использование которого обещало бы в течение ближайшего десятилетия на порядок повысить производительность, надежность, простоту разработки программного обеспечения.
Очень часто при чтении работ посвященных ИТ, возникает острое ощущение, что когда-то это уже было, где-то с этим уже встречался, что-то подобное было в прошлом — девавю. Предлагаю обратить внимание на соотношение следующих процитированных ниже материалов.
С одной стороны, развитие ИТ (прежде всего аппаратуры) привело к появлению новых возможностей по реализации более сложных программных систем, нежели ранее, что, разумеется, повлекло, обусловило появление новых способов описания этой самой сложности, с которыми не могли уже справиться старые инструменты описания. Но, с другой стороны, во временном и процентном соотношении: намного ли больше дал нам, к примеру, UML сейчас, нежели раньше давали блок-схемы? Брукс в своей работе (это цитировать не буду, потому как достаточно объемно, да и скорее всего многие уже читали) указывает, что первопричину сложности (т.н. им "сущность") как-либо описать и автоматизировать в обозримом будущем не представляется возможным, есть возможности только по автоматизации акцидентной части разработки (то есть второстепенной, то есть, если очень грубо говоря, реализации с помощью конкретного инструментария уже разработанной/придуманной на первом этапе "сущности"). И блок-схемам он по сути отводит постфактум-роль даже не на этапе разработки "сущности", а именно постфактум-действие этапа реализации! Таким образом, получается, что графическое представление в программировании максимум (то есть дает 100% эффект, практически СП) пригодно только для документирования уже реализованного/готового программного кода. Далее... Есть ведь UML! Последнее время все больше и больше склоняюсь к мнению XP-шников (опять же очень грубая формулировка): если ты не можешь жить без диаграмм — рисуй, если можешь, то забудь о них, ощутимого эффекта (на порядок) ты от них не получишь. Вот и интересно соотношение пользы, которую ранее приносили блок-схемы и полезности UML сейчас.
Часть 1. Итак, примерно 1975 год. Описание действительности, предсказание будущего — по сути нашего настоящего:
Глава 16. Серебряной пули нет — сущность и акциденция в программной инженнерии
Нет ни одного открытия ни в технологии, ни в методах управления, одно только использование которого обещало бы в течение ближайшего десятилетия на порядок повысить производительность, надежность, простоту разработки программного обеспечения.
...
Графическое программирование
Излюбленной темой докторских диссертаций в программной инженерии является графическое, или визуальное, программирование — применение компьютерной графики в разработке программного обеспечения. Иногда перспективы такого подхода основываются на аналогии с проектированием СБИС, в котором компьютеры играют такую большую роль. Иногда такой подход обосновывается, исходя из того, что блок-схемы являются идеальным материалом при проектировании программ. Имеются мощные средства для создания таких блок-схем.
Ничего убедительного и удивительного из этих попыток пока не вышло, — и я уверен, не выйдет.
Во-первых, как я всюду доказываю, блок-схема является весьма слабой абстракцией структуры программы. Лучше всего это видно из попыток Беркса, фон Неймана и Гольдстайна снабдить свой предполагаемый компьютер крайне необходимым управляющим языком высокого уровня. В том жалком виде — многие страницы соединенных линиями прямоугольников, — в котором сегодня разрабатываются блок-схемы, они доказали, в сущности, свою бесполезность: программисты рисуют их после, а не до создания описываемых ими программ. Во-вторых, сегодняшние экраны имеют слишком мало пикселов, чтобы показать целиком и с достаточным разрешением сколько-нибудь подробную схему программы. Так называемая "метафора рабочего стола" становится метафорой "сиденья самолета". Всякий, кому приходилось листать пачку бумаг, будучи стиснутым двумя корпулентными соседями, почувствует разницу: одновременно можно увидеть очень немного. Настоящий рабочий стол позволяет обозревать и произвольно выбирать множество бумаг. Более того, в порыве творчества не один программист или писатель предпочитал рабочему столу более вместительный пол. Аппаратным технологиям нужно сделать очень большой наг, чтобы предоставляемый экранами обзор был достаточным для задач проектирования программ.
Если обратиться к основам, программное обеспечение очень трудно визуализировать, как я доказывал это выше. Составляем ли мы схемы управляющей логики, вложенных областей, видимости переменных, перекрестных ссылок переменных, потоков данных, иерархических структур данных или чего-то еще, они отражают лишь одно изменение взаимодействующих запутанным образом частей программной системы. Если наложить одна на другую эти схемы, отражающие взгляд с различных точек зрения, трудно извлечь из этого какую-либо общую точку зрения. Аналогия с интегральными схемами вводит, в сущности, в заблуждение: конструкция микросхемы представляет собой многослойный двумерный объект, геометрия которого отражает сущность. Программная система не является таким объектом.
Часть 2. А теперь, посмотрим, что мы имеем в этом отношении сейчас. Если отмести все различия обусловленные временными рамками, то Фаулер как будто повторяет Брукса:
UML и XP
...
Да, в ХР и UML есть несколько взаимоисключающих аспектов. Так, в ХР существенно снижается значение диаграмм. Не смотря на то, что официальная позиция ХР по этому поводу гласит: "используйте их, если это помогает вам в работе", но существует и неофициальный подтекст: "настоящий ХР-шник не рисует диаграмм". Это подчеркивается еще и тем фактом, что таким людям, как Кент, неудобно использовать диаграммы. Я, например, никогда не видел, чтобы Кент по своей воле рисовал диаграмму программного продукта, неважно даже на языке UML, или каком другом.
Я думаю, что такая ситуация возникает по другим причинам. Во-первых, одни люди считают, что диаграммы полезны, а другие придерживаются противоположного мнения. Фокус в том, что те, которые так считают, полагают, что те, которые так не считают, должны изменить свое мнение, и наоборот. Вместо этого, мы должны просто принять тот факт, что одни люди будут использовать в работе диаграммы, а другие не будут.
Во-вторых, диаграммы программных продуктов обычно ассоциируются с тяжелыми процессами разработки. В таких процессах большая часть времени уходит на построение диаграмм, что не очень помогает в работе, а иногда даже вредит. Именно поэтому я считаю, что людей нужно учить, как использовать диаграммы правильно и избегать различных ловушек, а не просто говорить "рисуй диаграмму, если тебе без нее совсем не обойтись, бедняга", как это обычно делают ярые ХР-шники.
...
Последний пункт стоит раскрыть подробнее. Когда вы занимаетесь предварительным проектированием, вы неизбежно обнаруживаете, что некоторые ваши решения неправильны. Причем обнаруживается это уже при кодировании. Разумеется, это не проблема, если вы после этого вносите соответствующие изменения. Проблемы начинаются тогда, когда вы полагаете, что с проектированием покончено, и не учитываете полученные сведения, сохраняя неверный дизайн.
Изменения в дизайне вовсе необязательно подразумевает изменения в диаграммах. Абсолютно разумным будет просто-напросто выбросить диаграмму, после того, как она помогла вам найти нужное решение. Нарисовав диаграмму, вы решили стоявшую перед вами проблему, и этого совершенно достаточно. Диаграмма и не должна существовать как некий постоянный артефакт. Надо сказать, что лучшие UML-диаграммы такими артефактами как раз не являются.
...
Кроме того, UML-диаграммы используются в качестве документации по проекту. Как правило, в своей обычной форме это модель, редактируемая при помощи некоторого CASE-инструмента. Идея здесь состоит в том, что ведение такой документации облегчает работу. На самом деле, чаще всего она вообще не нужна, поскольку:
нужно постоянно тратить массу времени, чтобы не дать диаграммам устареть, в противном случае, они не будут соответствовать программному коду;
диаграммы находятся внутри сложного CASE-средства либо в толстенной папке, и никто туда не заглядывает.
Итак, если вы хотите иметь текущую документацию по проекту, учитывайте все вышеперечисленные проблемы:Используйте только те диаграммы, которые вы можете поддерживать без особых усилий.
Помещайте диаграммы туда, где их все видят. Я предпочитаю пришпиливать их на стену. Пусть остальные рисуют на ней ручкой все простые изменения, которые были внесены в изначальный вариант.
Посмотрите, обращают ли ваши разработчики на диаграммы хоть какое-то внимание, и если нет, выбросите их.
И, наконец, последний аспект использования UML для документации — передача проекта в другие руки (например, от одной группы разработчиков другой). Согласно методологии ХР, создание документации — такая же задача, как и все остальные, а значит, ее приоритет должен быть определен заказчиком. В этой ситуации может пригодиться UML, разумеется, при условии избирательности диаграмм, которые создавались с целью облегчения коммуникации. Помните, что программный код — это основной репозиторий подробной информации, а диаграммы служат для обобщенного представления основных аспектов системы.
Здравствуйте, rsn81, Вы писали:
R>Кто дочитал до этой строчки — герой! R>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
В общем-то согласен. Я еще ни разу не видел, чтобы новомодные MDA и прочие UML-безобразия срабатывали в реальной жизни. Попытки нарисовать программу целиком в Together/Rose обычно заканчиваются полным крахом. Хотя в каких-то узких областях UML может и бывает полезен (мне говорили, что state-диаграммы из UML рулят в телекоме).
В качестве документации для архитектуры UML примерно на уровне обычных квадратиков со стрелочками — но хотя бы тут UML дает хоть какую-то стандартизацию. Но больше всего меня бесят разные "архитекторы", после которых мне достаются длинные портянки со взрывами квадратиков и стрелочек и названиями типа "Use case diagram" или "Actor Model", в которых понять ничерта нельзя. Причем обычно нарисованые совсем не по стандартам UML.
И еще чисто техническая сложность — с большими диаграммами UML сложно работать на экране монитора.
Здравствуйте, Cyberax, Вы писали:
C>В общем-то согласен. Я еще ни разу не видел, чтобы новомодные MDA и прочие UML-безобразия срабатывали в реальной жизни. Попытки нарисовать программу целиком в Together/Rose обычно заканчиваются полным крахом. Хотя в каких-то узких областях UML может и бывает полезен (мне говорили, что state-диаграммы из UML рулят в телекоме).
Диаграммы состояний рулят во всех случаях, когда состояний не слишком много и они хорошо формализованы. Обычно это что-то достаточно близкое к железу, или просто само железо. Или сервер, откликающийся на пинки клиента — если видов пинков мало, всё это хорошо помещается на экран и действительно помогает понять алгоритм/смысл работы сервера.
C>В качестве документации для архитектуры UML примерно на уровне обычных квадратиков со стрелочками — но хотя бы тут UML дает хоть какую-то стандартизацию. Но больше всего меня бесят разные "архитекторы", после которых мне достаются длинные портянки со взрывами квадратиков и стрелочек и названиями типа "Use case diagram" или "Actor Model", в которых понять ничерта нельзя. Причем обычно нарисованые совсем не по стандартам UML.
use-cases, имхо, вообще лучше текстом писать... На картинке можно только список действующих лиц отразить, а вот содержимое конкретного кейса сложно.
C>И еще чисто техническая сложность — с большими диаграммами UML сложно работать на экране монитора.
Здравствуйте, SergH, Вы писали:
SH>use-cases, имхо, вообще лучше текстом писать... На картинке можно только список действующих лиц отразить, а вот содержимое конкретного кейса сложно.
Для формулирования требований к функциональности системы показался более удобным IDEF/0, может быть ошибаюсь, но показалось, что он достигает большей конкретики при том же уровне абстракции, нежели диаграммы вариантов использования.
Здравствуйте, rsn81, Вы писали:
R>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
Sequence diagrams еще неплохи -- чуть поинформативнее "обычного" call graph'а.
Иногда я еще dataflow рисую, в "интуитивной" нотации (ну, то есть квадратик -- модуль или переменная, в зависимости от уровня детализации, стрелочка -- канал, или процедура выполняющая передачу).
ps. Помнится, когда мне нужно было разрисовать как сложным образом между собой синхронизируются много потоков (там была хитрая конструкция из очередей и пулов потоков, передающая данные из milter'а в собственные треды демона) я пришел к схеме, производной от сетей Петри.
pps. Представляю, как сейчас глумятся "хардкорные UMLщики"
Здравствуйте, Eugene Kilachkoff, Вы писали:
R>>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
EK>Sequence diagrams еще неплохи -- чуть поинформативнее "обычного" call graph'а.
О! Народ! Я знаю — вы знаете! Каким инструментом в Visio (конкретно: 2007-й) sequence diagram-ы рисовать?
А может кто знает какую доку, где подобрано общее описание инструментов и как что удобнее использовать в околософтовых рисунках? Буду страшно благодарен!
Здравствуйте, The Lex, Вы писали: R>>>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
EK>>Sequence diagrams еще неплохи -- чуть поинформативнее "обычного" call graph'а.
TL>О! Народ! Я знаю — вы знаете! Каким инструментом в Visio (конкретно: 2007-й) sequence diagram-ы рисовать?
Конкретно в 2007 не знаю, в 2003 и раньше надо было создать специальный тип диаграммы: UML diagram.
TL>А может кто знает какую доку, где подобрано общее описание инструментов и как что удобнее использовать в околософтовых рисунках? Буду страшно благодарен!
Вот тут народ, например, обсуждает.
Я вот тоже dot/xslt припахивал для анализа кода
Создаётся ощущение, что мода на UML стремительно проходит. Помниться раньше первое, что спрашивали — знаешь ли UML, используешь ли. И после ответа "понимаю, иногда полезно что бы кратко изложить идею на бумаге во время обсуждения" смотрели как на полного отморозка. Сейчас даже особо никто не спрашивает...
Я бы отвел UML скорее техническую документацию нежели конструкторскую, потому что в процессе проектирования изменять электронный вариант просто не получается, только потому что есть бумага или маркерные доски и дифицит времени. При готовом проекте иметь наглядное представление о классах и их взаимодействии и отношении нужнее всего будет, когда придется что-то менять, через некоторое время после окончания проекта. Если говорить по просту, то проще будет вспомнить за чем это так написано и почему это все работает.
Здравствуйте, Vyatsek, Вы писали:
V>Я бы отвел UML скорее техническую документацию нежели конструкторскую, потому что в процессе проектирования изменять электронный вариант просто не получается, только потому что есть бумага или маркерные доски и дифицит времени.
Да, на этапе проектирования и разработки карандаш и тетрадь или доска оказываются удобнее. А для документирования UML хорошо подходит.
Здравствуйте, VGn, Вы писали:
AN>>Да, на этапе проектирования и разработки карандаш и тетрадь или доска оказываются удобнее. А для документирования UML хорошо подходит.
VGn>А что, на доске sequence diagram уже никак не нарисовать?
Документирование это этап, результатом которого будет документация, которая останется для будущих поколений. Так что нарисовать на доске можно, если потом никто стирать не будет или если сфотографировать доску и выложить фотографию в качестве документа (такие случаи я встречал).
Интерес к UML значительно поутих после того, как выяснилось, что из неправильных картинок получаются неправильные программы.
А если по-сути, то UML вполне годится как язык диаграмм, но "рисовать все на UML" — экстремальная, а значит, дурная методология.
Рисовать нужно только то, что будет понятнее в виде диаграммы или, если диаграмма хорошо иллюстрирует текст.
А UML в данном случае хорош тем, что более-менее одинаков для всех и все его более-менее знают. Вот и все
Re: Дежавю: блок-схемы и UML
От:
Аноним
Дата:
13.02.09 13:47
Оценка:
Здравствуйте, rsn81, Вы писали:
R>Очень часто при чтении работ посвященных ИТ, возникает острое ощущение, что когда-то это уже было, где-то с этим уже встречался, что-то подобное было в прошлом — девавю. Предлагаю обратить внимание на соотношение следующих процитированных ниже материалов.
R>Кто дочитал до этой строчки — герой! R>Интересны любые мнения и ссылки (быть может, я сам сейчас написал очередной баян, очередное дежавю) по теме.
Очень интересная параллель. И место и роль этих средств в общем-то сходны.
Только рассуждение будет неполным, если не учитывать некоторые достижения в этих направлениях. Например, по блок-схемам: есть почему-то оставшийся неизвестным широкой публике труд В.Д. Паронджанова «Как улучшить работу ума». При всей претенциозности этого довольно значительного труда, в нем есть несколько совершенно замечательных идей, которые, на мой взгляд, так и не получили должного резонанса в программистском мире.
Главным же относительно обсуждаемого вопроса моментом у Паронджанова является то, что его идеи радикально изменяют место и роль блок-схем в программировании. Он показывает, что можно-таки программировать непосредственно в графике, и это не фантазии автора, а действительно реальное программирование.
На мой взгляд, беда всех этих средств (блок-схемы, UML) в непродуманности нотации (хотя Паронджанов и в рамках нотации блок-схем умудрился создать нечто значительное — путем установления ограничений), которая не дает возможности работать с насыщенными схемами – сложность восприятия растет быстрее сложности самой схемы. При малых объемах все красиво получается, но столь тривиальные вещи действительно проще сразу программировать – и так все ясно. А при росте объемов сложность составления, восприятия, осмысления схем быстро превышает тот уровень затрат, который программист, разработчик готов потратить на схему.
И вторая часть этой проблемы – практическая полезность схем, диаграмм. Если с ее помощью можно сделать только некоторый «скелет», набросок программного элемента, то совершенно очевидно, что рано или поздно встанет проблема синхронизации схемы с программным кодом. И здесь вопрос в том, что будет легче: либо плюнуть на синхронизацию и продолжать писать, держа при этом в голове всю сложность разрабатываемого элемента, либо делать изменения в схеме, и затем с помощью каких-то средств отражать эти изменения в коде. Этот вопрос является ключевым в использовании графических нотаций. Будет возможность автоматического отображения изменений – тогда эти средства будут востребованы, и могут серьезно изменить технологию программирования. Не будет возможности – и нотация останется языком для аналитиков и преподавателей.
Здравствуйте, Aviator, Вы писали:
A>Создаётся ощущение, что мода на UML стремительно проходит. Помниться раньше первое, что спрашивали — знаешь ли UML, используешь ли. И после ответа "понимаю, иногда полезно что бы кратко изложить идею на бумаге во время обсуждения" смотрели как на полного отморозка. Сейчас даже особо никто не спрашивает...
Вообще по опыту нашего отдела АСУ UML полезно использовать "по-крупному". То есть рисовать примерную архитектуру, структуру БД. Вместо use-case действительно проще словами написать. Диаграммы деятельности — вовсе похожи на блок-схемы. Диаграммы состояний — когда конечные автоматы приходится рисовать — самое то.
А рисовать детально все диаграммы классов и остальные — практически никто не делает.
С точки зрения нашего нормального программера, можно начать с них, потом перейти к коду, а в конце, когда проект уже работает, по работающему проекту уже создать соответствующие диаграммы. Только автоматический инструмент нужно использовать: код -> диаграммы.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Аноним, Вы писали:
А>Только рассуждение будет неполным, если не учитывать некоторые достижения в этих направлениях. Например, по блок-схемам: есть почему-то оставшийся неизвестным широкой публике труд В.Д. Паронджанова «Как улучшить работу ума». При всей претенциозности этого довольно значительного труда, в нем есть несколько совершенно замечательных идей, которые, на мой взгляд, так и не получили должного резонанса в программистском мире.
Просмотрел эту книгу. Кроме изобретения никому нафиг ненужной очередной графической системы "ДРАКОН", у автора какие-то претензии на глобальные идеи суперязыков, развитии мозга и т.п.
А>Главным же относительно обсуждаемого вопроса моментом у Паронджанова является то, что его идеи радикально изменяют место и роль блок-схем в программировании. Он показывает, что можно-таки программировать непосредственно в графике, и это не фантазии автора, а действительно реальное программирование.
Да-да. В его книге нет диаграмм для программ длиннее пары десятков строк.
Простите, но сейчас это совершенно неинтересно. Любой начинающий программист после полугода работы уже просто не оглядывается на детали реализации циклов и операторов ветвлений.
В реальном программировании гораздо более интересны средства борьбы со сложностью большого объёма кода: объектная система, модули, стандартные контейнеры и алгоритмы, система типов, DSL'и и так далее. Что характерно, эти средства позволяют разрабатывать программы размерами в миллионы строк кода.
Здравствуйте, Cyberax, Вы писали:
C>Просмотрел эту книгу. Кроме изобретения никому нафиг ненужной очередной графической системы "ДРАКОН", у автора какие-то претензии на глобальные идеи суперязыков, развитии мозга и т.п.
Вобще-то я говорил не о языке, и не о претензиях автора (не спорю, их там хватает). Только давайте оставим их на совести автора и посмотрим, что же в его труде есть полезного. А полезно в нем не столько язык, сколько исследование вопросов, почему графические изображения плохо читаются, и как с этим бороться.
C>Да-да. В его книге нет диаграмм для программ длиннее пары десятков строк.
Есть. Посмотрите диаграммы по ядерному реактору. И структурирование имеется. Кроме того, для книги как раз не следует приводить громоздкие примеры, главное – показать принцип. (Это кстати практически во всех книгах наблюдается – не только у Паронджанова)
C>Простите, но сейчас это совершенно неинтересно. Любой начинающий программист после полугода работы уже просто не оглядывается на детали реализации циклов и операторов ветвлений. C>В реальном программировании гораздо более интересны средства борьбы со сложностью большого объёма кода: объектная система, модули, стандартные контейнеры и алгоритмы, система типов, DSL'и и так далее. Что характерно, эти средства позволяют разрабатывать программы размерами в миллионы строк кода.
Конечно, автор со своими идеями отстал лет этак на 15-20, но тем не менее, его идеи направлены на борьбу именно со сложностью. Только не в тексте кода, а в его графическом представлении. Графика способна во многих случаях не то чтобы решать проблему сложности, просто уменьшать ее вредность, и во многих случаях — существенно. И здесь главным образом ценны идеи о том, как сделать графику хорошо читаемой, понятной. На мой взгляд, отсутствием этих качеств страдают все без исключения современные графические языки – и это пожалуй, самый мощный фактор, отталкивающий программистов от графических средств. То есть, дело не в графике как таковой, а в существующих средствах.
Здравствуйте, serg0s, Вы писали:
C>>Да-да. В его книге нет диаграмм для программ длиннее пары десятков строк. S>Есть. Посмотрите диаграммы по ядерному реактору. И структурирование имеется. Кроме того, для книги как раз не следует приводить громоздкие примеры, главное – показать принцип.
Вот про это, пожалуйста, не надо. Мне принцип нафиг не интересен, если на практике он неприменим.
S>(Это кстати практически во всех книгах наблюдается – не только у Паронджанова)
Обычно в книгах и не утверждается, что они претендуют на серебряную пулю.
C>>В реальном программировании гораздо более интересны средства борьбы со сложностью большого объёма кода: объектная система, модули, стандартные контейнеры и алгоритмы, система типов, DSL'и и так далее. Что характерно, эти средства позволяют разрабатывать программы размерами в миллионы строк кода. S>Конечно, автор со своими идеями отстал лет этак на 15-20, но тем не менее, его идеи направлены на борьбу именно со сложностью.
Нет, не направлены.
S>Только не в тексте кода, а в его графическом представлении. Графика способна во многих случаях не то чтобы решать проблему сложности, просто уменьшать ее вредность, и во многих случаях — существенно. И здесь главным образом ценны идеи о том, как сделать графику хорошо читаемой, понятной. На мой взгляд, отсутствием этих качеств страдают все без исключения современные графические языки – и это пожалуй, самый мощный фактор, отталкивающий программистов от графических средств. То есть, дело не в графике как таковой, а в существующих средствах.
Нет.
Здравствуйте, Cyberax, Вы писали:
C>>>Да-да. В его книге нет диаграмм для программ длиннее пары десятков строк. S>>Есть. Посмотрите диаграммы по ядерному реактору. И структурирование имеется. Кроме того, для книги как раз не следует приводить громоздкие примеры, главное – показать принцип. C>Вот про это, пожалуйста, не надо. Мне принцип нафиг не интересен, если на практике он неприменим.
А как же с первой частью моего ответа? Посмотрите диаграммы, убедитесь в том, что они таки существуют. А это значит, что Ваше утверждение не имеет оснований.
S>>(Это кстати практически во всех книгах наблюдается – не только у Паронджанова) C>Обычно в книгах и не утверждается, что они претендуют на серебряную пулю.
Обида – не повод для критики. Давайте говорить по существу вопроса.
S>>Конечно, автор со своими идеями отстал лет этак на 15-20, но тем не менее, его идеи направлены на борьбу именно со сложностью. C>Нет, не направлены.
Этим только подтверждаете (см. абзац 1 ответа).
S>>Только не в тексте кода, а в его графическом представлении. Графика способна во многих случаях не то чтобы решать проблему сложности, просто уменьшать ее вредность, и во многих случаях — существенно. И здесь главным образом ценны идеи о том, как сделать графику хорошо читаемой, понятной. На мой взгляд, отсутствием этих качеств страдают все без исключения современные графические языки – и это пожалуй, самый мощный фактор, отталкивающий программистов от графических средств. То есть, дело не в графике как таковой, а в существующих средствах. C>Нет.
Столь краткие утверждения могут означать либо отсутствие доказательств, или хотя бы суждений, либо нежелание думать над ними. Ваше право. Однако Вы должны понимать, что из-за этого вес их близок к нулю.
Допускаю, что у Вас есть некая внутренняя убежденность в этом. Опять же, имеете право. Но ведь верить можно, например, в господа бога, или в коммунистическую партию. А в программировании, извините, нужны хотя бы мало-мальские доказательства.
Буду страшно благодарен! 
