OberonCore

Вот конкретный пример.
В одной программе (отладчике) надо организовать разбор запросов и входных данных (в частности, таблиц).
По ряду причин (каких - здесь не принципиально) мне было неудобно применить yacc, который я использую обычно, поэтому я написал пару простых нисходящих разборщиков a la Wirth.
Следующим шагом я добавил "семантику" методом поэтапного дополнения (как у Вирта в старой книге "Алгоритмы + структуры данных = программы"). Т.е. просто дописал дополнительные переменные, операторы и вызовы процедур в нужных местах.
Если бы я делал это на КП в ББ, то обязательно бы выделил "семантические" операторы с помощью другого цвета или шрифта и получил бы разделение синтаксиса и семантики в самом простом виде.
Если бы потом мне потребовалось переделать семантику, я бы сразу видел (в буквальном смысле слова), что в исходнике относится к синтаксису, а что к семантике.
Это (по крайней мере, в данном случае) удобно. А возможно благодаря тому, что цвет не расходуется нерационально на выделение ключевых слов языка программирования.

Ещё пример: реализация автомата. Цветом выделяются варианты в CASE - состояния (тек. и те, куда возможен из него переход):Жирным выделяются операторы перехода в новое состояниеБлагодаря такому оформлению можно легко видеть граф состояний автомата в коде.

В общем, синтаксическая раскраска - это вчерашний день. Архитектурная раскраска - вот современный подход!

А если Вы где-то забудете раскрасить, что-то пропустите? И понеслись ошибки понимания программы...

Будет просто нераскрашенный кусок текста. Всего-то.

И вот придёт другой человек в проект после вас, и начнёт голову ломать -- почему этот кусок не раскрашен, тайный умысел или просто недомыслие?

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

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

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

Это Ваше конкретное умозаключение представляется мне немного странным, учитывая, что в рамках проекта может существовать соглашение об унифицированном использовании раскраски текста.
Давайте проверим это, заменив "семантическую раскраску" на "форматирование исходного текста" (обычно в рамках проекта используется то или иное соглашение об использовании отступов, пробелов, расстановке скобок; как правило, используется также соглашение о том как "правильно" именовать объекты).
Вот что получится.
Впрочем, отсюда можно извлечь (сейчас довольно популярную) идею об использовании языков с однозначным форматированием.
Но такие языки как Си/Си++, Паскаль, Оберон предоставляют известную свободу программисту, так что критика Оберона "со стороны Паскаля" не слишком понятна.

Мало ли что мне хотелось. Если есть чёткий корпоративный стандарт - ему должно следовать. Иначе это детский сад - васе хочется раскрашивать лопаткой, а пете палочкой.

Я применял автораскраску синтаксиса несколько лет, просто не зная о другой возможности. И мне казалось, что раскрашивать синтаксис - это обязательная черта среды. Когда я познакомился с ББ, по привычке долго раскрашивал синтаксис (с помощью компонента автораскрашивания Master, авт. С. Губанов). А когда началось плотное программирование на ББ, то случилось страшное: раскраска синтаксиса стала мешать и отвлекать внимание! Я пока не могу сформулировать, почему. Хотя для начинающих осваивать синтаксис языка - это удобно, признаю! Чем сложнее язык, тем удобнее. Думаю, для оберона это несущественно.

У меня та же самая история, тоже потом "случилось страшное".

Если бы я не имел опыт в чтении таких исходников, то в таком случае всё, как минимум, было бы не очевидно.

Цель ручной раскраски - обратить внимание. То есть, автор тем самым говорит: "сюда смотри внимательнее". Приведённые выше примеры раскрасок говорят о том, что виды раскрасок преследуют разные цели (наиболее нужные в данный момент авторам).

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

Если действительно от ручной раскраски присутствует дискомфорт, то автоматическая мешает ещё больше.

P.S. Я имел дело с исходниками среды и исходниками некоторых компонентов. Выделения, пусть и различные у разных авторов, довольно сильно мне помогали.

А автоматическая раскраска, можно сказать, ничего не выделяет. Имеем дело с однородной пестрящей массой.

То, чего вы достигаете "архитектурной раскраской" (в месиве низкоуровневого кода отделить мух от котлет), намного эффективнее достигается введением DSL. Но с DSL в оберонах совсем плохо, поэтому ручное раскрашивание это вариант...

Кстати, а что такое DSL? А то у меня ассоциации только с Digital Subscriber Line

Domain Specific Language: http://en.wikipedia.org/wiki/Domain_Specific_Language

Vlad, я на 4GL DSL программил много лет. Не срослось у меня с ним Кстати, там тоже была раскраска строго синтаксическая...

А речь не идет о каком-то конкретном DSL. Нужен конечный автомат - вы бертете DSL конечного автомата, нужен парсер - берете DSL парсера. Если "взять" для вашего языка/среды сложно - сидите и форматируете/комментируете/раскрашиваете.

Язык с "отсутствующим синтаксисом" имеете в виду? Лисп-Форт?

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