OberonCore

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

Общие сведения о системах
Для дальнейшего изложения принципиально неважно то, о какой системе идет речь, это может быть программная система (операционная система, система управления базами данных, система управления предприятием и т.п.), техническая система (судно, самолет, автоматическая линия и пр.), живая система, социальная система и т.д. и т.п. Поскольку все перечисленное выше (и многое другое, от атома до вселенной) является системами, то очевидно, что все это имеет нечто общее, что и позволяет отнести их к системам. Известно, что любая система обладает:
1. элементами;
2. связями между элементами.
При этом каждая система представляет собой единое целое и обладает свойством эмерджентности (http://ru.wikipedia.org/wiki/%D0%AD%D0%BC%D0%B5%D1%80%D0%B4%D0%B6%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C). Понятие "целое", неотделимо от понятия "цель" (это не просто однокоренные слова, но не будем (пока?) углубляться в этимологию этих слов). Система обладает целями, которые образуют три группы:
1. цели создателя (смысл, предназначение целого-системы);
2. цели владельца(ев) системы (цели над-уровня);
3. цели, вырабатываемые самой системой (для систем обладающих целеполаганием).
Для данной темы, представляет интерес вторая группа целей. Наличие "владельцев" определяет:
а) существования способа взаимодействия между "владельцем" и системой;
б) принципиальное наличие разных уровней.
В свою очередь, существование разных уровней (целого-системы) подразумевает и различие целей у уровней. Это принципиально важно, для рассмотрения данной темы. (Примечание. К сожалению, строгий вывод о существовании разных уровней целого не должен постулироваться, но он требует очень значительного объема изложения).
Различие целей каждого уровня проявляется в:
1. Задачах, решаемых каждым уровнем;
2. Способах межуровнего (с над- и под-уровнями) взаимодействия;
3. Структурном (или архитектурном) исполнении уровня.
Различие в задачах, решаемых на разных уровнях системы, предполагает и различие в используемых средствах взаимодействия элементов системы, то есть, в интерфейсах элементов системы. Интерфейсы элементов создаются/моделируются с помощью языка, и, следовательно, язык может быть более или менее адекватным/эффективным для решения конкретных задач данного уровня. Другими словами, каждый уровень системы обладает собственным набором интерфейсов и предъявляет свои требования к средствам взаимодействия между элементами и над-уровнем (и своими требованиями к языку, в частности).
С другой стороны, разнообразие средств взаимодействия не должно приводить к произвольности интерфейсов и случайному выбору языков. В противном случае, легко получить результат аналогичный тому, который получили "строители вавилонской башни". То есть, формирование межуровневых интерфейсов (создание/выбор языков, в частности) должно происходить по единым правилам, устанавливаемых для системы, как единого целого.

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

PS. Если эта тема представляет интерес, то можно привести иллюстрацию изложенного выше.

Представляет, приведите, пожалуйста.

Только сразу спрошу: что такое "язык"?
Для обсуждаемого вопроса, очевидно, собственно язык (EBNF) + библиотеки.
A формальная логика и арифметика на всех уровнях одинаковая. Т.е. про EBNF можно не заморачиваться.
Значит, библиотеки.

Но тогда тезис тривиализуется, если не ошибаюсь.
То есть разные библиотеки/словари для разных уровней, и всё.

В продолжение мысли Info21.

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

Свойства уровней системы
Нижний уровень
а) внешняя среда
Начнем рассмотрение с самого нижнего уровня. Ниже нижнего уровня находится среда исполнения, в качестве которой могут выступать: процессор, память и периферия; операционная система; различного рода RTL (run-time library); программные инструментальные средства и т.п. Соответственно, в зависимости от типа «слоя» под нижним уровнем меняется и интерфейс нижнего уровня и внешней среды (среды исполнения). Интерфейс с нижним уровнем представляет собой ни что иное, как язык на котором система «разговаривает» с внешней средой. Характерно, для данного этапа развития программной индустрии, почти полное отсутствие тщательно продуманных интерфейсов. Едва ли не единственным исключением является язык SQL, который позволяет прикладным системам единообразно взаимодействовать с различными SQL-DBMS (хотя и здесь все далеко не идеально). В подавляющем большинстве случаев внешняя среда представляется набором разрозненных библиотек, которые меняются от версии к версии, не всегда обеспечивая совместимость. Отсутствие единого стандартизованного интерфейса с внешней средой очень затрудняет разработку систем, делает сами системы зависимыми от конкретных версий используемых библиотек, исключает портирование систем на другие платформы без коренной их переработки под новую внешнюю (исполнительскую) среду. С другой стороны, существование интерфейса позволило бы согласовывать интересы/потребности, как разработчиков исполнительской среды, так и разработчиков прикладных систем. При этом и те и другие могли бы развивать и совершенствовать свои части независимо друг от друга при условии поддержания неизменного интерфейса.

б) структура уровня
Нижний уровень системы всегда является наиболее простым (примитивным) в любой системе. Основа этого уровня, как и любого другого, закладывается при формировании интерфейса данного уровня с последующим. В случае, когда интерфейс между данным и следующим уровнем является многообразным, то это многообразие образуется за счет композиций относительно небольшого количества типов базовых элементов. Правильная (строго обоснованная) декомпозиция нижнего уровня является необходимым условием для успешной реализации всей системы, обеспечивая ее надежность, гибкость и эффективность. Можно без потери общности провести аналогии с нижними уровнями других систем:
- все многообразие этого мира обеспечивается небольшим количеством типов атомов, а те, в свою очередь, тремя частицами (протон, электрон, нейтрон);
- все многообразие слов, предложений, текстов обеспечивается небольшим числом букв, а те, в свою очередь, уникальными звуками, которые задаются тремя компонентами: частотами, амплитудами и продолжительностями;
- все многообразие экономических форм, образовано небольшим числом типов предприятий, в основе которых лежат: предметы труда, средства труда и, собственно, живой труд;
- и т.д.
Нижний уровень, как правило, достаточно легко алгоритмизовать и для его реализации удобно применять императивные языки. Очень эффективно для реализации нижнего уровня использовать объектно-ориентированный анализ и проектирование. Дело в том, что интерфейс со следующим уровнем, с одной стороны, является декларацией, а с другой стороны, он представляет собой набор «полиморфных свойств», которые могут быть реализованы в иерархии классов сущностей (объектов). Но, важнее всего то, что хороший ООА позволяет предвосхитить/предсказать динамику развития элементов данного уровня системы и сделать развитие уровня наименее болезненным и наименее проблематичным.

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

