модели, модели моделей, языки моделирования
типа размышление вслух, кидал быстро свой поток сознания
ну да, ну да... )) Левенчук тут, вот читает таки меня, ой читает )... хотя и не дискутирует со мной, потому как птица высокого полета ) но мне и не требуются его комментарии )
++++++++++++++++++
===========Левенчук:========
Это я всё продолжаю не столько бежать к цели (SysMoLan), сколько медленно ползти к ней, или даже просто лежать к ней. Ибо по линии развития онтологических языков мы уже ходили, по линии архитектурных языков ходили, а вот по линии языков моделирования данных -- пока нет. Нам же нужно описывать систему, пробегая по всей цепочке от реального мира через концепты к представлению этой системы в каких-то данных. С этим нужно ещё как-то подробней разобраться, с этой идеей "одного языка, на котором можно отследить связи разных уровней моделирования" -- как в случае Архимейта с его уровнями организации/концептов-софта/данных-железа/носителей.
https://ailev.livejournal.com/1451630.html
==========
вот, пробует заход делать на моделирование данных, я тут ранее с неделю назад как раз писал у себя, что
---
ну коль можно модели систем писать на сисмоланге, то и модель сисмоланга можно написать на нем же )
следует определиться с понятием модели и формализовать понятие модель!
тогда станет ясно, что требуется для языка на котором всё желаете замоделировать
Язык моделирования 2018-10-20 23:07:00
https://deep-econom.livejournal.com/263454.html
---
и до этого еще ранее, говорил у него в блоге, что не получится никак иначе, чем через модели, дозрел видимо, но думаю только потому, что иное не получается
а почему не получается? а потому как теоретически не готовы они! не смотря на всю эрудицию и начитанность
поскольку требуется именно понимание проблемы правильное
нужен иной подход, а подход не прочитаешь в книжках, его надо создавать, вот и тыкаются они как "онтологические котята" )) ну да, должен пройти долгий путь осмысления и переработки информации
***Левенчук: а вот по линии языков моделирования данных -- пока нет
не данные надо моделировать, а мир надо моделировать ) мышление надо моделировать
+++++++++++++++
"Еще один из интересных способов борьбы с complexity - создание собственного DSL, по сути моделирование в DDD терминах - шаг после осознания пункта выше." /ссыль1 внизу/
DSL = https://ru.wikipedia.org/wiki/Предметно-ориентированный_язык
DDD= https://ru.wikipedia.org/wiki/Проблемно-ориентированное_проектирование
компилирую )
способ борьбы со сложностью - создание собственного языка предметной области, что по сути является моделированием в терминах предметно-ориентированного проектирования
цель: мы желаем всё моделировать
предметная область=весь мир
каковы должны быть термины предметно-ориентированного проектирования нашей предметной области "весь мир"?
человек может моделировать весь мир, для этого у него есть куча языков, от ассемблера и машины Тьюринга (МТ) до языков программирования, до языков разных профессий (профессионального слэнга и терминов) и до естественного языка включительно.
а каков конкретно должен быть язык?
почти все компьютерные языки Тьюринг-полны, тьюринг-эквивалентны т.е. без разницы какой язык брать за основу, хоть бери машину тьюринга (МТ), без разницы
по сути языки это синтаксический сахар над МТ + библиотеки интерпретирующие этот синтаксический сахар
=======
ну типа придумали вектора и сложение векторов, нам надо организовать процедуру представление/хранение данных и процедуру интерпретации сложения
придумали очередной типа данных и операции над ним, нам опять надо знать как мы его храним/представляем и набор операций с ним
нужен метасистемный/надсистемный переход
вопрос, что тогда требуется, чтобы такой язык стал полезен?
какова универсальная структура данных, такая что из нее легко лепить все (любой синтаксический сахар)
и чтобы можно было легко лепить/строгать процедуры
т.е. нам надо хороший инструментарий для моделирования объектов и процессов
универсальное моделирование требует и универсального понятия модели
модель всегда совмещает описание объекта и процесса (допускаем, что объект или процесс могут отсутствовать, вырожденные модели, это нормально)
но мы хорошо понимаем, что разные предметные области знаний требуют своей специальной терминологии и свои специальные процессы, только тогда в этих терминах все будет удобно и понятно и наглядно и просто описываться
универсализация влечет неэффективность, эффективность влечет отсутствие универсализации
обычная проблема, нельзя все и сразу, нельзя быть эффективным во всем, за эффективность платим отсутствием универсализации, за универсализацию платим отсутствием эффективности
т.е. универсального эффективного одного языка офигительного на все случаи жизни нет и похоже не будет
поэтому все языки нужны и все языки важны
универсальный система, универсальный интерпретатор, интерпретатор интерпретаторов, видимо не может быть чисто механическим, это будет сильный ИИ, он будет плодить языки по мере необходимости, он будет изучать чужие языки по мере надобности, он будет клепать специализированные интерпретаторы по необходимости и т.п.
соответственно основой универсального языка нужна структура данных модель и соответствующие операции с моделями, когда этот интерпретатор моделей станет достаточно сложным и универсальным, то он превратится в сильный ИИ
неважно на каком языке будет интепретатор интерпретаторов, хоть на языке машины Тьюринга, хоть на ассемблере, на любом
факт в том, что нам нужны модели и манипуляции с моделями, типа нужен универсальный язык работы с моделями, но это будет в любом случае низкоуровневый язык, я у себя в блоге давал формальное определение универсальной модели типа это упорядоченная пара состоящая из упорядоченных пар
((*,*),(*,*))
это начальный уровень языка, это такой модельный ассемблер, примитивная "модельная машина", у которой примитивы модели и операции над моделями (какие конкретно операции надо думать)
в природе базовая операция над моделями это ассоциация
мы не обязаны вслепую следовать за природой, но ассоциация естественно там будет, как одна из примитивных универсальных операция
=========
над примитивным языком моделей надо будет надстраивать модельный синтаксический сахар, надо создавать библиотеки работы со сложными моделями, со сложным синтаксическим сахаром
должна быть иерархия слоев модельного синтаксического сахара
предыдущий слой интерпретирует верхний слой, создали текущий слой моделирования, переходим к следующему и т.д.
я это все както так вижу ))
ps
============
Выношу из комментов - complexity
Комментирую http://gaperton.livejournal.com/66415.html
Есть еще несколько способов:
моделирование изменений или проектов - это была цель UML и прочих инструментов системной инженерии.
В подкасте iTunes U от Carnegie Mellon University Software Engineering Institute, есть несколько интересных обсуждений на тему software complexity, включая mission critical systems. В одном из таких обсуждений приводится ссылка на одно из исследований в котором рассматривали complexity как "меру когда разработчик не может удержать систему или изменение в голове" и поэтому появляется необходимость (или осознание необходимости) моделировать систему. Однако тоже исследование указывает что к тому моменту система уже становится messy и моделировать становится слишком поздно.
ИМХО менеджерское решение - надо моделировать заранее, начиная с мелких шагов и включать стандарт моделирования, общий для разработчиков + dev ops и бизнеса.
Еще один из интересных способов борьбы с complexity - создание собственного DSL, по сути моделирование в DDD терминах - шаг после осознания пункта выше.
https://alexander-mikh.livejournal.com/255399.html
======
ну да, ну да... )) Левенчук тут, вот читает таки меня, ой читает )... хотя и не дискутирует со мной, потому как птица высокого полета ) но мне и не требуются его комментарии )
++++++++++++++++++
===========Левенчук:========
Это я всё продолжаю не столько бежать к цели (SysMoLan), сколько медленно ползти к ней, или даже просто лежать к ней. Ибо по линии развития онтологических языков мы уже ходили, по линии архитектурных языков ходили, а вот по линии языков моделирования данных -- пока нет. Нам же нужно описывать систему, пробегая по всей цепочке от реального мира через концепты к представлению этой системы в каких-то данных. С этим нужно ещё как-то подробней разобраться, с этой идеей "одного языка, на котором можно отследить связи разных уровней моделирования" -- как в случае Архимейта с его уровнями организации/концептов-софта/данных-железа/носителей.
https://ailev.livejournal.com/1451630.html
==========
вот, пробует заход делать на моделирование данных, я тут ранее с неделю назад как раз писал у себя, что
---
ну коль можно модели систем писать на сисмоланге, то и модель сисмоланга можно написать на нем же )
следует определиться с понятием модели и формализовать понятие модель!
тогда станет ясно, что требуется для языка на котором всё желаете замоделировать
Язык моделирования 2018-10-20 23:07:00
https://deep-econom.livejournal.com/263454.html
---
и до этого еще ранее, говорил у него в блоге, что не получится никак иначе, чем через модели, дозрел видимо, но думаю только потому, что иное не получается
а почему не получается? а потому как теоретически не готовы они! не смотря на всю эрудицию и начитанность
поскольку требуется именно понимание проблемы правильное
нужен иной подход, а подход не прочитаешь в книжках, его надо создавать, вот и тыкаются они как "онтологические котята" )) ну да, должен пройти долгий путь осмысления и переработки информации
***Левенчук: а вот по линии языков моделирования данных -- пока нет
не данные надо моделировать, а мир надо моделировать ) мышление надо моделировать
+++++++++++++++
"Еще один из интересных способов борьбы с complexity - создание собственного DSL, по сути моделирование в DDD терминах - шаг после осознания пункта выше." /ссыль1 внизу/
DSL = https://ru.wikipedia.org/wiki/Предметно-ориентированный_язык
DDD= https://ru.wikipedia.org/wiki/Проблемно-ориентированное_проектирование
компилирую )
способ борьбы со сложностью - создание собственного языка предметной области, что по сути является моделированием в терминах предметно-ориентированного проектирования
цель: мы желаем всё моделировать
предметная область=весь мир
каковы должны быть термины предметно-ориентированного проектирования нашей предметной области "весь мир"?
человек может моделировать весь мир, для этого у него есть куча языков, от ассемблера и машины Тьюринга (МТ) до языков программирования, до языков разных профессий (профессионального слэнга и терминов) и до естественного языка включительно.
а каков конкретно должен быть язык?
почти все компьютерные языки Тьюринг-полны, тьюринг-эквивалентны т.е. без разницы какой язык брать за основу, хоть бери машину тьюринга (МТ), без разницы
по сути языки это синтаксический сахар над МТ + библиотеки интерпретирующие этот синтаксический сахар
=======
ну типа придумали вектора и сложение векторов, нам надо организовать процедуру представление/хранение данных и процедуру интерпретации сложения
придумали очередной типа данных и операции над ним, нам опять надо знать как мы его храним/представляем и набор операций с ним
нужен метасистемный/надсистемный переход
вопрос, что тогда требуется, чтобы такой язык стал полезен?
какова универсальная структура данных, такая что из нее легко лепить все (любой синтаксический сахар)
и чтобы можно было легко лепить/строгать процедуры
т.е. нам надо хороший инструментарий для моделирования объектов и процессов
универсальное моделирование требует и универсального понятия модели
модель всегда совмещает описание объекта и процесса (допускаем, что объект или процесс могут отсутствовать, вырожденные модели, это нормально)
но мы хорошо понимаем, что разные предметные области знаний требуют своей специальной терминологии и свои специальные процессы, только тогда в этих терминах все будет удобно и понятно и наглядно и просто описываться
универсализация влечет неэффективность, эффективность влечет отсутствие универсализации
обычная проблема, нельзя все и сразу, нельзя быть эффективным во всем, за эффективность платим отсутствием универсализации, за универсализацию платим отсутствием эффективности
т.е. универсального эффективного одного языка офигительного на все случаи жизни нет и похоже не будет
поэтому все языки нужны и все языки важны
универсальный система, универсальный интерпретатор, интерпретатор интерпретаторов, видимо не может быть чисто механическим, это будет сильный ИИ, он будет плодить языки по мере необходимости, он будет изучать чужие языки по мере надобности, он будет клепать специализированные интерпретаторы по необходимости и т.п.
соответственно основой универсального языка нужна структура данных модель и соответствующие операции с моделями, когда этот интерпретатор моделей станет достаточно сложным и универсальным, то он превратится в сильный ИИ
неважно на каком языке будет интепретатор интерпретаторов, хоть на языке машины Тьюринга, хоть на ассемблере, на любом
факт в том, что нам нужны модели и манипуляции с моделями, типа нужен универсальный язык работы с моделями, но это будет в любом случае низкоуровневый язык, я у себя в блоге давал формальное определение универсальной модели типа это упорядоченная пара состоящая из упорядоченных пар
((*,*),(*,*))
это начальный уровень языка, это такой модельный ассемблер, примитивная "модельная машина", у которой примитивы модели и операции над моделями (какие конкретно операции надо думать)
в природе базовая операция над моделями это ассоциация
мы не обязаны вслепую следовать за природой, но ассоциация естественно там будет, как одна из примитивных универсальных операция
=========
над примитивным языком моделей надо будет надстраивать модельный синтаксический сахар, надо создавать библиотеки работы со сложными моделями, со сложным синтаксическим сахаром
должна быть иерархия слоев модельного синтаксического сахара
предыдущий слой интерпретирует верхний слой, создали текущий слой моделирования, переходим к следующему и т.д.
я это все както так вижу ))
ps
============
Выношу из комментов - complexity
Комментирую http://gaperton.livejournal.com/66415.html
Есть еще несколько способов:
моделирование изменений или проектов - это была цель UML и прочих инструментов системной инженерии.
В подкасте iTunes U от Carnegie Mellon University Software Engineering Institute, есть несколько интересных обсуждений на тему software complexity, включая mission critical systems. В одном из таких обсуждений приводится ссылка на одно из исследований в котором рассматривали complexity как "меру когда разработчик не может удержать систему или изменение в голове" и поэтому появляется необходимость (или осознание необходимости) моделировать систему. Однако тоже исследование указывает что к тому моменту система уже становится messy и моделировать становится слишком поздно.
ИМХО менеджерское решение - надо моделировать заранее, начиная с мелких шагов и включать стандарт моделирования, общий для разработчиков + dev ops и бизнеса.
Еще один из интересных способов борьбы с complexity - создание собственного DSL, по сути моделирование в DDD терминах - шаг после осознания пункта выше.
https://alexander-mikh.livejournal.com/255399.html
======