Оберон-клуб «ВЄДАsoft»

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

Я бы назвал это "обозначаю проблемы и указываю пути их решения".

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

Да пожалуйста. Микроконтроллеры, космос, риэлтайм, сверхнадёжные программные системы и такие, где требуется огромная производительность, кроссплатформенная разработка, "энтертайнмент", и т.д. и т.п. За всю свою сознательную программистсткую жизнь я не могу найти ниш для Хаскеля вообче, кроме самоудовлетворения тщеславия зануд-математиков. А ты, когда тебе надоест очередной Хаскель с другим синтаксисом скобочек, дай нам знать.

В основном слои ругают из-за оверхеда. Ассемблер не вполне слой, это представление машкода, более удобное для человека. Это не библиотека, не API, не интерпретатор и не виртуальная машина. Оверхед нулевой.

У системы типов Оберона есть особенности, которые тебе кажутся недостатками. И если бы даже у тебя была возможность их "исправить", ты лишился бы других достоинств Оберона, например, его простоты.

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

Тебе эти достоинства Оберона кажутся незначительными? Это по молодости, дружок, я сам такой был.

Last_Alien, я знаю что он считает недостатками системы типов Оберона. Он мне уже рассказывал. Вовсе не отсутствие поддержки юникода в символьных типах. А отсутствие прямо в языке комплексных чисел и аппарата для сверхбольших и прочих ленивых вычислений. То, что превращает язык в монстра. Это технологический тупик, который ожидает любой язык, но Оберон движется к нему не так быстро, как шарпы.

Ну делают конечно. И многоядерные Форт-процессоры, и Лисп-процессоры. Только вот для специфических применений, уставших же романтиков от программирования манит универсальность, почти утопичность.

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

Ну вот смотри... Это я когда-то писал.

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

Я программировал на Форте некоторое время, даже делал свою реализация Форта для Спектрума. Мозги закипают и выворачиваются наизнанку. Чтобы понять логику алгоритма — иногда без пистолета и бетонной стенки просто не обойтись. Когда пишешь вычисления — нужно в уме представлять себе арифметический стек и все манипуляци в нём. Для сложных ветвлений — стек возвратов. Отладка ужасная. Пишешь код будто ходишь по минному полю. И это по-своему прекрасный язык! Но с некоторых пор я избегаю подобных языков как чумы. При всей их привлекательности и красоте по Туполеву.

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

Ты бы предложил при засилье Форта публиковать алгоритмы на Форте? Или для этого лучше всё-таки Оберон с его зафиксированными набором ключевых слов и системой типов?

Хаскел как нотация для записи алгоритмов — тот же Форт, только нерасширяемый, очень далёкий от железа (не того железа, которое где-то делается и куда запихнули миллиард транзисторов, а от того, которое приходится использовать каждый день) и абсолютно не имеющий никаких преимуществ для моих задач и моего образа мышления. Да-да, если я не математик, то это не значит, что я ненавижу математику, не передёргивай. Просто люблю уверенные и простые понятийные аппараты. С некоторых пор. Это — не каприз. За всем этим — годы работы и не один десяток ЯП, платформ и архитектур, дружище.

Лисповское +(a b) и Фортовское a b + вместо a + b как нотация — компромисс или реверанс реализации, притом часто в очень ограниченных условиях. Или вкусовщины. Или привычки, вот что обидно. Так вот Оберон — это a + b. Что думаю, то и пишу. То и читаю. Программу не надо из её записи постоянно "распаковывать" в голове и "запаковывать" опять. Так делают очень плохие и неудобные нотации: Форт, Лисп, Си/C++/C#/Java. Хаскел. Между тем, адекватная нотация — не роскошь, а суровая необходимость, и ты как математик должен это понимать.

Вот именно.

