OberonCore

По сравнению с плоским текстом двумерная структура и так наглядна. Поэтому они избыточны.

Да будет Вам известно, что избыточность механизмов контроля как раз и является в инженерном деле основным способом увеличения надёжности.

Просто после того, как я на такое пару раз наступил. Как в своём коде, так и в чужом, глючащем, причем там было всё интересней -- скобочки были. но перед ними человек на автопилоте влепил точку с запятой. т.е. было нечто вроде:

Усугублялось тем, что там было кода намешано много. Отступы были расставлены художественно (вот тут у нас отступ в два пробела, тут в три, тут в семь, а тут в один), ну и функция там была больша-ая + там был PeekMessage/DispatchMessage в результате которых через хитрозакрученную жо.. эмм.. логику вызывалась та же функция (там был VCL). Ковырялись мы в этом (в двоём) где-то с полчаса наверное.

Вот. После этого я недостающие скобочки всегда вижу


Дас, сишечка хороша для подобных приколов/подколов коллег

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

Так что не всегда следование пути избыточности даёт хороший результат, часто лучше изменить исходную конструкцию.

Особенно когда коллега уже успел забыть о предыдущем приколе и расслабился.

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

Я бы заменил слово "не всегда" на слово "никогда". Впрочем, Вы правы, иногда действительно приходится закладывать избыточность, но как правило это свидетельствует о недостаточной проработке (то есть необходимо "изменить исходную конструкцию").

Там асимптотика. Стремимся к нулевой вероятности ошибки - и никогда не достигаем, конечно. Но сколько-нибудь нулей после запятой имеем, если хорошо страхуемся

Смысл верификации любой, доказательств в перекрёстной проверке, в представлении одного и того же в эквивалентной форме. Допустить ошибку и там, и там уже гораздо менее вероятно. При этом нелинейно менее.

P.S. По поводу балки Geniepro. Занятно, народ теперь по National Geographic узнаёт про то, что раньше в книжках по занимательной физике для младших школьников писалось. И пример там плохой - там отбрасывается не "избыточная страховка", а как раз полностью ненужный баласт - в любой цельной конструкции большая часть её площади сечения находится в стороне от линий распределения напряжения и вообще не несёт нагрузки, поэтому может быть выкинута.

Ну лично я-то и раньше знал -- часто вижу мосты, сделанные по этому принципу. А эти из National Geographic просто умеют наглядно показать то, что на страницах книжек выглядят не особенно впечатляюще...

Переформулирую первоначальный вопрос: есть ли какая-нибудь связь между подобными сишными безобразиями и исключением из Оберона-07 всех конструкций с контекстной связью (LOOP/EXIT и RETURN в произвольном месте)?
Могут ли указанные конструкции привести к безобразиям, хоть отдалённо сопоставимым с приведённым примером? Или Вирт проявил чрезмерную осторожность (вариант -- стремление к совершенству)?

Если говорить о языке-ядре, то Вирт просто прав.
Хотя лично у меня некоторые сожаления насчет LOOP/EXIT как средства оптимизации.
Но во всех, насколько помню, подобных ситуациях нужен некий частный случай:
IF ... THEN EXIT END, причем на верхнем уровне тела цикла.
Который, может быть, можно было бы как-то оформить пожестче, синтаксически.

А еще полезнее графическое, а не текстовое выделение блоков в структурном/семантическом редакторе:

Вот не знаю почему, но в примере Прохоренко меня "типает" от while - elseif. Так и хочется написать whileif - elseif. Чтобы в обоих словах был суффикс if.
Хотя сам цикл мне очень нравится!
Только нужно еще end в конце поставить.

Зачем?

Потому что конструкция незакрытая получается.

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

Ваша точка зрения понятна. Интересно, что скажет Валерий Лаптев.

На картинке Сергея Прохоренко закрытость конструкции очевидна без всяких end -- там весь этот блок выделяется слева большой скобкой.
Вот мне и интересно -- нафига здесь ещё и end?

Кстати, исходники могут динамически порождаться, компилироваться и загружаться.

И? К чему Вы это?

В смысле, наглядность закрытия конструкции порождаемого исходника в тексте генератора может обеспечить только END?

Для примера. CocoCRX
Как конструкции будут в коде просматироваться без END?

Без end возможна двоякая интерпретация:
1. elseif - внутри цикла и проверяется на каждой итерации цикла. Это просто цикл Дейкстры непосредственно с несколькими охраняемыми командами.
2. elseif выполняется ОДИН раз после выхода из цикла, когда условие while становился ложным. Это почти так сделано в Питоне. Там стоит else после цикла.

Наличие end явно обозначает конец цикла и не допускает разночтений.