>Простота должна быть в смысле минимальности основных понятий и конструкций языка при их абсолютной достаточности для выражения любых структур данных и алгоритмов.

'Структуры данных и алгоритмы', и, уж тем более, Паскаль и Оберон, означает, что мы остаемся в рамках структурного (в лучшем случае - модульного) программирования. Такие вещи, как аспектное, объектно-ориентированное, обобщенное, функциональное программирования, программирование, основанное на языках, специфичных для предметной области, программирование, основанное на правилах, программирование, основанное на ограничениях, логическое программирование остаются 'за кадром', в то время, как многопарадигменные языки, такие как семейство Lisp, позволяют легко показать все вышеперечисленные подходы (навскидку: CommonLisp; Schema; Logo, eLisp, как важные примеры языков предметных областей).

Структуры данных и алгоритмы важны, как хороший пример, на котором можно изучать стиль, эффективность, самодокументирование, совместимость и другие важные аспекты программистского образования, но явно недостаточны для современного программиста. Человек, ознакомившийся со всем Кнутом и с Корменом, будет способен решать задачи ICPC-олимпиад, но уже перед ICFP он будет пасовать.

К сожалению, я про Олимпиады не могу ничего сказать, так как не знаю.
Нужно понимать, что мой личный научно-технический интерес заключается в создании комплексов ДПЛА. Это сложные радиотехнические, авиационные и программные комплексы. В части программирования меня интересует создание бортовых и наземных программ для таких комплексов. Там требуется заставить ЭВМ делать то, что надо. Причём пароль к успеху один-- "надёжность"!
Уверяю Вас, что никакие из экзотических видов программирования, перечисленных Вами, не требуются, более того вредны, при решении моих проблем. Ибо все они зиждятся на создании некоторых слоёв на реальном "железе" ЭВМ. Каждый такой слой, особенно когда его делали чужие люди, особенно иностранцы, является источником ненадёжности, причём принципиально непознаваемой ненадёжности.

ЭВМ --это прежде всего устройство. Мне вовсе не требуется программировать, не зная как это устройство работает. Это для "программистов". Я знаю ЭВМ и использую эти знания. Я не имею в виду, что нужно программировать в машинных кодах. Отнюдь! Но язык программирования должен соответствовать тому, что делает ЭВМ в реальности. А она исполняет программу, команда за командой. Это наилучшим образом отражается обычными алгоритмическими процедурно-ориентированными языками. Даже "Си":)
Паскаль просто лучше для человека. Ведь важнейшая функция программы как текста -- это абсолютно достоверное документирование структуры самой программы, структуры данных и алгоритма того, что мы проектируем. И эта функция просто неоценима.

{+}

>Уверяю Вас, что никакие из экзотических видов программирования, перечисленных Вами, не требуются, более того вредны, при решении моих проблем.

Возможно, но они не экзотические, они широко применяются в промышленности. И при этом ограничение _образования_ теми парадигмами, которые нужны в системах ДПЛА, - это по крайней мере странно, поскольку это влечет за собой неадекватность образования реалииям.

>Но язык программирования должен соответствовать тому, что делает ЭВМ в реальности. А она исполняет программу, команда за командой.

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

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

Кроме того, что считать иностранными разработками? Вам известно, что слой реализации сокетов в операционной системе Linux реализован московским программистом? Думаю, что нет. Все это очень расплывчато и ненадежно.

Мы немного о разных вещах говорим. Я понимаю, что Вы имеете в виду. Правда.
Но учить надо начинать с алгоритмического процедурно-ориентированного языка. Потом можно всё:)

Алгорифмы Маркова непроцедурны. (Да и не "алгоритмичны", в смысле "алгоритмического языка".)

А ЭВМ -- процедурна.

смотря при какой архитектуре

Если архитектура какого-то устройства непроцедурна, то это устройство не есть ЭВМ, а есть нечто иное. Например, программируемая логическая матрица.

Пример Вашей правоты приведите, пожалуйста.

правильно ли я вас понял, что вы считаете, что фон Неймановская архитектура = ЭВМ?
примеры вы и сами знаете - те же самые матричные устройства, очень параллельные устройства (так, чтобы на каждый процессор поступала для обработки одна строка таблицы решений), машины баз данных и т.д.
фН архитектура процветает по тем же причинам, что и Винда - инертность рынка + тяга к быстрой прибыли рыночных агентов

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

Но речь идёт о принципиальном отличии философского характера. Дело не в фН.
То, что я выделяю в вид "ЭВМ", обладает главным свойством, описанным в главном посте. И это свойство способно порождать другие чудесные свойства предмета, обладающего главным свойством. Поучается универсальный информационный прибор, способный обрабатывать информацию любым способом, никак не связанным с конструкцией прибора "ЭВМ". Понимаете? Этот прибор является бесконечно модифицируемым уже после своего изготовления. Причём его материальная конструкция остаётся неизменной при любых модификациях. Не чудо ли!? И всё это благодаря программе. А прибора "ЭВМ" главное имманентно присущее ему свойство всего одно -- исполнять любую программу, команда за командой...

Больше никто этого не может. Даже если Ваши решатели таблиц программируеммы, то они остаются решателями таблиц. А ЭВМ становится то решателем таблиц, то пилотом, то архивариусом, то ещё чёрт-те знает кем:)
Устройства же жёсткой логики на это неспособны.

{+}

под "матричными устройствами" ваш оппонент, видимо, имеет ввиду векторные компьютеры, а не программируемые логические матрицы. так что же, CRAY - не ЭВМ?

Бывает, что объединяют несколько процессоров. И называют это ЭВМ. Конечно, "Крэй" -- ЭВМ. Просто там их много. Главное, что своя программа выполняется последовательно каждым процессором.

ну правда, неужели не стыдно "Главному конструктору комплексов тыры-пыры" декларировать такие судьбоносные "определения ЭВМ", не зная ни одной архитектуры помимо фон-неймановской и ни одного подхода к решению задач кроме построения последовательного алгоритма (фактически, старой доброй блок-схемы)?

Нет не стыдно. Кстати, то что я написал, не есть фон-неймановская архитектура, а есть единственный существенный признак ЭВМ.

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

И всё-таки я считаю, что обучение следует начинать с алгоритмического языка. Мозги чище будут.

А у меня четкое убеждение, что начинать надо с функционального языка, типа Haskell или ML, и параллельно с ассемблера - мозги будут менее закрепощенными - у меня в знакомых есть примеры людей, которые не поймут ассемблера никогда, так и никогда от него не уйдут дальше 'C' - обе категории одинаково ужасны.