Ну, начнём с того, что вначале ты упоминал про невозможность использования сишных языков в некоторых нишах. Ты привёл такие ниши, и что мы видим?
Ты, возможно, удивишься, но тот же сишарп можно использовать на "жирных" микроконтроллерах, для которых реализован .NET Compact Framework или .NET Micro Framework.
C++, Ява довольно активно используются в тех же космических аппаратах.
Программы на Яве, С++ или даже том же Хаскелле куда более кросплатформенны, чем тот же оберон, просто потому что оберонщики не заморачиваются с кросплатформенностью, в оберонах нет даже переносимости в пределах одного диалекта между разными компиляторами.
Насчёт огромной производительности -- боюсь, тут ещё долгие годы будут использовать самый первый язык программирования -- фортран. Эта сфера весьма консервативна...

Что касается реалтайма и сверхнадёжности. Вот возьмём тот же Astrobe Oberon-07 -- его нельзя использовать в подобных нишах. А знаешь почему? Потому что его автор вряд ли когда озаботится сертифицированием своего транслятора и библиотек к нему.
Так что это проблема не только для хаскеллов, но и для оберонов.

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

Печально. При чём печальнее всего не то, что ты не можешь этого сделать, а то что ты не хочешь этого делать.
Впрочем, как раз эту тему обсуждали недавно в оберон-конфе oberon@conference.jabber.ru -- большинство современных программистов (точнее тех, кто получает зарплату за занятия программированием) не хотят учиться, изучать что новое, не видят в этом интереса, пользы. Печально, но ничего не поделаешь, наверное...
Программирование вышло из той стадии, когда оно было новой интересной профессией, стало обычной рутиной для тех, кого ты называешь "быдлокодерами"...
Я сам работаю с одним таким, когда вижу его код, мои волосы встают дыбом, а глаза плачут кровавыми слезами... ))

Даже не знаю что ответить. Хаскель -- это не синтаксис скобочек, а контроль над эффектами -- действиями по вводу/выводу и изменения переменных, причём контроль со стороны системы типов. Плюс -- удобные средства для описания предметной области.
То есть хаскель -- это не про синтаксис, а про семантику. Почему ты делаешь такой упор на синтаксис каких-то там скобочек -- непонятно.
Или ты говоришь хаскель, а имеешь в виду си? Определись уже...

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

Когда я вижу подобные утверждения, прямо таки представляю, как меня снисходительно похлопывает по плечу умудрённый опытом седовласый старший товарищ, и тем смешнее мне становится, когда я вспоминаю, что я старше того, кто это утверждение делает. )))

ОМГ! Не вводи в заблуждение других людей.
Неужели я так коряво изъясняюсь, что меня можно вот так вот превратно понять?
Какие нахрен комплексные числа прямо в языке? Да, их добавили в Си, но это не значит, что я считаю, что каждый язык должен их иметь.
В том же хаскелле, например, комплексные числа, как и сверхбольшие числа, сделаны всего лишь как часть стандартной библиотеки, поставляемой с компилятором.

Если бы было засилье Форта, то это значило бы, что он для этого вполне годится.
Я не считаю, что для публикации алгоритмов лучше оберона нет ничего. Мне не нравится синтаксис оберона, так же как мне не нравится и синтаксис сей.
Для публикации алгоритмов, имхо, лучше всего подходит некое подмножество Питона, с ясным двумерным синтаксисом, с минимумом синтаксического мусора в виде {} или BEGIN END. Выбросить из Питона ООП-составляющую -- все эти классы -- и нет ничего лучше для публикации алгоритмов. Но это моё частное имхо, конечно же...

Ну это уже дело привычки, своего рода каприз.
Вот я совершенно не вижу преимуществ нотации оберона по сравнению с Си/C++/C#/Java или Хаскел, хотя для меня, человека хоть и занимавшегося когда-то фортом и лиспом, но так и не привыкшего к их нотации, преимущество перед лиспом и фортом очевидное -- оберон просто привычнее.
Однако это не повод ставить на одну чашу Форт/Лисп, Си/C++/C#/Java и Хаскел.
Между обероном и сями разница куда меньше, чем ты пытаешься это показать другим...

