OberonCore

Тогда это не расширяемый язык. Это программы/комплексы на нем писаные расширяемые. Не следует подменять понятия.

Сам стиль мышления там не способствует жёсткости. Это - инструменты индивидуального выражения мысли индивида

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

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

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

Ну здравствуйте.

Понятие компонентно-ориентированного языка программирования кто отменил?

См. Шиперски; Пфистера, Губанова в статьях на ОберонКоре.

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

Абажите, Илья! У вас - противоречие! Разве вы его не замечаете?
Мы же говорим о КОМПОНЕНТНЫХ средах исполнения и языках их поддержки?
Основное качество таких сред какое? Скрывая реализацию, обеспечить связь.
Какая разница, какой кавардак внутри, в реализации компонента???
Компонент удовлетворяет соглашениям по статическим и динамическим интерфейсам? Всё - вопрос закрыт! Это - РАБОЧИЙ компонент.

Тут диалектика: работаем с каждым компонентом так, как будто не знаем его реализации...
Но знать-то её лучше знать.

Я за компонентный open-source. Не говоря про ситуации, где лучшей формой повторного использования является таки копи-паст, вместо порождения лишней зависимости наружу.

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

Ох, чего-то как-то вы - юлите, чесслово!
Мы же оговорили требование на удовлетворению статики и динамики в процессе общения с данным компонентом! Не нужны вам знания о его "кишках"!


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


...Ну, а теперь, сделайте ещё один шажок в своих рассуждениях! И к чему вы придёте? Да у же к готовой форме реализации вашего желания - ПАРАМЕТРИЗОВАННЫМ ШАБЛОНАМ Си++

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

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

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

Ну зачем же сразу С++? Это очень жестоко. Это не осторожно. У здешней публики на "С++" сразу условный рефлекс -- что-нибудь возразить. Не важно по теме или нет. Впрочем, вам повезло, Илья относится к тем не многим кто адекватно реагирует на С++.

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

Т.е. циклы допустим тоже не существуют? Ведь на этапе исполнения их нет. Зато есть всеми горячо любымый goto. (aka jmp)

Переменных тоже нет, кстати. Зато есть регистры.

Имен переменных частенько тоже нет.

И строк нет.

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

В Обероне я имею в рантайме практически всю информацию из compile-time; а ещё - имею тот же самый компилятор, который могу задействовать.

ОК. Как мне эту информацию из рантайма вытащить? Вот собрал я программу обероновскую посредством oo2c или xds, или pow, или Astrobe, и? Да, и где мне там найти компилятор. После того как мою программу пользователь поставил на машину.

Я про Блэкбокс. XDS и названные другие - это чисто компиляторы, с отбрасыванием обероновской идеи операционной среды.

В ББ у меня Meta, Kernel и DevCompiler, совершенно одинаково в любой момент от development-time до автономного run-time.

А теперь, внимание! Я ЭТОГО В ТОМ КЛАССЕ ЖЕЛЕЗЯК, которые используются в наших подсистемах, НЕ ИМЕЮ! Системы - достаточно большие, но - не на столько, что бы метаинформацию хранить! Там нужно ещё столько в табличном представлении функций иметь и просто - алгоритмов во внутренних флэшах, что поддержка оберон-решений просто не прокатывает.
Я ещё не упомянул на "потери места" на код "почленной" и "поэлементной" инициализации, который так любят в оберон-системах... С точки зрения наших систем, тысячи строчек поэлементного присвоения значений элементам массива, вместо memcpy, - совершенно неприемлемая и ничем не оправданная потеря памяти!

Условия понятны.

Думаю, что у Вас они лучше (оборудование помощнее), чем у НПЦ АП, с Графит-Флоксом.

И для таких условий как раз лучшим представляется ещё больше развить идею обобщённого программирования - т.е. уйти к генерационным инструментам, САПР-ам, с высокоуровневыми описаниями, в гнёзда которых могут вставляться низкоуровневые инструкции, например. Что и сделано вот у НПЦ.

Понимаю, что у Вас ещё и "зоопарк" платформ, да. Там выбор С понятен. А раз хочется обобщать - то и ++.

А я про Оберон, как про язык. И XDS это таки компилятора Оберона-2, как и все перечисленные мною (Astrobe -- это Oberon-07). А BB это вообще какой-то паскаль. Хоть и компонентный