Ответ на »сообщение 5092« (Руслан Богатырев)
___________________________
Расширение типа -- это не ООП. Это средства, которые позволяют как получать схему с ООП, так и строить свои схемы (generic bus как пример).
Поехали по двадцать пятому разу...
Расширение типа и ООП семантически эквивалентны.
(Это generic bus - то, не ООП?)
Вопрос только в соответствии или несоответствии синтаксиса стилю мышления конкретного программиста и большему или меньшему удобству программирования различных задач.

Ответ на »сообщение 5073« (Стэн)
___________________________


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

Ответ на »сообщение 5093« (Руслан Богатырев)
___________________________

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

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

Ответ на »сообщение 5092« (Руслан Богатырев)
___________________________

Вывод: должны быть модули разных категорий (для реализуемых блоков целевой системы -- "свои" и "посторонние"). Для "посторонних" нужно уходить от процедурных вызовов и от механизма экспорта-импорта.

Собственно говоря, Вирт со своей командой абстрагировались от проблемы "посторонних" модулей, от проблемы коллективной работы многих десятков специалистов над одним проектом. Система Oberon (да и BlackBox, хоть и в меньшей степени) -- это системы индивидуального программирования. Эгоистические. Не удивительно, что Вирт и его коллеги не заморачивались проблемами масштабирования разработки (а тем более, промышленной разработки).

Сам язык Оберон (включая и его последующие диалекты), ушедший от физического разделения модуля на интерфейс и реализацию (как было в Modula-2), сделал шаг в направлении эгоизма.

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

Размышляя над проблемами неприятия Оберона программистским сообществом (и как языка, и как системы, и как подхода), пришел к выводу, что не последнюю (если не решающую) роль в этом сыграл технологический изоляционизм, заложенный Виртом в идею индивидуального программирования (а также моноязыковость). Т.е. для небольших групп исследователей, для программистов-одиночек -- это полезный инструмент (позволяет быстро конструировать требуемую программу/систему), но для полноценного использования в коллективной разработке имеет много недостатков. Врожденных.

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

Это никоим образом не отвергает нынешние работы по совершенствованию того же BlackBox, поскольку в проект новой ОС "Роса" вольются те, кто косметической правкой BlackBox никогда и не хотел бы заниматься.

Кроме того, до момента создания полноценного инструментария требуется несколько лет. И в этот период BlackBox может стать хорошим рабочим инструментом. Его наверняка придется дорабатывать (для целей реализации новой ОС). Это будет конверсия, польза тем, кто сосредоточился на BlackBox и хотел бы видеть, прежде всего, его развитие и совершенствование.

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

Ответ на »сообщение 5089« (Стэн)
___________________________

То что такое Oberon-технология? Есть у нее ключевая черта, которая отличает ее от всех остальных?

Если говорить коротко, то это две вещи, которые Вирт добавил к своему классическому Паскалю.

1. Модули (в Modula-2; перекочевали и в классический Оберон).
2. Расширение типа (в Обероне, подразумевает сборку мусора).

А также принцип прямого отображения языковых концепций на ОС (язык с библиотеками как самостоятельная ОС, способная работать и на голом железе, и поверх другой ОС).

Вот и все. Остальное (автоматическая сборка мусора, средства метапрограммирования, динамическая загрузка-выгрузка модулей, динамическая кодогенерация, не JIT) -- от лукавого. Полезная трактовка разных реализаций. Следствие первых двух вещей.

Расширение типа -- это не ООП. Это средства, которые позволяют как получать схему с ООП, так и строить свои схемы (generic bus как пример). Модули в пределе (когда язык сливается со своей ОС, как в случае Oberon System) превращаются в процессы этой ОС. А расширение типа играет роль фундамента межпроцессной коммуникации.

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

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

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

Это и есть средство для полноценного компонентного программирования. Когда модуль Оберона (наборы модулей) превращается в компонент/кластер (т.е. следует определенным требованиям работы в операционной среде и взаимодействия друг с другом).

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

Ответ на »сообщение 5089« (Стэн)
___________________________

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

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

Когда нужна динамика -- используете ран-тайм, который является микро-ОС и  рассматривает исполняемые модули (могут быть представлены в виде семантических деревьев Франца с целевой кодогенерацией на лету во время загрузки) в качестве единицы исполнения (своих процессов, работающих в едином адресном пространстве). Примеры: Oberon System, BlackBox.

Когда динамика не нужна -- считаете Оберон языком традиционным, где модуль не имеет исполняемой формы и линкуется в монолит (или схему с DLL -- без разницы). Пример: XDS (и один из режимов BlackBox).

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

Относительно статьи Губанова. На мой взгляд, модульность в Обероне, как и модульность вообще, он понимает весьма своеобразно. Я неоднократно оппонировал ему в этом форуме. Честно говоря, пересказывать все это, равно и то, что считаю Оберон-технологией, затруднительно. Скачайте к себе на компьютер этот форум (напр., по кускам, задав гранулированность вывода сообщений в 1000). Внимательно перечитайте мои высказывания. Из них можно составить некую картину. Будут вопросы, задавайте.

Зайдите на стр. http://www.europrog.ru/oberon.html . Там в самом низу есть ссылки на мои заметки по вопросам модульности. Давно хотел подготовить небольшую работу (заметно превышающую по объему статью, по сути -- книгу), где раскрыть эти вопросы достаточно обстоятельно, но есть проблемы со временем. А с учетом проекта по новой ОС это для меня стало малоприоритетным.

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

Модульность != компонентность, динамическая модульность == компонентность?

Ответ на »сообщение 5088« (Руслан Богатырев)
___________________________
>>> При этом модульность уже выполняет функцию архитектурного элемента только на уровне исходников, а не на уровне работающей программной системы.
>>> Нужно ли в исходных текстах правильно декомпозировать программу на модули? И вредны ли они для этого? Риторический вопрос.

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

А с другой, если по желанию можно сделать модульность, а можно не делать... Можно линковать, а можно - нет. Можно все, что угодно и даже немного больше... То что такое Oberon-технология? Есть у нее ключевая черта, которая отличает ее от всех остальных?

Ответ на »сообщение 5087« (Стэн)
___________________________

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

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

Нужно ли в исходных текстах правильно декомпозировать программу на модули? И вредны ли они для этого? Риторический вопрос.

Ответ на »сообщение 5086« (Geniepro)
___________________________
>>> А при чём здесь модульность-то? Можно делать компонентное ПО на языках, где нет понятия "модуль", так же как и модульные языки для создания некомпонентного ПО...

Все это конечно правильно, но если мы используем язык, где есть понятие "модуль", но самим механизмом модульности не пользуемся, то наверное некоторые проблемы становятся не актуальными... Но, как говориться, можно и на ассемблере все написать... Тогда зачем модули?
Тем неменее вопросы не снимаются. Если в языке есть понятие "модуля", да еще динамически загружаемого, то такой язык должен для каждого модуля обеспечивать некоторые инварианты на тот случай, если кто-то вдруг захочет все таки его куда-то динамически загрузить. И если я, решая некоторую задачу, заранее знаю, что никакая динамическая загрузка и конфигурация мне не нужна, то модульность в языке может помешать, так как будут наложены излишне жесткие пред- или пост- условия, которые в противном случае можно было бы ослабить...
Таким образом, возвращаясь немного назад, можно ли утверждать, что системы 24x365 - это и есть ниша применения Oberon-технологии с присущей ей динамической модульностью?