Я хочу учиться, я вообще вечный студент, я учусь всё время, но вьюношу типа тебя, который ещё не завоевал весь мир, но вскорости планирует это сделать, очень тяжело понять по молодости, что объём черепной коробки ограничен, и чем больше человеку лет — тем меньше у него ресурсов для обучения. Это закономерно. Природа. Это понимается с возрастом. Вот только зачем ты приравниваешь обучение вообще к обучению Хаскелю? Ну не пришлось мне, пласт моих познаний лежит в более другом промежутке времени, но я не считаю ущербным то, что мне даже не пригодилось. Для опыта всё ценно. Кроме Хаскеля.

Я в этом Вирта не одобряю. Но ты забыл, что он не господь бог, и комитеты по стандартам — не его стихия. Он вообще свои задачи решает, а не управляет новым мировым порядком. Так что лучше придерись к чему-то другому.

Так чего же ты нахрен хочешь от системы типов Оберона?

А знаешь что ты щас сказал? Что идеальной в твоём понимании нотации для публикации алгоритмов на данный момент вообще просто нету в готовом виде. Это очень печально, друг!

Он проверен временем.

Поверь, я ценю всё что ты делаешь для нашего форума. Без иронии. Ценю.

Кстати, а что бы ты предложил использовать вместо JavaScript? Ведь есть же люди, которым приходится использовать JavaScript, однако для них это слишком тяжко и они ищут ему замену...

Сколько тебе лет-то? Я помню, что ты вроде бы моложе меня (80-х годов рождения кажется), но запамятовал насколько именно, извини..

Кто тебе сказал, что я так приравниваю?
То, что я меньше внимания уделяю другим языкам, так это потому, что мне Хаскель просто бльше нравится, кроме того именно в хаскелле сейчас идут наиболее активно всякие разные исследования -- софтверная транзакционная память там, исследования в области систем типов и т.д.

Именно так -- он делает обероны для себя, для своих задач. И Оберон неплохо может подойти для программистов-одиночек типа Вирта. Для промышленного же программирования Оберон мало приспособлен.

Я когда-то думал об этом, но потом пришёл к выводу, что подобные изменения системы типов уж слишком изменят язык для того что бы он мог называться обероном.
Вот, например, Зоннон. В нём изменения по сравнению с Обероном незначительны, однако ортодоксальные оберонщики уже отказывают ему в праве называться обероном...

Ага, нету. Питон ближе всех подходит, но тоже неидеален.
Однако это не является особой проблемой для меня лично...

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

И на том спасибо )))

Слегка модифицированный Оберон-2 / Компонентный Паскаль конечно ( не Оберон-07 ! ). JS да и вообще интерпретация, в какие бы финтифлюшки её не заворачивали, это некрасиво и не ортодоксально, и js вообще имхо не имеет права на жизнь. А вообще это ненормально, что для клиенской стороны один язык, для серверной другой (чаще всего PHP), для десктопов третий, для планшетов и смартов четвёртый и т.д. Предложи использовать вместо всей это сишной дребедени один универсальный? Барьер вхождения тоже ведь никто не отменял. Приток новых юзеров, рамки решаемых ими (без переквалификации) задач должны быть широки, не надо нам специалистов по левому и правому уху. Т.е. может и надо, но...

Имхо Обероном занимаются вообще незаслуженно мало. А ведь применимость самая широкая. На нём можно даже сайты делать с форумами.

Но насчёт того, как заставить всех поддержать Оберон в браузерах — тут не ко мне.

Я не удивлюсь, я в курсе. Микровиртуальная машина. И куда бы деть производительность проца, ведь она не нужна, ведь всё упирается в скорость HDD и сети?

Вах вах вах. И кто ж тебя, сердешного, принуждает общаться с таким неадекватным человеком как я? Вдруг в секту втяну! Или это мне грозит. Вдруг ты всем расскажешь, что я с пистолетом тебя преследую и заставляю Оберон юзать.

Мне слегка надоело наше общение. Извини, если на некоторые вопросы не ответил. Возможно, потом, при настроении. Пойду лучше на Обероне покодю.

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

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

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

