Чтобы не мешать все темы в кучу, сделал новую ветку. Тема берёт начало отсюда.
Вообще то понятие «синтаксический сахар (смотрим Википедию) не имеет устоявшегося определения. Обычно он имеет 2 толкования. Первое (более распространённое) – это когда одни и те же вещи можно написать разными способами. Во втором случае это понятие применяется к тем конструкциям языка, без которых в языке, в принципе, можно обойтись. Например, «then» после «if» компилятору не нужен, он нужен некоторым программистам «для наглядности». С этой точки зрения «then» и есть синтаксический сахар.
Если остановиться на первом толковании понятия «синтаксический сахар», то можно сказать, что в Обероне нет анонимных функций, поэтому написать так же, как в статье по приведённой ссылке
map( function(x){return x*2;}, a );не получится. Можно использовать именованные функции, но они 1) будут описаны в другом месте 2) не будут скрытыми. Т.е. добиться ровно того же не получится. Значит, это не «то же самое, только другим способом». Значит, это не синтаксический сахар в первом понимании.
Если брать второе толкование, то приведённый пример как раз то лишён всех «излишеств». А если добиваться того же именованными функциями, то код удлиняется и появляется синтаксический сахар. Поэтому желание писать программы как в вышеприведённом примере – это требование синтаксический сахар убрать.
Опять же обращу Ваше внимание, что в Обероне нет чистых функций. А они позволяют уменьшить количество состояний программы. Т.е. уменьшить её логическую сложность. А это, в принципе, повышает её надёжность. Между тем, последнее время языки активно дополняются функциональными возможностями: C++11, D, Nemerle и другие. Функциональная парадигма в чистом виде не оправдала себя, как универсальная и пригодная на все случаи жизни. Но в гибридных языках она приживается как некое подмножество и может найти применение в оправданных случаях.
В языке D есть контактное программирование. Это проверка значений на входе и выходе функций. Этого можно добиться обычными «if». Но в D эти проверки можно отключить при компиляции, когда код хорошо проверен. А в обычных языках «if» - это обычная конструкция. Как компилятор отличит проверочное «if» от обычных «if», чтобы отключить эту проверку, которая стала ненужной?
Или взять оператор «break n» из PHP. С одной стороны, без него можно обойтись, используя обычный «break». С другой – он делает код проще и короче.
Конечно, что функциональные, что контрактные добавки в язык этот язык утяжеляют. Растёт количество правил в БНФ, растёт число страниц в учебниках. Но это ускоряет разработку программ и увеличивает их надёжность. Значит, это оправдано.
Оберон же, остановившись на минимальном, но достаточно мощном императивном подмножестве, остановился вообще. Не желает выйти из этих рамок. Может, именно поэтому он не востребован? И в мировых, и в российском рейтингах языков программирования он вообще не наблюдаем. Можно, конечно, на зеркало попенять. Но можно просто задуматься: а почему? Автор языка имеет право на своё видение. Плохо получилось у него или хорошо – это уже голосуют пользователи языка.
Поэтому не знаток Оберона, отнюдь 
), а проверять должны умные электронные системы, благо научно-технический уровень уже позволяет это делать — проводить самопроверку всех систем и узлов.
