Илья Ермаков писал(а):
Цитата:
Илья Ермаков писал(а):
А что взамен, в двух словах?
Смотрите сообщение в этой ветке за Воскресенье, 20 Апрель, 2008 13:19
Блоки красивые. Исходник показывать так, может быть, и хорошо. Только Вы кастрируете граф до его маленького класса. Возвращаетсь к топологии, характерной (и необходимой) для текстового представления. Строго линейно-иерархическая блочная структура. Так чего огород городить, чтобы получить всё то же самое?
Да, я избавился от линий передачи управления (это о кастрации несчастного графа), нежелательность пересечений которых столько обсуждалась. Если команды выполняются последовательно сверху вниз, то никакой потребности в линиях нет. А если линейная последовательность нарушается, то для этого используются языковые конструкции структурного программирования (без GOTO). Место, куда передаётся управление, легко зрительно отследить по очертаниям блоков и отступам - без каких-либо дополнительных линий. Если внутри блока должно быть несколько веток, то все они будут показаны изначально в свернутом виде (с комментариями) - одна под другой.
В чем
достоинства?
Это, во-первых, возможность оперировать блоком как единым целым: вставлять, дублировать и настраивать шаблон блока, соответствующий выбранной языковой конструкции, удалять блок, копировать, перемещать, свертывать/разворачивать, выделять цветом.
Во-вторых, блок образуется автоматически (и уже со своим отступом), и поэтому нет необходимости вручную указывать, где делать фолдинг. Фолдинг будет возможен везде, где это логично. Нет нужды и в форматтере - форматирование производится изначально.
Третье достоинство - возможность иметь блоки-таблицы, например, таблицы свойств, таблицы переходов конечного автомата и т.п.
Четвертое достоинство - текст блоков в несколько колонок. Например, колонки: идентификаторы, типы, комментарии. Работа парсера упрощается до предела (всю разбивку за него уже сделал программист). Взаимосвязи между любыми объектами (не только в смысле ООП) программы становятся доступными для автоматического анализа еще до какой-либо компиляции.
Пятое достоинство - более жесткая, чем в текстовом исходном коде, структура блока уберегает программиста от некоторых возможных ошибок, помогает новичкам разобраться с шаблонными языковыми конструкциями.
Илья Ермаков писал(а):
Цитата:
Граф (мне более привычен термин "блок-схема") может быть хорош для описания микроскопических задачек
Так нет другого способа успешно решать задачи как сводить их постепенно, пошаговым погружением, к ансамблю таких вот "микроскопических задачек". Чтобы способ решения и правильность каждой была уже очевидной. Я лично обсуждаю в этих темах Дракон (или его развитие) как язык для описания каждого отдельного узла такого ансамбля... И если узел слишком сложен для описания его таким образом, требует более комплексной формы представления, значит он требует анализа и декомпозиции на подузлы...
А способ проектирования и представления этих самых ансамблей в целом я вообще здесь не затрагиваю. Это отдельная песня...
Представляется, что визуальная форма нужна не для того, чтобы сделать толко черновой эскиз, который потом ещё нужно вручную превращать в исходный код. Вся прелесть визуального программирования как раз в том, что исходный код генерится автоматически. Раз это так, то нельзя ограничиться стопкой крохотных блок-схем. Нужно ещё что-то, что объединяло бы "микрозадачи" в большую систему. Чтобы, например, указав на идентификатор, можно было бы посмотреть, с чем он связан (влияющие и зависимые переменные и т.п.). А объединить блок-схемы весьма проблематично, в отличие от предложенного мной гибрида одноколончатой блок-схемы с исходным кодом. К тому же изначально маленькая блок-схема микрозадачи может так разрастись, что станет необозримой, а её разделение на несколько маленьких трудоёмко и чревато ошибками.