Поэтому, по моему мнению, одной из наиболее важных и интересных задач на современном этапе, является разработка системы языков: строгой концепции расширяемого множества языков для создания больших систем (более трех уровней).
А каковы Ваши соображения о природе языка для каждого уровня и ядре (с которого начинается расширение)?
Вообще Вы предполагаете, что параллельно для каждого уровня должны существовать язык спецификаций и язык программирования, или эти два назначения должны совмещаться в одном языке уровня?
alexus писал(а):
Было бы наивным предполагать, что сегодня можно без особых проблем создать систему, используя для каждого уровня наиболее пригодный/эффективный язык программирования. Не получится... Дело в том, что, не смотря на свои различия, языки должны иметь единую (хотелось бы сказать: семантическую/системную) основу. Однако современные языки разработаны не для создания систем, а для решения некоторого вполне определенного круга задач.
Хочется опять вспомнить Оккама и не умножать уровни и средства их реализации без необходимости. Можно ли понимать иерархию уровней создаваемой информатической системы (имеющей программируемые функции, хотя вообще-то необязательно - и просто оборудование тоже описывается на каком-то языке) следующим образом:
* класс "нижний уровень" связан со средой исполнения, класс м.б. определён в стольки вариантах, сколько существенных вариаций сред встретилось пользователям данной концепции (разработчику систем);
* класс "верхний уровень" связан с потребляющей системой (у Вас - "владельцем"), класс м.б. определён в стольки вариантах, сколько "профилей владельцев" практически потребовалось сформировать разработчику;
* класс "промежуточный уровень" вводится изначально между нижним и верхним, по необходимости число промежуточных уровней, требующих отдельного определения, наращивается добавлением (между промежуточным и нижним, верхним и промежуточным, соседними промежуточными.
Смысл в том, чтобы определять три семейства языков (по одному для каждого класса, а не уровня) и при разработке очередной системы выбирать из уже существующих средств (вариантов реализации) каждого класса. Каково Ваше мнение?
Я тут опираюсь и на концепцию "трёх схем", изначально сформулированную применительно к информационному моделированию (данных; см. IDEF1X-определение в выдержке, вложенной
в этом сообщении), но, по-видимому, приложимую и к алгоритмам и к исполнителям. Можно сопоставить верхнему уровню "схему для пользователя", нижнему - "схему для исполнителя (в частности, программно-аппаратной платформы)", промежуточному - "нейтральную схему".
Кстати, и Агафонов в следующем вложении в то же сообщение, по-моему, касался тех же вопросов...
Речь шла не о "свободе от состояний"... а о том, что анализ состояний отдельная, порой, очень не простая задача. При относительно небольшом количестве элементов, можно использовать "конечные автоматы", но при большом (тем более, произвольно большом) числе элементов и их возможных состояний... задача выбора/принятия (оптимального для данных условий) решения... Не легко это. В свое время (лет 15 назад) для подобных задач я пользовался Прологом.
Имеется в виду, наверное, принятие решений, заложенное в разрабатываемую систему, а не решений по её разработке? Анализ состояний самой системы в процессе разработки вроде продвинулся за последние годы... см. работу, выдержка из которой вложена
в это сообщение. В принципе эти же результаты можно использовать для изначального моделирования состояний системы в алгообстановке.
Кстати, в той же работе показаны пути сокращения "произвольно большого числа" ("взрыва") состояний...
Интерфейс с над-уровнем представляет собой некоторое множество операций/функций/деклараций, которые должен реализовать данный уровень. Интерфейс с нижележащим уровнем представляет из себя набор требований к операциям/функциям, которые необходимы данному уровню. Если разбираться более детально, то просматривая интерфейсы сверху-вниз можно увидеть логическую структуру системы (декомпозиция интерфейсов), где каждый уровень реализует вполне определенную часть логики системы. В таком случае, язык, принятый для данного уровня - это эффективное средство реализации/раскрытия этой логики (цели уровня). При этом, языки всех уровней подчиняются единым правилам. Об этом единстве всех языков и говорилось.
Возможно, это не так просто понять, поскольку сегодня языки программирования не имеют системной/объединяющей основы и не имеют привязки к конкретике задач (задаваемой интерфейсами).
Я бы сказал, что это можно понять на конкретном примере определения языков каждого уровня (свойств базового ядра и расширения для каждого уровня разрабатываемой системы, выбранной для примера, в т.ч. в форме указания для уровня существующего языка с предложениями по его коррекции для обеспечения единства). Вы можете сформулировать такой пример?
Проектирование системы начинается не с выбора языка, но с архитектуры системы. Глядя на Оберон, например, я бы не взялся "увидеть" систему, сделанную на его основе (тем более, учитывая, что разных(!) систем... более одной).
А нужно ли "увидеть", исходя только из определения языка (рассматриваемого как базовое ядро выражения смысла), если средствами Оберона (включая написанные на нём модули, содержание которых - типы, процедуры - образует расширения выразительного ядра) можно описать каждый уровень разрабатываемой системы? И каковы Ваши аргументы за то, что такое описание невозможно/нецелесообразно? Я вижу один - что нужно описывать смысл того, что делает модуль, "человекочитаемо" - для чего визуализировать исходный текст и сопоставлять структурам данных визуальные формы, где каждая величина занимает место как параметр, влияющий на вид/содержание этой формы. Но это никак не влияет на выбор самого языка - то же самое следует делать для любого выбранного ТЯП. И какой смысл выбирать для каждого уровня новый язык? Или Вы что-то иное имели в виду - что как раз надо для каждого уровня написать на этом языке что-то выражающее специфику именно этого уровня?