Мы уже знаем чем заканчиваются попытки включить в язык всё, что вообще может понадобиться. Получаются PL/1, Ada и C++. В то же время, если чего-то недовключить в язык, появляются недовольные его минимализмом (мало типов, кривая система типов и т.д.). Так как же соблюсти баланс между переизбытком и недостатком? Это очень сложный вопрос, который затрагивает многие настолько сложившиеся мнения, что простого ответа нет и не будет. Если заложить в язык механизм расширения в стиле Форта, то язык останется манной кашей, потому что проблемно-ориентированные множества языков, на нём построенных, будут настолько непохожи и отличительны, что читать тексты программ на них без полного понимания принципов расширения над основным языком практически невозможно. Этим сверхрасширяемость себя дискредитирует. Потому что вместо одного языка мы получаем целую кучу языков, в которых предстоит разобраться. И практика показывает, что они обычно бывают настолько плохо спроектированы, корявы и заумны, что лучше было бы писать всё в более едином стиле.

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

Чем более концептуально уверенные понятия вложены в семантику языка (а менее уверенные — выносятся на уровень библиотек, написанных на нём) — тем лучше. Притом мостик от машинных кодов надо строить не только к профессорам математики, но и к обычным людям, которых большинство. Нет, профессора тоже имеют право иметь свои мостики, без проблем. Но меня это не очень интересует. Я, перед тем как заняться серьёзно Обероном, искал универсальный ЯП ("один заместо всех других"), который помог бы повысить производительность моего труда. Рассматривались кандидаты:

C, C++, D, Forth, Modula-2, Ada, Pascal

Язык должен быть непременно универсальным, говорил я себе, потому что есть больше смысла научиться ловить разную рыбу, чем научиться готовить только одну селёдку, т.е. изучить узкоспециализированное средство для очень эффективного решения задач из очень узкого диапазона ниш. Тогда я хотел заняться производством софта под КПК и любил Паскаль, а PalmOS и PocketPC (WinCE) можно было программировать преимущественно на C. И я честно пытался это всё освоить. Да, я овладел в своё время PalmOS и научился делать для неё программы, только жаль, что мне это знание сейчас абсолютно не пригождается, ну кроме общего уровня понимания ситуации с софтопроизводством.

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

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

Если говорить о мостике между железом и мышлением, надо оценить все эти языки по этому критерию. И вот что я заметил. Между моим мышлением (не буду говорить за других и утверждать что-то наверняка) и языком Си лежит некоторая общая напряжённость. Ну, недопонял языка, не доучил, не набил руку, думал я, всё притрётся с опытом. А не, не тут-то было. А вот если взять Паскаль, то ещё по знакомству с ним по книгам осталось солидное впечатление. И работая с ним в школе на УК-НЦ, а потом дома на Спектруме (HiSoft Pascal) — это впечатление ещё больше укрепилось. А теперь если взять Форт или Лисп, то пропасть между мышлением и этими языками настолько глубока, что они практически не решают основную задачу их появления. И неудивительно. Ведь Лисп изобретался как новая парадигма, отличная от императивной, а Форт делался вообще на коленке для радиотелескопа в условиях тесного адресного пространства и специфичной системы машинных команд.

Так моя главная претензия не к Хаскелю конкретно, а вообще ко всем этим навороченным императивным языкам, ровно также как и к функциональным — это пропасть между тем, что я проговариваю в уме, чтобы прояснить задачу, и тем, что надо написать в нотации, чтобы машинка "переварила" и съела, подав нужный результат. А чтобы окончательно пресечь споры, предлагаю такую аналогию: какому языку живее и лучше и в более короткие сроки легче обучить десяти-, двенадцати-, четырнадцатилетнего ребёнка, ровно как и студента, — Оберону или, скажем, Хаскелю? Какой из этих языков является лучшим мостиком между мышлением ребёнка или студента и машиной? (с учётом того, что машины как раз — зверьки очень изменчивые). На каком из этих языков проще всего научить писать маленькие программки для построения графиков функций, решения квадратных уравнений или рисования калячек-малячек?

