Изучаю UML и прочие языки/системы метамоделирования. Впечатления самые грустные: те же яйца, вид сбоку.
Те же деления на уровни, куча ограничений и прочее.
Есть ли что-нибудь более гибкое?
А пока, в связи с этим накарябал гипотетические фичи гипотетической системы, к которой я стремлюсь.
Надо бы обработать перед отправлением сюда, но думаю кое-что разобрать можно
Фичи располагаются в случайном порядке, как в голову взбрели.
==============8<===========================
Цель: построить мета-язык описания любых процессов (в частности программирования, ввода-вывода), более сложные функции которого выражаются ТОЛЬКО через набор базовых.
В UML такое отсутствует: сложные конструкции обрабатываются частным образом, а не с помощью базовых, отсюда — слишком много первоначальных определений (в машинном языке). К тому же чётко фиксированы мета-уровни: объект может быть экземпляром класса только соседнего уровня (3M->2M, 2M->Model, Model->Object).
Цель: мета-язык должен быть таким, чтобы результат преобразования L->MeL->L, где L — любой выбранный язык, а MeL — мета-язык, был семантически эквивалентен оригиналу. Т.е. атомарные конструкции должны быть способными описывать ЛЮБУЮ семантику, вплоть до квантовой.
++(Features):
* Время как координата? Лёгкая возможность добавления кода (захвата данных или подобного) в любое место уже написанного.
* Возможность вырождения в императивные, логические или чисто функциональные языки, путём ввода ограничений.
Императивный = "как делать"
Логический = "что нужно получить"
Функциональный = "что делать"
Чисто функциональный = функциональный, но вход-выход без сохранения состояния, т.е. созданные объекты неизменяемы.
* ! Редукция алгоритмов! Пример: primes = filter prime [1..] редукция в решето Эратосфена (т.е. исключение произведений простых чисел из натурального ряда, остаток — искомый ряд), т.к. проверять на делимость числа на все числа подряд — ненужная операция, достаточно проверки на делимость на простые числа меньше квадратного корня из исследуемого. Для такой редукции нужна полная развёртка операции остатка от деления (в атомарные операции).
* Как следствие редукции алгоритмов: реоптимизация машинного кода переведённого в метасистему.
* ! Выделение части реального времени (например верхний предел в %) на тестирование и оптимизацию используемых алгоритмов для текущих данных (в реальном времени, во время параллельной работы).
* родная "компиляция" в ANSI С и ANSI С++, ну и во внутреннее представление (для метасистемы и симуляции)
* Метасистема и язык написаны на самом мета-языке.
* Множественные операции, написанные НЕ через рекурсию. Рекурсивное описание — всего лишь частный случай.
* как можно более компактное (компактнее чем в тексте) и легко-понимаемое представление для человека, но при этом как можно более гибкое и мощное. Кстати, в UML наоборот, более громоздкое описание, по сравнению с текстом.
* достойное представление динамики. В статической графике — опять ограничения и недостатки? В динамике — как это вообще может выглядеть? Источник: UML Action Semantics.
* ввод как графической (формы и объекты) так и текстовой информации. Изменения должны сразу отражаться в остальных.
Ещё лучше: наличие множества (эквивалентных) представлений метаобъектов, в том числе — одно или несколько для пользователя (т.е. для конечного продукта).
* новые метатехнологии могут быть применены к существующим объектам. Пример: распараллеливание на кластерах для скорости, дублирование для надёжности и прочее, применительно к простому объекту, где ничего этого не планировалось. Источник: Oracle.
* отсутствие фиксированного текстового и графического синтаксиса!
1) Текстовый синтаксис определяется задаваемыми внешними правилами (например Extended Bakus-Naur Form), или описываются с помощью самого MeL. Может быть как обычным, так и pattern-matching !
2) Графический синтаксис настраивается с помощью редактора графических форм, или опять с помощью самого MeL.
* Изменяемая семантика. В других языках семантика фиксирована.
NB! Можно ли сделать семантику тоже настраиваемую изнутри???? Получится полностью модифицируемый язык, способный вырождаться в обычные! Более того, получится система моделирования ЧЕГО УГОДНО. 8-)
* Изменяемая строгость: аргументы вычисляются до вызова (Strict) или по мере необходимости (Non-strict). Реализуется легко, т.к. связи являются метаобъектами.
* ? Объекты могут быть множественные, иметь несколько частей, т.е. связи могут образовываться с конкретной частью объекта, а не со всем объектом. Простейший пример: In-Out. В UML для этих целей используется тройка InputPin <- DataFlow -> OutputPin.
* 1 placeholder заменяется на 1 объект; 2 связанных — на 2 объекта, и т.д.
? Возможность подмены цепочки placeholder-ов на другое число объектов. Например, 2 на 3 (дополнительный объект, все 3 объекта выполняют функцию 2-х запланированных), или наоборот, 2 на 1 (один объект выполняет функции обоих)
Нужно ли это вообще??
* свобода направления.
A --<<include>>--> B : "вызов" B из А
A <--<<extend>>-- B : B расширяет A, т.е. возможно В будет вызвано из А.
* возможность запуска исключений (ошибок).
* внутренняя файловая система — фактически объектная система.
* в качестве прикола: возможность писать трекерную музыку в MeL. (следствие изменяемого синтаксиса и семантики)
--(Features)
Цель: Каждый объект может изменять любой другой объект (любого мета-уровня!) или его связи. Как следствие — программа, ведущая себя как самомодифицирующаяся. После компиляции она может стать обычной статической, хотя умный компилятор должен уметь при необходимости делать и модифицирующуюся.
Цель: всё что не требует внешних данных можно выполнить на этапе компиляции. Можно поставить ограничение соотношения <размер результата>/(<время выполнения>*<требуемый для выполнения размер памяти>). Т.е. короткая по времени функция, дающая длинный результат, останется кодом, а не результатом.
Наследование в С++ = безымянное включение члена класса.
Цель: в программировании (в частности) использовать структуры расширяющие, но не ограничивающие возможности дальнейшего использования. Ограничения должны вводится, когда они _НЕОБХОДИМЫ_.
Из физики: непрерывное число измерений — что это может быть? Объединение измерений? Аналогия с уровнями UML (3М, 2М, Модель, Объект) — уровни можно объединить, связи объектов оставить. Объект сможет стать экземпляром не соседнего (в оригинале), а любого уровня (3М -> Объект).
Привет тебе, брат по разуму limax, Вы писали:
L>Изучаю UML и прочие языки/системы метамоделирования. Впечатления самые грустные: те же яйца, вид сбоку.
L>Те же деления на уровни, куча ограничений и прочее.
Иначе обычные человеческие мозги просто не управятся с любой, даже простейшей задачей. UML — это способ документирования твоих мыслей, и он на себя функций берёт не более, чем... ну, скажем, язык символов принципиальных электрических схем — транзисторы, резисторы, микросхемы и прочее. Когда-то я тоже думал, что на UML можно адекватно описывать семантики (в т.ч. — динамические) разных уровней. Оказалось, что можно, конечно... в Notes, очень удобно.
L>Есть ли что-нибудь более гибкое?
Есть. Точно знаю. Мозг. Более гибкого инструмента в распоряжении человека пока нет. Ещё — язык квадратиков, кружочков и стрелочек с пометками.
L>А пока, в связи с этим накарябал гипотетические фичи гипотетической системы, к которой я стремлюсь. L>Надо бы обработать перед отправлением сюда, но думаю кое-что разобрать можно L>Фичи располагаются в случайном порядке, как в голову взбрели.
Угу, мечты всегда беспорядочны.
L>==============8<=========================== L>Цель: построить мета-язык описания любых процессов (в частности программирования, ввода-вывода), более сложные функции которого выражаются ТОЛЬКО через набор базовых.
Язык программирования C++. Минимальная базовая семантика — даже операции ввода-вывода отсутствуют. Богатые средства комбинирования объектных семантик. Все сложные функции выражаются (кстати, не "выражаются", а создаются!) через набор базовых.
L>В UML такое отсутствует: сложные конструкции обрабатываются частным образом, а не с помощью базовых, отсюда — слишком много первоначальных определений (в машинном языке). К тому же чётко фиксированы мета-уровни: объект может быть экземпляром класса только соседнего уровня (3M->2M, 2M->Model, Model->Object).
Дык! Потому-то и появляются разные "уровни", поскольку людям проще оперировать сложными семантиками, разбивая их на "уровни" или "срезы" или "схемы" и прочее. Реальные объекты вообще состоят из атомов и молекул с (обращаю твоё внимание) фиксированной семантикой. Кроме того, набор базовых символов UML — ИМХО, весьма перегруженная вещь и ты правильно заметил, что вместо цельных символов логично использовать именованные композиции. Ну так поди докажи это оболваненному COM-ом и прочей дребеденью миру?
L>Цель: мета-язык должен быть таким, чтобы результат преобразования L->MeL->L, где L — любой выбранный язык, а MeL — мета-язык, был семантически эквивалентен оригиналу. Т.е. атомарные конструкции должны быть способными описывать ЛЮБУЮ семантику, вплоть до квантовой.
Ты поймал верную ниточку, а дальше размечтался и ушёл в неизвестность. Ну так выдели её из этого абзаца. Даю наводку — ты точно сформулировал её в последнем предложении.
А вот теперь прокомментирую твои мечтания. Мне они показались очень-очень интересными. И начну сразу с того, что ты ставишь исходную задачу весьма обобщённо, а посылки формулируешь в частных семантиках. Это — следствия.
L>++(Features):
L>* Время как координата? Лёгкая возможность добавления кода (захвата данных или подобного) в любое место уже написанного.
Нет ничего проще! Текстовый редактор + шаловливые ручонки. Вопрос на самом деле не в добавлении кода как такового (это — достаточно тривиальная задача), а в сохранении системы в состоянии, удовлетворяющем требованиям, ради удовлетворения которых она создана. Таким образом, имеем необходимости: а) описания требований к системе, б) глубокой интроспекции изменяемого кода, для верификации соответствия изменённых структур предъявляемым требованиям.
А ещё в связи с этим одно наблюдение. Есть такой продукт Rational RequisittePro, знакОм, наверное? Когда я его только начинал осваивать, я всё искал возможности отобразить семантику требований на создаваемую программу. Недолго искал — дня два. Пока не понял, что во фразе "управление требованиями", которыми характеризуется Requsitte главное — это "управление" (которое выражается в сопоставлении флажков требованиям и некоторой структуре перепинываний требований от пользователя к пользователю на их "утверждение", "одобрение", "верификацию" и т.п.), а "требование" это вовсе не семантическая структура, а так... клочок бумаги, пометка на полях и не более того. Просто я её прочёл неправильно — RequsittePro — это удобная, но ни к чему не обязывающая записная книжка. Примерно та же история и с UML.
L>* Возможность вырождения в императивные, логические или чисто функциональные языки, путём ввода ограничений. L> Императивный = "как делать" L> Логический = "что нужно получить" L> Функциональный = "что делать" L> Чисто функциональный = функциональный, но вход-выход без сохранения состояния, т.е. созданные объекты неизменяемы.
В принципе, такая задача решаема, при выборе подходящего базиса, вопрос только в целесообразности её решения. Может быть, лучше сразу ассемблер генерировать и не кувыркаться?
L>* ! Редукция алгоритмов! Пример: primes = filter prime [1..] редукция в решето Эратосфена (т.е. исключение произведений простых чисел из натурального ряда, остаток — искомый ряд), т.к. проверять на делимость числа на все числа подряд — ненужная операция, достаточно проверки на делимость на простые числа меньше квадратного корня из исследуемого. Для такой редукции нужна полная развёртка операции остатка от деления (в атомарные операции).
Угу, но прикинь себе нагруженность базовой системы базовыми же математическими аксиомами. А методы поиска по ним? Нет, в принципе можно перебирать всё-всё-всё в поисках наиболее подходящего, но критерии завершённости... с этим проблема...
L>* Как следствие редукции алгоритмов: реоптимизация машинного кода переведённого в метасистему.
Как там у Кнута — "Преждевременная оптимизация — источник..."
L>* ! Выделение части реального времени (например верхний предел в %) на тестирование и оптимизацию используемых алгоритмов для текущих данных (в реальном времени, во время параллельной работы).
Очень интересная мысль.
L>* родная "компиляция" в ANSI С и ANSI С++, ну и во внутреннее представление (для метасистемы и симуляции)
ИМХО, это — игрушки, поскольку C и C++ — инструментальные языки и никакой необходимости в генерации исходного кода на них — нет.
L>* Метасистема и язык написаны на самом мета-языке.
Браво.
L>* Множественные операции, написанные НЕ через рекурсию. Рекурсивное описание — всего лишь частный случай.
Соображаешь.
L>* как можно более компактное (компактнее чем в тексте) и легко-понимаемое представление для человека, но при этом как можно более гибкое и мощное. Кстати, в UML наоборот, более громоздкое описание, по сравнению с текстом.
Кстати, его более трудно сотоавлять, хотя и порой проще читать.
L>* достойное представление динамики. В статической графике — опять ограничения и недостатки? В динамике — как это вообще может выглядеть? Источник: UML Action Semantics.
UAS — это источник проблемы или чего?
L>* ввод как графической (формы и объекты) так и текстовой информации. Изменения должны сразу отражаться в остальных. L>Ещё лучше: наличие множества (эквивалентных) представлений метаобъектов, в том числе — одно или несколько для пользователя (т.е. для конечного продукта).
Здраво. C++ — это всего лишь один из способов представления внутренней структуры программы — не более того.
L>* новые метатехнологии могут быть применены к существующим объектам. Пример: распараллеливание на кластерах для скорости, дублирование для надёжности и прочее, применительно к простому объекту, где ничего этого не планировалось. Источник: Oracle.
Так, одна просьба убери слово "новые", оно уже у всем оскомину набило. Просто "новое" при нынешнем состоянии IT-отрасли часто ассоциируется с: "для идиотов, идидотичнее старых".
L>* отсутствие фиксированного текстового и графического синтаксиса! L>1) Текстовый синтаксис определяется задаваемыми внешними правилами (например Extended Bakus-Naur Form), или описываются с помощью самого MeL. Может быть как обычным, так и pattern-matching !
Эх, раззудись рука. См. моё примечание в конце поста. Обращаю твоё внимание, что pattern-ы сами по себе наследники той парадигмы, для которой они сформулированы.
L>2) Графический синтаксис настраивается с помощью редактора графических форм, или опять с помощью самого MeL.
Rational пытается делать шаги в этом направлении, но пока...
L>* Изменяемая семантика. В других языках семантика фиксирована. L>NB! Можно ли сделать семантику тоже настраиваемую изнутри???? Получится полностью модифицируемый язык, способный вырождаться в обычные! Более того, получится система моделирования ЧЕГО УГОДНО. 8-)
Которая никак абсолютно не будет работать. Ты забываешь о главном — у базовой системы (компьютера, то бишь) все семантики фиксированы до предела. Если это регистр, то это регистр, если это адресная шина, то адресная шина. Вся гибкость компьютеров следует из простого постулата о том, что система S может быть описана в терминах системы G, если S выразима в символах G. А прикол в том, что благодарая системе команд центрального процессора компьютера (это и есть базовый язык описания моделируемой системы), а также наличию оперативной памяти компьютеры могут моделировать системы с очень сложной семантикой. Прикинь себе сложность системы, которую можно описать 256 командами в 1M памяти. Собственно, я имею ввиду, что от необходимости базовой элементарной семантики ты никуда не денешься. Приятно складывать кубики то в башню, то в автомобиль, но должны быть кубики.
L>* Изменяемая строгость: аргументы вычисляются до вызова (Strict) или по мере необходимости (Non-strict). Реализуется легко, т.к. связи являются метаобъектами.
И ни на что реально не влияет (в глобальном масштабе), поскольку если включающая система требует строгого определения типа, то его по-любому придётся выполнять. Короче, ИМХО, в таком виде — рюшечки.
L>* ? Объекты могут быть множественные, иметь несколько частей, т.е. связи могут образовываться с конкретной частью объекта, а не со всем объектом. Простейший пример: In-Out. В UML для этих целей используется тройка InputPin <- DataFlow -> OutputPin.
Роковая ошибка. Я понимаю, хочется всего и сразу. Если объект имеет несколько частей, то зачем всё усложнять? Это же очень просто — объект состоит из нескольких объектов же. Вот и всё. Далее — см. агрегация, ассоциация и т.п.
L>* возможность запуска исключений (ошибок).
Ну... за образец семантики можно принять C++... или CLU.
L>* внутренняя файловая система — фактически объектная система.
Так файловая или объектная? Термин "объект" может быть определён в рамках определения термина "файловая система", но вот наоборот...
L>* в качестве прикола: возможность писать трекерную музыку в MeL. (следствие изменяемого синтаксиса и семантики)
Мда... какофония — тоже музыка своего рода. Симфонии здесь не получится... по крайней мере — сразу...
L>--(Features)
А почему "--" ?
L>Цель: Каждый объект может изменять любой другой объект (любого мета-уровня!) или его связи. Как следствие — программа, ведущая себя как самомодифицирующаяся. После компиляции она может стать обычной статической, хотя умный компилятор должен уметь при необходимости делать и модифицирующуюся.
Тогда этот компилятор практически ничего не должен делать, всё необходимое сделает сама программа.
L>Цель: всё что не требует внешних данных можно выполнить на этапе компиляции. Можно поставить ограничение соотношения <размер результата>/(<время выполнения>*<требуемый для выполнения размер памяти>). Т.е. короткая по времени функция, дающая длинный результат, останется кодом, а не результатом.
Нужно внести ещё понятие времени, ну ты правильно подметил это ранее.
L>Наследование в С++ = безымянное включение члена класса.
Обобщи эту посылку.
L>Цель: в программировании (в частности) использовать структуры расширяющие, но не ограничивающие возможности дальнейшего использования. Ограничения должны вводится, когда они _НЕОБХОДИМЫ_.
То есть, ограничение — это часть семантики структуры. А вернее — семантика структуры всегда автоматически обладает теми или иными ограничениями.
L>Из физики: непрерывное число измерений — что это может быть? Объединение измерений? Аналогия с уровнями UML (3М, 2М, Модель, Объект) — уровни можно объединить, связи объектов оставить. Объект сможет стать экземпляром не соседнего (в оригинале), а любого уровня (3М -> Объект).
А вот гонять с уровня на уровень, ИМХО, не стоит. Тогда уж проще вообще не вводить уровней абстракции как обязательной части системы. Не зацикливайся ты так на UML-ных структурах. На них свет клином не сошёлся. Пусть себе предлагает деления тем или иным способом.
L>Итого, изменяемые определения: синтаксис, семантика (!), передача управления (!!), строгость (!!!)
Выглядит заманчиво, хотя на самом деле не всё так уж "золото на голубом".
L>==============8<===========================
L>Вот такие вот запросы, да?
Нормальные запросы неиспорченного "индустриальым подходом" человека. Постарайся их логичнее изложить. Найдёшь и свои собственные противоречия и кучу бардака вокруг. И вообще — дерзай.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
L>>==============8<=========================== L>>Цель: построить мета-язык описания любых процессов (в частности программирования, ввода-вывода), более сложные функции которого выражаются ТОЛЬКО через набор базовых.
ГВ>Язык программирования C++. Минимальная базовая семантика — даже операции ввода-вывода отсутствуют. Богатые средства комбинирования объектных семантик. Все сложные функции выражаются (кстати, не "выражаются", а создаются!) через набор базовых.
C++ несёт слишком много уточняющей информации, которая к программированию не относится, а относится к оптимизации. Я понимаю, можно конечно использовать сплошь и рядом огромные (и гибкие) объекты с метаструктурой на виртуальных функциях, но где взять компилятор, который всё это редуцирует? К тому же атомами там являются int-ы, char-ы и прочее, но не объекты. Я же хочу, чтобы МЕТАобъект был минимальной структурой, а int, char и прочая шалупонь являлись структурами построенными на основе атомов (включая свойства и операции).
L>>В UML такое отсутствует: сложные конструкции обрабатываются частным образом, а не с помощью базовых, отсюда — слишком много первоначальных определений (в машинном языке). К тому же чётко фиксированы мета-уровни: объект может быть экземпляром класса только соседнего уровня (3M->2M, 2M->Model, Model->Object).
ГВ>Дык! Потому-то и появляются разные "уровни", поскольку людям проще оперировать сложными семантиками, разбивая их на "уровни" или "срезы" или "схемы" и прочее. Реальные объекты вообще состоят из атомов и молекул с (обращаю твоё внимание) фиксированной семантикой. Кроме того, набор базовых символов UML — ИМХО, весьма перегруженная вещь и ты правильно заметил, что вместо цельных символов логично использовать именованные композиции. Ну так поди докажи это оболваненному COM-ом и прочей дребеденью миру?
Деление на уровни можно оставить, но не делать его фиксированным и навязанным. Т.е. "хочешь — используй, хочешь — нет, а хочешь наваяй свои".
А насчёт "фиксированной" семантики окружающего мира я очень сомневаюсь. Мы слишком мало знаем (а точнее хотим знать).
L>>Т.е. атомарные конструкции должны быть способными описывать ЛЮБУЮ семантику, вплоть до квантовой.
ГВ>Ты поймал верную ниточку, а дальше размечтался и ушёл в неизвестность. Ну так выдели её из этого абзаца. Даю наводку — ты точно сформулировал её в последнем предложении.
Гы? И что же в этом предложении такого? Про глобальность или про кванты?
ГВ>А вот теперь прокомментирую твои мечтания. Мне они показались очень-очень интересными. И начну сразу с того, что ты ставишь исходную задачу весьма обобщённо, а посылки формулируешь в частных семантиках. Это — следствия.
L>>++(Features):
L>>* Время как координата? Лёгкая возможность добавления кода (захвата данных или подобного) в любое место уже написанного.
ГВ>Нет ничего проще! Текстовый редактор + шаловливые ручонки.
Текстовый редактор?! Ну добавил ты сохранение объекта в середину кода, чтобы использовать это значение потом. Затем изменил программу и использование значения стало не нужно. Появился неиспользуемый мусор, который нужно убирать вручную. Мне же нужнен "линк" в середину кода (и временной шкалы), который сам отваливается, когда больше не нужен.
Замечу, что я визуалист. Дальше объяснять?
L>>* Возможность вырождения в императивные, логические или чисто функциональные языки, путём ввода ограничений.
ГВ>В принципе, такая задача решаема, при выборе подходящего базиса, вопрос только в целесообразности её решения. Может быть, лучше сразу ассемблер генерировать и не кувыркаться?
Зачем ассемблер? Мне такое вырождение может и не пригодится, но люди не умеют пользоваться всем сразу, и обычно большие возможности становятся основным источником ошибок. Кстати, другого объяснения рождению новых, всё более убогих языков я не нахожу. Поэтому для ограждения программы от посягательств человека такие вырождения просто необходимы.
Простейший пример: чисто функциональный язык. Если разрешить изменение объектов после их создания, то весь замысел летит к чёрту.
К тому же такие ограничения могут вводиться в зависимости от поставленной задачи.
L>>* ! Редукция алгоритмов! Пример: primes = filter prime [1..] редукция в решето Эратосфена.
ГВ>Угу, но прикинь себе нагруженность базовой системы базовыми же математическими аксиомами. А методы поиска по ним? Нет, в принципе можно перебирать всё-всё-всё в поисках наиболее подходящего, но критерии завершённости... с этим проблема...
Перебор — ну его к богу. Анализировать надо, а не перебирать. И анализировать не результат, а сам алгоритм. Не думаю, что это так уж невозможно, как принято считать.
L>>* Как следствие редукции алгоритмов: реоптимизация машинного кода переведённого в метасистему.
ГВ>Как там у Кнута — "Преждевременная оптимизация — источник..."
Это как раз не преждевременная. Реоптимизация готовых программ, не тобой написанных. Фактически: дизассемблирование -> анализ -> оптимизация -> компиляция. А вот любая программа на С++ — пример преждевременной (и неверной) оптимизации, т.к. чтобы вообще что-то написать, приходится описывать детали. Функциональные языки (в частности Haskell) мне тем и нравятся, что изначально описывается действие, а не его детали. Частично, конечно, но уже неплохо.
L>>* родная "компиляция" в ANSI С и ANSI С++, ну и во внутреннее представление (для метасистемы и симуляции)
ГВ>ИМХО, это — игрушки, поскольку C и C++ — инструментальные языки и никакой необходимости в генерации исходного кода на них — нет.
Я же сказал: компиляция! Не писать же компилятор для каждой системы отдельно? А так в С++ скомпилировал, а там пусть GCC мучается.
А не хочешь статически компилировать — есть внутреннее представление (или байт-код, если угодно), который используется интерпретатором/симулятором.
L>>* как можно более компактное (компактнее чем в тексте) и легко-понимаемое представление для человека, но при этом как можно более гибкое и мощное. Кстати, в UML наоборот, более громоздкое описание, по сравнению с текстом.
ГВ>Кстати, его более трудно сотоавлять, хотя и порой проще читать.
Угу. Вот и хочу, чтобы было легко "писать". Т.е. стоит подумать над интерфейсом вообще.
L>>* достойное представление динамики. В статической графике — опять ограничения и недостатки? В динамике — как это вообще может выглядеть? Источник: UML Action Semantics.
ГВ>UAS — это источник проблемы или чего?
Источник мысли. В UAS пока всё выглядит довольно убого. Интересно было бы взглянуть на будущий UML 2.0.
L>>* новые метатехнологии могут быть применены к существующим объектам. Пример: распараллеливание на кластерах для скорости, дублирование для надёжности и прочее, применительно к простому объекту, где ничего этого не планировалось. Источник: Oracle.
ГВ>Так, одна просьба убери слово "новые", оно уже у всем оскомину набило. Просто "новое" при нынешнем состоянии IT-отрасли часто ассоциируется с: "для идиотов, идидотичнее старых".
Новые не для нас, а для программы. Т.е. те, которые в данной программе/объекте не использовались и не подразумевались.
L>>* Изменяемая семантика. В других языках семантика фиксирована. L>>NB! Можно ли сделать семантику тоже настраиваемую изнутри???? Получится полностью модифицируемый язык, способный вырождаться в обычные! Более того, получится система моделирования ЧЕГО УГОДНО. 8-)
ГВ>Которая никак абсолютно не будет работать.
Почему нет? С точки зрения семантики это будет выглядеть как цепочка семантик от версии №1 до N-ной, где каждая следующая использует предыдущую. Понятно, что на самом деле можно оставить всего одну базовую, но для внутреннего представления. Внешняя же будет изменяемой.
L>>* ? Объекты могут быть множественные, иметь несколько частей, т.е. связи могут образовываться с конкретной частью объекта, а не со всем объектом. Простейший пример: In-Out. В UML для этих целей используется тройка InputPin <- DataFlow -> OutputPin.
ГВ>Роковая ошибка. Я понимаю, хочется всего и сразу. Если объект имеет несколько частей, то зачем всё усложнять? Это же очень просто — объект состоит из нескольких объектов же. Вот и всё. Далее — см. агрегация, ассоциация и т.п.
Неважно. Я просто думал, с какой стороны ещё можно "превратить бетон в резину".
L>>* внутренняя файловая система — фактически объектная система.
ГВ>Так файловая или объектная? Термин "объект" может быть определён в рамках определения термина "файловая система", но вот наоборот...
А бог его знает. Объектная наверное. Для большей гибкости. Мне очень многого не хватает в сегодняшних файловых системах. Например: не древовидная, а графовидная структура каталогов;
L>>--(Features)
ГВ>А почему "--" ?
Это закрывающая скобка к ++()
L>>Цель: Каждый объект может изменять любой другой объект (любого мета-уровня!) или его связи. Как следствие — программа, ведущая себя как самомодифицирующаяся. После компиляции она может стать обычной статической, хотя умный компилятор должен уметь при необходимости делать и модифицирующуюся.
ГВ>Тогда этот компилятор практически ничего не должен делать, всё необходимое сделает сама программа.
Ну исходный код сам по себе ничего не может. Он кем-то должен компилироваться или интерпретироваться.
L>>Наследование в С++ = безымянное включение члена класса.
ГВ>Обобщи эту посылку.
Т.е.? Просто пытался свести к минимуму различия между наследованием и включением, т.к. деление там не нужно. Предок в С++ — фактически член класса, только безымянный.
L>>Цель: в программировании (в частности) использовать структуры расширяющие, но не ограничивающие возможности дальнейшего использования. Ограничения должны вводится, когда они _НЕОБХОДИМЫ_.
ГВ>То есть, ограничение — это часть семантики структуры. А вернее — семантика структуры всегда автоматически обладает теми или иными ограничениями.
Угу. Но можно ведь подумать и над другими принципами? Развлекаюсь...
Эта мыслЯ у меня вытекла из идеи "программирование ограничениями". Т.е. описываешь что тебе нужно, а остальное — дело компа. Например сортировка состоит из одного постусловия: множество элементов такое же, но элементы распологаются в неубывающем порядке. Какой алгоритм применять, и применять ли вообще — пусть метасистема кумекает.
L>>Из физики: непрерывное число измерений — что это может быть? Объединение измерений? Аналогия с уровнями UML (3М, 2М, Модель, Объект) — уровни можно объединить, связи объектов оставить. Объект сможет стать экземпляром не соседнего (в оригинале), а любого уровня (3М -> Объект).
ГВ>А вот гонять с уровня на уровень, ИМХО, не стоит. Тогда уж проще вообще не вводить уровней абстракции как обязательной части системы. Не зацикливайся ты так на UML-ных структурах. На них свет клином не сошёлся. Пусть себе предлагает деления тем или иным способом.
Именно. Я уже рассказал про необязательное деление.
L>>Итого, изменяемые определения: синтаксис, семантика (!), передача управления (!!), строгость (!!!)
ГВ>Выглядит заманчиво, хотя на самом деле не всё так уж "золото на голубом".
Не забывай, что это не исследование, а случайные идеи.
L>>==============8<===========================
L>>Вот такие вот запросы, да?
ГВ>Нормальные запросы неиспорченного "индустриальым подходом" человека. Постарайся их логичнее изложить. Найдёшь и свои собственные противоречия и кучу бардака вокруг. И вообще — дерзай.
Здравствуйте, WolfHound, Вы писали:
WH>А как на счет SmallTalk и компания судя по тому что я читал оно то что тебе надо.
Ни в коем случае. У меня основное требование: изменяемый синтаксис (и не только текстовый!). Так что SmallTalk со своим убогим синтаксисом, ну никак не подходит.
Have fun: Win+M, Ctrl+A, Enter
Re: Метатехнологии. Что есть? Что возможно?
От:
Аноним
Дата:
04.03.03 10:58
Оценка:
Здравствуйте, limax, Вы писали:
L>Цель: построить мета-язык описания любых процессов (в частности программирования, ввода-вывода), более сложные функции которого выражаются ТОЛЬКО через набор базовых. L>В UML такое отсутствует: сложные конструкции обрабатываются частным образом, а не с помощью базовых, отсюда — слишком много первоначальных определений (в машинном языке). К тому же чётко фиксированы мета-уровни: объект может быть экземпляром класса только соседнего уровня (3M->2M, 2M->Model, Model->Object).
Уф.. Посмотри (если найдешь) полный стандарт на SDL, там такие трансформации описываются.
К сожаленью, имея строгий математический базис , SDL не удобен для практического применения в областях, не связанных с телекоммуникациями.
L>* ! Выделение части реального времени (например верхний предел в %) на тестирование и оптимизацию используемых алгоритмов для текущих данных (в реальном времени, во время параллельной работы).
Что-то делается здесь в рамках UML2 Real-time profile.
L>* родная "компиляция" в ANSI С и ANSI С++, ну и во внутреннее представление (для метасистемы и симуляции)
Симуляцию внутренниго представления не нужна. Customer-ы ее не хотят. Им надо видеть как работает реальный код (т.е. сгенеренный из модели). Особенно против симуляции выступает представители аэрокосмической промышленности и военные.
Нужно лишь соотв. образом обработать генеренный код так, что была возможнасть бегать по нему на уровне модели.
L>* как можно более компактное (компактнее чем в тексте) и легко-понимаемое представление для человека, но при этом как можно более гибкое и мощное. Кстати, в UML наоборот, более громоздкое описание, по сравнению с текстом.
Есть текстовое представление для UML2. Есть даже тулы поддерживающие его : Telelogic Tau/Developer. Синтаксис похож на С++.
L>* достойное представление динамики. В статической графике — опять ограничения и недостатки? В динамике — как это вообще может выглядеть? Источник: UML Action Semantics.
UML Action Semantics. от 2U Consr забавен, но перегружен ненужными вещами. Pin-ы не нужны.
L>* ввод как графической (формы и объекты) так и текстовой информации. Изменения должны сразу отражаться в остальных. L>Ещё лучше: наличие множества (эквивалентных) представлений метаобъектов, в том числе — одно или несколько для пользователя (т.е. для конечного продукта).
Telelogic Tau/Developer. Уже есть и работает.
L>* отсутствие фиксированного текстового и графического синтаксиса!
Эээ. Без фиксированого синтаксиса не сделаешь парсер.
L>* Изменяемая семантика. В других языках семантика фиксирована. L>NB! Можно ли сделать семантику тоже настраиваемую изнутри???? Получится полностью модифицируемый язык, способный вырождаться в обычные! Более того, получится система моделирования ЧЕГО УГОДНО. 8-)
А как ее чекать ?? Тогда надо описывать правила ее проверки, правила изменения правил проверки.
Тормозить будет.... Не нужно.
L>Цель: Каждый объект может изменять любой другой объект (любого мета-уровня!) или его связи. Как следствие — программа, ведущая себя как самомодифицирующаяся. После компиляции она может стать обычной статической, хотя умный компилятор должен уметь при необходимости делать и модифицирующуюся.
Не нужно. Много затрат на поддержку. А если вы генерите код для встраиваемой системы ?
Там серьезные требования на оптимизацию и надежность. Самомодифицируемый код — ненадежн.
Здравствуйте, limax, Вы писали:
L>Ни в коем случае. У меня основное требование: изменяемый синтаксис (и не только текстовый!). Так что SmallTalk со своим убогим синтаксисом, ну никак не подходит.
А customer-ам это нужно ? Наврядли, а стоимость производства и, как следствие, продукта, сие значительно увеличит.
Да и не реализуемо это на приемлемо уровне.
Парсер для Basic-а — это одно, а для С++ — совершенно иное, т.к. сложности их несопоставимы.
Здравствуйте, Аноним, Вы писали: L>>* как можно более компактное (компактнее чем в тексте) и легко-понимаемое представление для человека, но при этом как можно более гибкое и мощное. Кстати, в UML наоборот, более громоздкое описание, по сравнению с текстом.
А>Есть текстовое представление для UML2. Есть даже тулы поддерживающие его : Telelogic Tau/Developer. Синтаксис похож на С++.
L>>* ввод как графической (формы и объекты) так и текстовой информации. Изменения должны сразу отражаться в остальных. L>>Ещё лучше: наличие множества (эквивалентных) представлений метаобъектов, в том числе — одно или несколько для пользователя (т.е. для конечного продукта).
А>Telelogic Tau/Developer. Уже есть и работает.
Платное всё. И вообще продукт чисто коммерческий и на широкую публику не выйдет.
А>Эээ. Без фиксированого синтаксиса не сделаешь парсер.
Это почему?
Изменяемый синтаксис/семантику можно рассматривать как матрёшку. Есть какой-то базовый синтаксис и семантика, так сказать version 1.0. На него всегда можно вернуться. Остальные версии основываются на первой.
L>>Цель: Каждый объект может изменять любой другой объект (любого мета-уровня!) или его связи. Как следствие — программа, ведущая себя как самомодифицирующаяся. После компиляции она может стать обычной статической, хотя умный компилятор должен уметь при необходимости делать и модифицирующуюся.
А>Не нужно. Много затрат на поддержку. А если вы генерите код для встраиваемой системы ? А>Там серьезные требования на оптимизацию и надежность. Самомодифицируемый код — ненадежн.
Я же сказал — "ведущая себя", с точки зрения семантики. На самом деле скомпилированная программа может быть самой обыкновенной, причём это даже желательно.
А>Найдите хоть одну задачу, когда это нужно ?
А зачем задачу?
Задача — это когда знаешь что тебе нужно. Как говорится "мы не знаем того, чего мы не знаем".
Здравствуйте, Аноним, Вы писали:
L>>Ни в коем случае. У меня основное требование: изменяемый синтаксис (и не только текстовый!). Так что SmallTalk со своим убогим синтаксисом, ну никак не подходит.
А>А customer-ам это нужно ? Наврядли, а стоимость производства и, как следствие, продукта, сие значительно увеличит.
Лично для меня изменяемый синтаксис — это в первую очередь подстройка под конкретного человека. Т.к. всё равно объектное представление (вот оно-то может и будет фиксированным) можно переделать хоть в Бейсик, то проблем с чтением чужих исходников не должно быть.
Кстати, для того чтобы кастомерам что-то стало нужно, для начала они должны знать, что подобное принципиально возможно, и если возможно, то чем оно может быть лучше. Попробуй почитать старую фантастику: в большинстве произведений сегодняшний мир представляется совершенно по-другому.
Сейчас вон квантовые компы изучают, и совершенно неизвестно что из этого получится (при таких-то потенциальных возможностях).
А>Да и не реализуемо это на приемлемо уровне.
Как говорится: "поживём — увидим". Я всё же надеюсь на лучшее.
L>>* Возможность вырождения в императивные, логические или чисто функциональные языки, путём ввода ограничений. L>> Императивный = "как делать" L>> Логический = "что нужно получить" L>> Функциональный = "что делать" L>> Чисто функциональный = функциональный, но вход-выход без сохранения состояния, т.е. созданные объекты неизменяемы.
ГВ>В принципе, такая задача решаема, при выборе подходящего базиса, вопрос только в целесообразности её решения. Может быть, лучше сразу ассемблер генерировать и не кувыркаться?
В данном случае, конечно, интереснее следующая идея: мы сначала пишем "что надо получить" (набор лог. ограничений, можно даже попробовать просто тесты и т.д.). Далее "компилятор" пытается решить задачу, если у него не получается, то мы ему помогаем, подсказывая какие-то эквивалентные замены; строя какие-то высокоуровневые абстракции (функции, объекты и т.д.)
L>>* ! Редукция алгоритмов! Пример: primes = filter prime [1..] редукция в решето Эратосфена (т.е. исключение произведений простых чисел из натурального ряда, остаток — искомый ряд), т.к. проверять на делимость числа на все числа подряд — ненужная операция, достаточно проверки на делимость на простые числа меньше квадратного корня из исследуемого. Для такой редукции нужна полная развёртка операции остатка от деления (в атомарные операции).
ГВ>Угу, но прикинь себе нагруженность базовой системы базовыми же математическими аксиомами. А методы поиска по ним? Нет, в принципе можно перебирать всё-всё-всё в поисках наиболее подходящего, но критерии завершённости... с этим проблема...
Но это же можно делать в полуавтоматическом режиме. Простые вещи "компилятор" рюхает сам, а про сложные мы ему говорим, что в данном случае можно "схитрить", т.е. говорим, что замыкание n функций — означает нечто большее, чем просто последовательное выполнение. например, замыкание sort(x)[0] эквивалентно max(x).
Т.е. получается так: мы сначала пищем решение в "общем" виде, далее проводим оптимизацию: говорим, что некоторые места эквивалентны другим — более простым или просто требующих другой набор ресурсов (память, время и т.д.)
Не понятно что же ты все таки хочешь? Что конкретно будут описывать эти хитрые метаданные, какую область?
Если описываться будет сам код — давайте подумаем для чего?
Зачем в .Net появились метаданные? — Чтобы сблизить язык программирования с платформой. В результате мы получили новые средства позволяющие абстрагироваться от конкретных api и действовать в терминах обьектной платформы (уже совсем другой уровень).
К чему мы стремимся придумывая свой мета язык — к расширению имеющегося (например C++), потому что на нем сложно и не удобно работать с сущностями какой-то КОНКРЕТНОЙ предметной области. Потому что наш код, связи и иерархии избыточны, мы хотим их сократить...
Вот пример: в текущей реализации C++ меня совершенно не устаевает механизм обрабоки исключений (если система большая, явно видно что код избыточен, и путей его сокращения в рамках C++ — не наблюдается).
Так что, как вариант, хорошо бы было собрать список вот таких конкретных вещей и попробовать найти способ их решения...
Здравствуйте, joker6413, Вы писали:
J>Не понятно что же ты все таки хочешь? Что конкретно будут описывать эти хитрые метаданные, какую область?
В идеале? Любую!
Сейчас сижу над системой произвольного моделирования. Предпологаемое применение: от записной книжки типа the Brain, до моделирования больших программных проектов с последующей компиляцией в C/C++.
Здравствуйте, limax, Вы писали:
L>Здравствуйте, joker6413, Вы писали:
J>>Не понятно что же ты все таки хочешь? Что конкретно будут описывать эти хитрые метаданные, какую область?
L>В идеале? Любую!
L>Сейчас сижу над системой произвольного моделирования. Предпологаемое применение: от записной книжки типа the Brain, до моделирования больших программных проектов с последующей компиляцией в C/C++.
Интересная дискуссия
Рассуждаем:
Наша система должна позволять моделировать любую область.
Отсюда следует что либо она должна включать в себя описания всех абстракций всех областей, или она должна быть метасистемой (надсистемой) всех областей, и тогда из нее мы сможем вывести описание любой области.
Парадокс: раз наша система является метасистемой всех областей — значит она является своей собственной метасистемой и находиться за границами самой себя.
Интересная получилась штука, напоминает попытки математиков получить полную теорию чисел, но Гедель же ясно дал понять что это не возможно.
Конечно было бы очень заманчиво выделить нечто — "общность" (набор абстракций), что позволяло бы путем конкретизирования получать программные системы в любой области (аналогия — сверху вниз, от общего к частному). Но наблюдения подсказывают, что подобные попытки обречены... Работающие методологии к которым IT пришли за последние несколько десятилетий — строят процесс разработки как раз наоборот (сниву вверх, от частного к общему). Единственное утешение — выработаны некоторые типичные способы решения задач, например архитектуры и шаблоны....
Здравствуйте, joker6413, Вы писали:
J>Интересная дискуссия J>Рассуждаем: J>Наша система должна позволять моделировать любую область. J>Отсюда следует что либо она должна включать в себя описания всех абстракций всех областей, или она должна быть метасистемой (надсистемой) всех областей, и тогда из нее мы сможем вывести описание любой области. J>Парадокс: раз наша система является метасистемой всех областей — значит она является своей собственной метасистемой и находиться за границами самой себя.
Никакого парадокса нет. Рабочая версия метасистемы может быть написана на (а точнее смоделирована в) самой метасистеме. Это часто применяется при написании языков программирования.
Более того, на той же системе может быть построена система ещё более мощная. Тебя ведь не шокирует, что все программы в итоге написаны в машинном коде?
А кажущийся парадокс возникает из неправильного представления метасистемы. Для её построения не нужно чего-то всеобъемлющего. Это всё равно что построить математическую бесконечность. Но тем не менее бесконечность повсеместно используется в математике и это никого не удивляет.
J>Интересная получилась штука, напоминает попытки математиков получить полную теорию чисел, но Гедель же ясно дал понять что это не возможно.
Но это не значит, что к этому не нужно стремиться. Не дойдём до полной теории, так хоть до частной.
В универе у меня был такой предмет — "Теоритическая информатика". Так вот, меня жутко возмутила одна теорема. Точную формулировку не помню, но смысл таков: невозможно построить программу, которая за конечное время определяла бы, даст любая другая программа результат за конечное время или нет. Действительно, это оказалось именно так, эта теорема легко доказывается. После этого хочется плюнуть на вопрос о решаемости задачи и сложить руки.
На самом деле это совсем не значит, что нельзя построить программу, которая работала бы для некоторых (а то и для большинства) входных данных.
Здравствуйте, limax, Вы писали:
L>Здравствуйте, joker6413, Вы писали:
L>Никакого парадокса нет. Рабочая версия метасистемы может быть написана на (а точнее смоделирована в) самой метасистеме. Это часто применяется при написании языков программирования.
Не путай понятия... О системе и метасистем см. ниже.
L>Более того, на той же системе может быть построена система ещё более мощная. Тебя ведь не шокирует, что все программы в итоге написаны в машинном коде?
Ни сколько, так как все программы — суть описание алгоритмов, это граница системы и ни одна программа за эту границу не вышла. Изменения касались только уровней "абстрагирования" от машинного кода. Заметь эти изменния пришли из вне, их внесла метасистема — человеческий разум.
L>А кажущийся парадокс возникает из неправильного представления метасистемы. Для её построения не нужно чего-то всеобъемлющего. Это всё равно что построить математическую бесконечность. Но тем не менее бесконечность повсеместно используется в математике и это никого не удивляет.
Метасистема определяет правила конкретной системы... Это разные вещи, т.к. система не определяет правил метасистемы даже если некоторые из этих правил могут совпадать. Но все конечно зависит от уровня "широты" системы и необходимой "непротиворечивости"...
J>>Интересная получилась штука, напоминает попытки математиков получить полную теорию чисел, но Гедель же ясно дал понять что это не возможно.
L>Но это не значит, что к этому не нужно стремиться. Не дойдём до полной теории, так хоть до частной.
Это принципиальная позиция, так как здесь мы решаем каким путем пойдем... будем пытаться придумывать новую "объемлющцю теорию", или работать над следующим уровенем "абстрагирования от кода"...
L>В универе у меня был такой предмет — "Теоритическая информатика". Так вот, меня жутко возмутила одна теорема. Точную формулировку не помню, но смысл таков: невозможно построить программу, которая за конечное время определяла бы, даст любая другая программа результат за конечное время или нет. Действительно, это оказалось именно так, эта теорема легко доказывается. После этого хочется плюнуть на вопрос о решаемости задачи и сложить руки.
Вобщем да, паршиво когда онимают надежду ничего не давая взамен...
L>На самом деле это совсем не значит, что нельзя построить программу, которая работала бы для некоторых (а то и для большинства) входных данных.
Конечно не значит — и лучший пример — программа печати .
J>Парадокс: раз наша система является метасистемой всех областей — значит она является своей собственной метасистемой и находиться за границами самой себя.
J>Интересная получилась штука, напоминает попытки математиков получить полную теорию чисел, но Гедель же ясно дал понять что это не возможно.
Дермаген!
(живот по немецки)
Вот не люблю я, когда на эту теорему сбрасывают все грехи. Ничего такого она не "даёт понять".
А по-поводу метасистемы. Ну, всем известно, что компиляторы сейчас пишутся зачастую на том же языке, который и компилируют. Уж не знаю, парадокс или нет, но противоречия тут точно нет. Метасистема может своей собственной метасистемой.
J> Но наблюдения подсказывают, что подобные попытки обречены...
Вот здесь я соглашусь. Слишком денег много на всё это нужно. Так и останется прожектом
L>В универе у меня был такой предмет — "Теоритическая информатика". Так вот, меня жутко возмутила одна теорема. Точную формулировку не помню, но смысл таков: невозможно построить программу, которая за конечное время определяла бы, даст любая другая программа результат за конечное время или нет. Действительно, это оказалось именно так, эта теорема легко доказывается.
Мне кажется, такое доказательство можно легко построить на контрпримере. Что-нибудь с датчиком случайных чисел.
Например, пусть вероятность завершения программы резко падает с каждым следующим тактом. Нужно так подобрать зависимость, чтобы суммарная вероятность конечного завершения была меньше единицы. Получается, проверить "конечность" такой программы можно только методом тыка, а метод тыка тут может затянуться на бесконечность.
Мы слишком мало знаем (а точнее хотим знать).
Дальше объяснять?
