OberonCore

Обсуждалось на форуме Королевства - http://delphikingdom.com/asp/talktopic. ... 82#msg5382

Вышеприведённая ссылка - более новый (сегодняшний) пост Зуева об Обероне, Си и т.д...

Спасибо!
Наконец-то Зуев решил сказать что-то и об Обероне, а то разбор полетов касался только Си++ (несмотря на заявленный нейтралитет).
Надо вчитаться, подумать. Все-таки человек работает в ETH не первый год.
Некоторые суждения кажутся резковатыми:
Хотелось бы спросить орловцев (как пишущих на Обероне/КП программы покрупнее, чем мои): согласны ли они с этим утверждением?

Тут дело тонкое.

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

На этом я мог бы закончить и ответить, что:
1) Утверждение Зуева верно;
2) Для многих задач (все системные и приличная часть прикладных) это не недостаток, а скорее достоинство (отделяется модель данных от архитектуры).

Однако, в компонентном ПО среди абстракций архитектуры кроме самих модулей появляются разъёмы между ними (т.е. динамические, виртуальные связи). Возникает задача описания интерфейсов этих разъёмов и виртуальных таблиц. И в Компонентном Паскале эта задача возложена на объектные ТД: ABSTRACT RECORD как описание интерфейсов, виртуальная таблица объектного типа как разъём.
Т.е. RECORD "пролезают" в архитектуру - и служат уже далеко не "для представления данных". Функции свои они прекрасно выполняют, но некоторая смысловая путаница таки возникает (хотя намнооого меньшая, чем в языках, эмулирующих понятие модуля через классы). Когда запись является типом данных, когда - интерфейсом, когда - реализацией интерфейса... Да ещё приходится налагать устные запреты на "смешивание" этих ролей - например, на наследование реализации (потому что это ведёт к ломке компонентной идеологии и всякого рода тонким проблемам).

Посему я бы вообще "откатил" RECORD практически до уровня первого Оберона, а для архитектурных задач ввёл пару спец. типов. Но это был бы далеко не OBJECT, как в Активном Обероне и Зонноне.

Именно о разъемах, а также о программной шине я и думал.
Не слишком это вяжется с утверждением, что (расширяемые) записи не несут архитектурной нагрузки.

Также непонятно, почему Зуев "уравнивает в правах" упорядоченную иерархию модулей (в Обероне) с простым линейным набором функций (в Си).

Как же так? Разве запись не является средством, объединяющим часть данных модуля в неделимую единицу? Разве после этого переменные внутри и снаружи записи всё ещё располагаются на одном уровне иерархии? Разве в Си запись названа структурой "от балды"?

Другое дело, что это не настолько ясный инструмент. Локальная структурность. Упрощающая жизнь не во всём проекте.

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

Такое чувство, что я не согласен с большинством утверждений Зуева.
Или во мне так разбушевалась необъективность?

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

Алексей Вячеславович, поскольку Вы смотрели мой томский доклад, позволю себе говорить в терминах "теории двух уровней":

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

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

Другими словами, то, что специалист хорош (или даже блестящ) как ум первого уровня/типа, совсем не переводит его на второй уровень/тип. Пример -- Д.Кнут (ср. 3 толстых тома Кнута с книжечкой Дейкстры, безусловного ума типа-II).

"Как только начинаются обобщения, начинается путаница." (С) некто Игорь Манцов (кинокритик есть такой, кстати, ум типа II за одно это суждение).

В общем, мне не ясно, какого хрена такое непропорциональное внимание уделяется суждениям Жени Зуева.

Мне лично очевидно, что его обобщающие суждения сильно кривые (одно утверждение, что в О. кроме модулей нет средств для борьбы со сложностью -- полная ахинея).

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

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

Если резюмировать коротко его мысль (в той части, с которой я согласен и что давно уже озвучивал) -- модулей Оберона недостаточно для ряда задач промышленного программирования. Они являются строительными блоками языка-ядра.

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

Можно мне тоже?
Я не согласен. Еще как являются. Старый пример расслоения функциональности списков по модулям (зав. списком + зав. содержанием) доказывает, что являются.

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

Еще как имеют. Экономят время. Чтобы можно было спокойно подумать о сути.

Например, я длинные посты некоторых авторов просто не читаю. Подумать страшно, сколько времени было бы потеряно, читая их.

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

EXTENSIBLE присутствует для совместимости с классическим Обероном.

А насчет смысловой путаницы -- путаница возникает при интерпретации понятий одной системы в терминах понятий других систем, что не есть, строго говоря, путаница внутри самой данной системы.

Этот вопрос обсуждался здесь: viewtopic.php?f=2&t=489. Хотелось бы увидеть ваше решение этой задачи -- введение в BlackBox кластеров без изменения языка КП.

Как я Вас понимаю. Нельзя свое драгоценное время растрачивать попусту. Это точно. Лучше маркировать людей. И фильтровать сообщения.

Мое решение Вы увидите в новом архитектурном языке в рамках проекта "Роса" (возможно, в одной из альтернатив такого языка).

В таком случае, утверждение Зуева неверно.
Или у меня что-то не в порядке с логикой?

Именно потому его и обсуждаем.
Наш человек работает в святая святых, грех не ознакомиться с его точкой зрения.
А если есть "критические нотки" (связанные с попыткой разобраться с этой точкой зрения), то ведь и причины есть: противоречащие друг другу высказывания, непонятное противопоставление модульности и раздельной компиляции (приходится гадать, не считает ли он Си языком с раздельной компиляцией), просто неверные (IMHO, конечно) утверждения и т.д. и т.п.