Третий уровень
Для того, чтобы было проще понять суть третьего уровня, позволю себе ввести в рассмотрение еще одну концепцию: системы с обратной связью. Сразу сделаю оговорку, что "обратная связь" нужна далеко не всегда, то есть, является частным случаем. Однако использовать эту концепцию удобно в целях иллюстрации. Итак, система с обратной связью предполагает:
- наличие исполнительного устройства (в нашем случае, исполнительный - нижний уровень);
- наличие регистрирующих и задающих устройств, иногда эти устройства выполняют первичную обработку/преобразование сигналов/информации. В нашем случае - это второй уровень;
- обрабатывающих и анализирующих устройств. В нашем случае - третий уровень.
Исполнительное устройство/уровень выполняет некую полезную работу, на выходе из него происходит измерение показателей (съем и регистрация сигналов) контрольных характеристик продукта. Эти показатели переводятся в форму удобную для последующего анализа и передаются в анализатор. Анализатор оценивает (в простом случае сравнивает с эталоном) полученную информацию и, если необходимо, то вырабатывает компенсирующие воздействия, которые поступают на задающие устройства. Задающие устройства воздействуют на входные параметры исполнительного устройства. Анализатор может иметь еще один вход, на который поступают задающие/регулирующие сигналы из над-системы.
Соответственно, основной задачей третьего уровня (по принятой здесь терминологии) является логико-аналитическая обработка информации и выработка, при необходимости, регулирующих воздействий.
Можно посмотреть с другой стороны. Любая сущность нижнего уровня, выполняя полезную работу, может изменять свое собственное состояние. Наличие нескольких допустимых состояний, свидетельствует о том, что сущность способна различно реагировать на одни и те же внешние возмущения/сигналы/сообщения/вызовы, в зависимости от своего текущего состояния. Сущности второго уровня, при обращении к сущностям нижнего уровня могут/должны оценивать их состояния. В простом случае, можно перед обращением запросить состояние нижележащей сущности. Однако, если сущностей много и/или их состояние определить трудоемко (например, состояние сущности может зависеть от состояния "железа", сетевого соединения и т.п.), то опрос станет затратным по времени. Проще/эффективнее поддерживать "карту состояний" используемых сущностей. Очевидно, что оценка состояний используемых сущностей важна не сама по себе, а с точки зрения состояния самого объекта-владельца, его способности правильно реагировать на обращения к нему. Соответственно, при переходе к третьему (еще более высокому) уровню, оценка состояний становится самостоятельной (иногда нетривиальной) задачей.
И анализ, и оценка состояний фактически представляют собой обработку значительного количества правил. И, следовательно, здесь могут быть эффективно использованы языки логического программирования.

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

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

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

Спасибо, очень интересно.

По поводу функциональной природы, которую Вы хотели бы видеть у языков верхних уровней. Аргументы "за" понятны. Но по существу, эти аргументы связаны обычно с тем, что ФП снимает некоторые недостатки ИП.

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

Видимо, я не очень хорошо изложил... Речь шла не о "свободе от состояний"... а о том, что анализ состояний отдельная, порой, очень не простая задача. При относительно небольшом количестве элементов, можно использовать "конечные автоматы", но при большом (тем более, произвольно большом) числе элементов и их возможных состояний... задача выбора/принятия (оптимального для данных условий) решения... Не легко это. В свое время (лет 15 назад) для подобных задач я пользовался Прологом.

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

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

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

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

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

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

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

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

Вы, случайно эпистемологией не увлекаетесь?
Уж больно похожи рассуждения...
про системы... информационные уровни и т.п....

Системы - это моя работа. А мои увлечения ближе к гносеологии, поскольку... науки (в моем представлении) сейчас просто нет. Ученые есть, а науки... увы. Поэтому эпистемологией я бы и рад увлечься, но нет основы...

Ну почему же: Дж. Клир. Системология. Автоматизация решения системных задачи 1990 г. 538 с. Плюс не стоит сбрасывать со счетов как минимум два подхода к изучению систем: Классический и Статистический.
Ну, ещё есть причинно-следственный подход к системам.

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

PS. Давайте обсуждение эпистемологии и т.п. вынесем в отдельную ветвь обсуждения.

Да ладно.

Тут как с обогащением урана: в руде 235-го 0.1%, а после обогащения, в котле -- 2%. Ну, 4% максимум.
Всё равно на порядок больше.

Ядро U235 может и в руде энергию выдать, нет вопроса.
Но полноценная реакция идёт в котле. Хотя там балласта >95%.

Довольно точная аналогия, на мой взглядю, даже количественно.

Ага, понятно.

.NET?

Попробуйте почитать работу: Акимов О.Е. Естествознание. Курс лекций. - М:ЮНИТИ-ДАНА, 2001. Там автор как раз обсуждает механизмы познания и заодно то, видимо, исходя из чего Вы считаете, что науки сейчас нет