Ответ на »сообщение 4318« (Антон Григорьев)
___________________________

Есть языки, в которые на уровне либо самого языка, либо СТАНДРТНЫХ библиотек встроены средства создания распределённых приложений. Java, например, или C#.
Формально, стандартные библиотеки и в C#, и в Java как раз очень маленькие.

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

Подобные размышления наталкивают на мысль о выведении средств управления кластерами в отдельный язык (именно язык), в большей степени декларативного характера, который описывает "топологию", инварианты, отношения, состояния. Это в чем-то близко направлению constraint programming.

Еще один немаловажный момент в этой цепочке рассуждений. Кластер при работе с модулями должен оперировать не штатными интерфейсами (DEFINITION), а верифицирующими интерфейсами (INTERFACE). Соответственно их синтаксис/структура определяются языком кластеров (кластеризации модулей).

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

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

Исключение -- это сущность, имеющая все основания рассчитывать на полноправное членство в наборе сущностей кластера.

Еще одна уязвимость Оберонов. Для обеспечения надежности (операционной) нужна обработка исключений. Мой опыт в этой области показал, что:
1. Исключения строятся как программные прерывания с делегированием полномочий по принятию решения на верхние уровни контроля исключений.
2. Низкоуровневые исключения (внутренние) должны всегда ретранслироваться в высокоуровневые (внешние).
3. Нужны "саркофаги" ("поглотители" исключений с автономным принятием решения) разного уровня вложенности.

Чтобы не было терминологической путаницы: исключительная ситуация -- это ситуация (условие), при которой возникает/генерируется исключение (exception) явно (вручную) или косвенно (автоматически).

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

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

Для работы с исключениями достаточно следующих вещей:
1. Выделение блока контроля исключений (зона чувствительности на предмет генерирования)
2. Выделение блока обработки исключений (зона распознавания и реакции)
3. Распознавание (перехват) исключения
4. Генерирование исключения

Блоки контроля могут выравниваться на границу модулей/процедур/методов, тогда не требуется их отдельно помечать. Блоки обработки можно выносить на "теневой" уровень. Это позволяет для одного и того же исходного текста задавать разные схемы обработки исключений, подключая их динамически в зависимости от требований проекта и режима эксплуатации системы.

>>> ...лебедь рвется в облака, рак пятится назад, а щука тянет в воду...
Есть определение лучше! Пришло приглашение на семинар ... прямо на злобу дня! :)

    "Персонал всегда чем-то занят. Он может быть перегружен, но при этом быть поразительно неэффективным! Почему? Обычно, нормальный персонал разгребает завалы, созданные особым видом сотрудников – «бобрами». По аналогии с особенностями поведения бобров в природе, "бобрами" в организации названы люди, посвятившие свою жизнь созданию завалов в любом виде деятельности, за которую они только берутся.
    Как же повысить эффективность существующих работников? Опыт показывает, что простое выявление и устранение из компании работников, создающих бардак и непродуктивность, само по себе повышает эффективность компании и оздоравливает внутреннюю атмосферу в коллективе. 
    Персонал не делает правильных вещей, просто потому что они правильные. Он делает их, потому что решает определенные задачи. Как эффективно помочь продуктивным работникам и заставить покинуть компанию скрытых «бобров» всех мастей – тема однодневного семинара «Как отстреливать «бобров в организациях»".

Ответ на »сообщение 4324« (Сергей Перовский)
___________________________

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

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

1. Оберону/КП нет необходимости пытаться перестроить весь мир под себя. Надо пользовать то, что есть (как "ненадежный" сервисный уровень).
2. Фундамент унифицированной (стандартной) библиотеки и ее архитектура должны быть тщательно продуманы.
3. Не надо игнорировать другие миры. Оба распространенных подхода: независимое сосуществование языков с последующей попыткой их интеграции на уровне случайных контактов, либо единая платформа для всего на свете (.NET, читай ООН) -- уже показали свои проблемы. Имеет смысл продумывать долгосрочное тесное сотрудничество взаимодополняющих "стран" со своими экономиками (например, Оберон/КП-Erlang/Haskell). С организацией максимально удобной инфраструктуры такой интеграции.

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

Ответ на »сообщение 4329« (Trurl)
___________________________

А перед этим он же отметил, что во вложенных модулях нет небходимости. ;-)

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

При этом исходит из того, что перед кластером стоят задачи:
1. Обеспечения высокоуровневой композиции модулей -- главных сущностей (в простейшем случае -- поименованный каркас-framework с ограничением прямых контактов на уровне модулей разных кластеров, соответственно, с иной трактовкой имен модулей/интерфейсов -- как "локальных" имен).
2. Предоставления средств контроля надежности (включая инварианты)
3. Обеспечения интерфейса для композиции с другими кластерами (но интерфейса иного плана, нежели DEFINITION). Этот интерфейс оперирует сущностями возможно иного порядка (не переменными, не константами, не типами, не процедурами языка Оберон, а например, состояниями и кое-чем еще).

Подобные размышления наталкивают на мысль о выведении средств управления кластерами в отдельный язык (именно язык), в большей степени декларативного характера, который описывает "топологию", инварианты, отношения, состояния. Это в чем-то близко направлению constraint programming.

Ответ на »сообщение 4238« (AVC)
___________________________

Руслан Богатырев, IMHO, правильно отметил отсутствие в Обероне более крупной конструкции, чем модуль, назвав ее "кластером"
А перед этим он же отметил, что во вложенных модулях нет небходимости. ;-)

Ответ на »сообщение 4303« (MS)
___________________________
Конечность является формальным признаком алгоритма.

А почему же тогда проблема завершаемости - одна из центральных в теории алгоритмов?

Ответ на »сообщение 4275« (Илья Ермаков)
___________________________
Насчет дженериков обсуждали много раз уже...
Легковесный полиморфизм не очень интересен ...
Полноценный параметрический полиморфизм полезен как раз для самых ценных штук - обобщенных алгоритмов, контейнеров и т.п., где он дает и обобщенность, и сохраняет высокое быстродействие
Мы тут пообсуждали, и я решил. :-)
"Легковесный" полиморфизм покрывает бОльшую часть того, что может предоставить параметрический полиморфизм.
"Полноценный" параметрический полиморфизм слишком тяжел и, собственно, не является параметрическим.