А как Вы относитесь к табличному представлению структуры - типа структурограмм?

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

какими средствами предлагается укладывать нелинейные структуры на плоскости документа без пересечений?

...некоторые парадигмы, наверное, плохо сочетаемы (если не взаимоисключающие) - а некоторые, напротив, хорошо объединяются (где-то однорангово, где-то иерархически).

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

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

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

Представьте себе обыкновенную электронику. А тех, кто там работает - "инопланетянами".
Так вот, эти "инопланетяне" давно уже намучались "с многократным нахождением приемлемого варианта расположения блоков на плоскости блок-схемы"
Наработали свои приемы "расположения"...

И фиг ты их заставишь работать в тексте. Лично я пытался их убедить - не получается

Обыкновенная бытовая электроника (ну там детекторный приёмник или даже телевизор) -- возможно.

Однако при разработке процессоров и прочих БИСов используют текстовые языки типа VHDL и Verilog. Почему?

Обыкновенная бытовая электроника (ну там детекторный приёмник или даже телевизор) -- возможно.

Однако при разработке процессоров и прочих БИСов используют текстовые языки типа VHDL и Verilog. Почему?

Поясните, что имеется в виду?

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

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

Мне просто интересен этот вопрос. Скажем аргументация "скорописи" - мне известна. Ну типа: я напишу "Hello Word" ровно за 8 секунд, а мышью Вы будете долбиться аж целых двадцать. Известна, и не убеждает.
У нас ведь здесь другой случай. Вот я и спросил за аргументацию в этом другом случае...
Пока поймал аргумент: нарисовать правильно и понятно - это ТРУД.
Согласен - ТРУД. И есть целая область (инженерия), где этим трудом постоянно занимаются. Значительную часть времени. За зарплату.
Гипотеза для обсуждения: если этим трудом сознательно не заниматься - "ракеты будут продолжать падать"

1) Структурное программирование, т.е. вложенные друг в друга блоки
2) Многоветочные конструкции, похожие на Дракон, но только "линейные"
3) Отбражение разных частей программы (модулей, процедур) на разных вкладках, т.е., по сути, разбиение программы на страницы/слайды
4) Средства автоматического преобразования выделенного кода в инлайновую процедуру, размещаемую на отдельной вкладке

По пунктам:
1) Вкладываем то, что имеет один вход и один выход. Так?

Если графы (в частности, графит-схемы) Вас не устраивают - не следует ли ввести как альтернативное табличное представление с заменой маршрутной лексики табличной сеткой (структурограмм, развивающих источники в этом сообщении с учётом высказанной там критики)?

2) ...как обходимся без "выкладки в линию", ... т.е. без goto и/или заменителей? Или не обходимся?

3) Разбиение - значит, фрагментарное восприятие. Как собираем - т.е. где "схемы соединений и подключений" содержимого (модулей, процедур)?

4) Имеется в виду то, что в шампур-методе называется подстановкой (см. определение здесь)?

Для этого ей придется перестать быть двумерной, вытянуться в вертикальном направлении и стать более автоматизированной.

Обходимся без goto. Использование brake, continue и т.п. - дискуссионный вопрос (что важнее: скорость или надежность программы?). В принципе, без них можно обходиться.

Тут у Вас не совсем верное противопоставление. Скорости программе break и continue не добавляют. Для редких случаев нужен общий LOOP-EXIT, а простой break нужен только тем, что не умеет циклы писать...

...

Так это - текст В каком-то... будущем, широком смысле слова, как линейная последовательность объектов. Прообраз "будущего широкого смысла" - составной документ... Видимо...

Прежде всего, по поводу дискуссии о БИСах. Мне тоже нравится смотреть на хорошо сделанные (кем-то другим) графы. Но кто рисовать-то будет? Непроизводительно это и неэффективно с экономической точки зрения. Как учебный пример, чтобы разобраться со сложным местом в алгоритме - пойдет (причем это можно сделать маркером на доске). Отладить одно маленькое критическое приложение "для ракеты" - ну тоже можно. Но как промышленный инструмент - слишком трудоемко и сложно (одних правил построения сколько!, да их еще надо уметь применить).

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