Представления Вирта о ФП довольно сильно устарели. Достаточно глянуть на список литературы в конце -- из всего мира ФП там ссылка лишь на статью про Лисп, 62-го года.
Ты делаешь ту же ошибку -- рассуждаешь об огромном семействе языков программирования по одному из его представителей, да ещё и по самому первому. Это всё равно что рассуждать об императивном программировании, взяв Фортран за его лучший образец. Что же ты не пишешь программы на Фортране?
Да ещё и Форт сюда постоянно зачем-то приплетаешь...

Ну, как ты сам ниже признаёщь, такие же проблемы есть и у вполне себе императивных языков, всяких Ада, С++, Ди, Ява...

Насчёт того, что ближе к человеческому мышлению -- это всё спорно, люди -- они разные.

Ну да, привычки влияют сильно, недаром тот же Страуструп писал в своей книге по С++ -- если вы прекрасно знаете Си, то это знание может вам очень сильно мешать при изучении С++, новичкам С++ даётся значительно легче...

Были уже подобные эксперименты.
Детям приходится показывать коробочки, в которые прячут какие-нить там шарики, кладёшь туда шарики, вынимаешь обратно -- это типа визуализация переменных и их изменения. По другому они мутабельность состояния понять не в состоянии ))

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

Вообще, у меня вот такой вот сложился тезис -- Хаскел можно смело сравнить с обероном, только в применении к функциональному миру. Ну ладно, не с Обероном, а скорее с Компонентным Паскалем.
Можно придумать язык более простой чем Хаскелл, так же как можно упростить Компонентный Паскаль и получить тот же Оберон. Однако как в случае с Обероном, так и в случае с недохаскеллом, результат получится малопригодным для реального использования.
Из Хаскелла нельзя выкинуть что-то серьёзное, что бы не поломать весь язык. Можно выбросить лишь мелочи, немного облегчающие повседневное использование. Хаскелл вобрал в себя самые важные достижения информатики в области ФП -- алгебраические типы данных, параметрический полиморфизм, классы типов (нормализованный перегрузочный полиморфизм), поддержку монад, контроль монады ввода/вывода... Если убрать хоть что-то из этого, то сразу же получится малополезный недохаскель, отброшенный в 70-80-е годы прошлого века...

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

Я не знаю, изучал ли ты Хаскель, но по твоему отношению к нему подозреваю что нет. Может всё же стоит попробовать?
Вот недавно ilovb подсказал ещё одну книжку по хаскеллу, которую он нашёл на сайте PascalABC.NET и которая ему очень понравилась:
А. Холомьев - Учебник по Haskell

Эх, как бы тебе ответить так, что бы не сильно обидеть-то? Да посмотри хотя бы на код самого Вирта -- это же ужас. Начиная от секции VAR, которая заставляет декларировать те же счётчики циклов в ста страницах кода от их использования...
Но самое главное -- это то что за неимением параметрического полиформизма приходится плодить копипастом одни и те же списки, рискуя сделать кучу ошибок. Да хрен с ними, со списками, а если взять что-нибудь посложнее, красно-чёрные деревья, например. Ведь один раз сделанная профессионалами библиотека для работы со сложными структурами данных будет наверняка надёжнее и эффективнее, чем наколенные поделки простых пользователей языка, которым нужно о своей предметной области думать, а не о тонкостях алгоритмики...
Оберон не позволяет создать аналог той же библиотеки STL, и это приводит к возникновению говнокода там, где его могло бы не быть...

Не имеет практически никакого значения, на каком языке проще писать маленькие программки, каляки-маляки. Просто потому что они, как правило, одноразовые -- написал, выполнил, стёр.

В серьёзных же проектах может иметь значение распределение обязанностей между программистами, например. И здесь definition-модули из модулы-2 или ады гораздо полезнее, чем упрощённый экспорт из обероновских модулей...
В больших проектах недопустимо на каждый чих заводить самодельный вариант распространённой структуры данных, гораздо выгоднее использовать STL или её аналог, и здесь оберону опять незачёт.
В конце концов, в сложных проектах становятся важны средства создания встроенного предметного языка -- eDSL, и тут единственное средство оберонов -- процедуры -- становятся недостаточно удобными и выразительными...

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