Обсуждение

>> шесть типов "мета" при таком делении отношение "чертеж"<->"деталь, изготовленная по чертежу" относится к какому варианту? №3 и/или №4?

а я бы выбрал "и 1 и 4"

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

можно привести и менее "атомный" пример. имеется ли хоть один элемент, который было бы возможно назвать "моделью", к примеру, в такой цепочке: "замысел программы в голове программиста" <--> "исходный код программы" <--> "скомилированный объектный код программы" <--> "процесс операционной системы, исполняющий объектный код программы" ? если "нельзя", не получается ли так, что отличительной чертой подобных "моделей" является "неприменимость ее в реальной жизни"? не нравится мне такой вывод. цель моделирования - извлечение пользы. польза не может быть "метафорической", а должна в чем-то как-то исчисляться...

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

У меня в черновиках аккурат висит текст (первая часть) об интеграции системы типов (для данных) и прототипных описаний (как для типов, так и для сущностей реального мира) в рамках бинарного контейнера/протокола. Основа - разделение на "X is Y", которое интерпретируется как "X соответствует требованиям для Y" (и может быть определено экстенсионально или интенсионально), и прототипное "X is based on Y", которое означает лишь "при описании X каким-то (любым) образом использовалось описание Y". Вчера стало ясно, что для понятности сначала придётся набросать "нулевую" часть, с описанием основ системы типов вне специфики их кодирования, а также отображением существующих случайных/народных "мета" в этом базисе.

"чертеж" трудновато ложится на "абстрактный синтаксис" вот ГОСТ- 2.306-68 по отношению к чертежу - это да ...

Я боюсь, что перечисленные у товарищей из MOF варианты "меты" не являются случайными/народными, и в этой "нулевой части" нужно их поимённо разобрать. Рекомендую также поглядеть особо на презентацию Конрада Бока на коллоквиуме по MBSE (вот так он учит инженеров про "соответствие дизайну", "соответствие требованиям" и т.д.: http://www.isr.umd.edu/events/m-bsec_PPTs/111128_Bock.pdf) и попробовать упомянуть этот же аспект -- продвижение модели по жизненному циклу изделения.

для простой модели "r^3 = const > 0" и то приходится вводить погрешности, чтобы она не была метафорической :)

Вообще-то говоря, идея моделирования исходного кода программы для товарищей из тусовки MDA (это которые про MOF/UML) как раз и является главной. Они подробненько разбирают, что может быть моделью кода программы, что может быть метамоделью этой модели кода, и так далее. И демонстрируют множество применений. Все тексты по ссылкам именно про это. Вы же пытаетесь сформулировать приключения текста программы безо всяких моделей (намеренно их избегая), это как раз то, с чем борются представители всего этого model-based и model-driven движения. Конечно, можно замыслить программу, запрограммировать её, откомпилировать и т.д. -- и какой в этом подвиг, какую вы задачу решаете, почему у вас это должно быть лучше, чем с использованием моделей? Ровно на эти темы и рассуждают люди, занимающиеся разными "мета" -- они рассказывают, что с метамоделированием лучше заниматься моделированием, а с моделированием лучше заниматься программированием. Вы таки почитайте тамошние материалы.

за ссылки в любом случае спасибо. >> Они подробненько разбирают, что может быть моделью кода программы >> что может быть метамоделью этой модели кода ...моделью кода объектно-ориентированной программы под тем углом зрения, под которым они предпочитают видеть 1)объект, 2) ООП и 3) достаточный уровень приближения модели. и ограничиться этим видением я совершенно не готов. не устраивает нотация UML. не думают мозги на всю катушку под при ее использовании. в той же книжке "Model Driven..." OWL как раз поминается. и тут же расписывается как маппить его в UML... тьфу. >> Вы же пытаетесь сформулировать приключения текста программы безо всяких моделей я бы сильно предпочел, чтобы "текст программы" и был "моделью". или по крайней мере был бы ей максимально гомеоморфен. >>почему у вас это должно быть лучше, чем с использованием моделей? их моделей... лучше приближение. меньше издержки. ( "лучший прибор - который отсутствует, но при том функции его исполняются". а "лучшая гидравлика - та, которая НИКОГДА НИКОГДА НИКОГДА НЕ СТОИТ на самолете" (с)товарищ Туполев ).

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

отличный пост, спасибо! 2. Группирование (тип-подтип), оно же категории ... 5. Основа-вариант (основная модель -- кастомизированная) а разве основная модель/кастомизированная - это не то же самое, что тип/подтип? не могу понять разницы.

Вот про все эти тонкие разницы и статьи :-)

Оказывается есть языки программирования которые поддерживают программирование на неограниченном кол-ве уровней (мета-, мета-мета- и проч), типа http://en.wikipedia.org/wiki/%CE%A9mega Как страшно жить

касательно программирования на мета-уровнях, я некоторое время назад пришел к выводу, что это сколько-нить разумно это делать только на реврайтовых языках типа Pure (Maude OBJ специализированные для графов реврайтовые языки) и то скорее всего сам Pure не очень, но очень интересна комбинация мета-, реврайтинга и динамических типов - статические типы на мета-уровнях конечно возможны, но это сплошной взорви-моск, в силу принципиальных ограничений на вывод типов

Да, там много-много статей на эту тему и ссылок на похожие языки "многометовости" в серединке страницы тут: http://web.cecs.pdx.edu/~sheard/

Опять же, программирование, онтологизирование и моделирование суть одно. Вот на MOF определено 9 возможных уровней метамоделирования, плюс попытки задать операционную семантику на этом. И никакого реврайтинга. Зачем нужны все эти меты показывает Конрад Бок в своей презентации: http://www.isr.umd.edu/events/m-bsec_PPTs/111128_Bock.pdf -- это как раз наш разговор на тему "на каком уровне меты появляются слова не про реализацию, а про предметную область". У Конрада Бока эти слова появляются главным образом на пути специализации/генерализации, но у метамодельеров обычно эти слова появляются практически по любой линии мет. Так что это было бы неплохим упражнением для прозрачного персистанса указать на его мета-уровень по отношению к уровню, когда появляются понятия предметной области вверху, и уровню виртуальной машины внизу. Ну, и более чётко прописать мета "выражение -- абстрактный синтаксис", ибо задача-то ставится в абстрактном синтаксисе, а потом только отражается в одном из многочисленных выбранных языков. Кстати, Алан Кей так же со своими "языками" обходится. У него каждый язык это "идея, как можно рассуждать о программах", а потом идут различные реализации на самых разных языках (ОМета была реализована чуть ли не на десятке языков -- просто как набор идей). Так и "прозрачный персистанс" может быть сформулирован абстрактно (на мета-уровне) один раз, а реализован множество раз. Ну, и пользовательские представления затем могли бы быть реализованы много раз, из них один раз -- с использованием прозрачного персистанса и всеми положительными плюшками от этого. Если так рассказывать, всё становится понятней.

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

А можно к каждому варианту мета конкретный пример? пс: я тоже по вашей наводке искал этот список, но не нашел раньше