SysMoLan как eDSL для Julia
В дискуссии о типах языков программирования/моделирования/представления знаний (там, кстати, уже 320 дискутантов -- https://t.me/typeslife) сегодня был очередной поворот: попытка вместо говорения об онтологии и представлении знаний (что сразу вызывает математических и философских духов) говорить о предметно-специфичности, продолжая программистскую традицию и попадая в программистский язык. Так что ответы на наши вопросы про языки моделирования разных предметных областей будем искать по ключевым словам "domain-specific".
Когда-то и Fortran называли domain-specific, ибо он только для formula translations, а не универсальный, как машинный язык. И то же самое было со всеми языками высокого уровня, они были domain-specific. Тем не менее, domain-specific пока чётче ведёт к цели, чеми использование всяких других слов. Нам нужно делать еmbedded domain-specific languages (eDSL) с domain-specific types (как онтикой предметной области) и domain-specific solvers (для того, чтобы интерпретировать модели в онтике/типах предметной области, задавать вопросы/делать запросы/вычислять).
В группе "Аттик" мехмата МГУ рассказывали, что нашли причину, почему Паскаль никак не мог победить Фортран в своё время. Они считали, что Паскаль был безблагодатен по сравнению с пакетными языками (Modula, Ada), ибо не было "пакетов" как раз для реализации общей для нескольких программистов системы типов - нельзя было делать "пакеты" как eDSL для domain-specific работы (те самые domain-specific types и domain-specific solvers, в терминах группы Аттик domains -- это были миры и solvers -- исполнители для этих миров). В Фортране же это реализовалось на раз-два через common-блоки! Потом какие-то аналоги common blocks начали делать в паскаль-компиляторах (но это уже потом! в учебниках паскаля это не было свойством языка, а только свойством реализации в конкретном компиляторе). Потом появились на краткий исторический миг пакетные языки, а потом domain specificity начали понятными словами объяснять как делать в ООП и в реляционных моделях данных - тут все эти "пакетные языки" и деревянные с сетевыми базы данных начала восьмидесятых и смыло в унитаз истории, где они и находятся до сих пор.
Вся дискуссия в чате крутилась вокруг того, что удобных для программирования eDSL языков программирования/моделирования/запросов к базам данных/представления знаний нет. Так что я продолжаю придерживаться мнения, которое выработалось у меня на прошлом такте дискусии (https://ailev.livejournal.com/1487293.html): работать тогда будем с Julia как хост-языком. И на Julia будем реализовывать структуры данных и солверы SysMoLan как eDSL.
Вчера на докладе на митапе по Julia (https://juliameetup.timepad.ru/event/1047482/, слайды https://yadi.sk/i/yBeUJJj1iuiJXQ, видео https://vimeo.com/360541672#t=4940s) я высказал ещё пару идей. Солверы для eDSL отличаются тем, что эффективно обрабатывают частные случаи -- предоставляют оптимизированные для этих частных случаев решения. И в Julia как раз отрабатывается такой подход на примерах методов оптимизации (JuMP) и методов решения систем дифференциальных уравнений (DifferentialEquations). Солверы этих систем -- это просто коллекция самых разных солверов, эффективных для самых разных ситуаций. Итого eDSL выглядит как набор типов, в терминах которых удобно описывать предметную область, плюс набор эффективных солверов -- типы должны универсально отражать задачи предметной области, а солвер должен устойчиво работать и жужжать в части скорости. Поэтому типы должны быть более-менее богаты в части их конструирования для отражения объектов и отношений в domain (сравнимы в этом плане с богатыми типами статических языков программирования), но динамическими, чтобы по ходу дела в runtime подбирать оптимизацию для solver. Ну, и проблема двух языков: на одном и том же языке и компактно и красиво (с рафинадом) высокоуровнево выражать domain, но не теряя низкоуровневости в скорости. И настолько не теряя низкоуровневости, чтобы эта оптимизация докатывалась аж до уровня железа -- до GPU. Вот Julia как раз имеет примеры таких решений. Вот этим путём и хочется пойти для SysMoLan: иметь возможность самых разных солверов для предлагаемых SysMoLan как eDSL структур данных.
Идти туда, как мне кажется, нужно в несколько шагов:
1. Сделать простой (архитектурный и требований) текстовый моделер для простых архитектур и использовать его, например, для обучения инженерии требований и инженерии системной архитектуры. У меня проходит в год сотня студентов и курсантов по разным линиям, вот это будет учебный софт. SysMoLan в объёме реализации IEC81346-1 для моделирования системного разбиения (чтобы можно было показать функциональное и конструктивное системное разбиение в их взаимосвязи на пару уровней) тут вполне подойдёт. Это MVP. Ничего вычислять даже не будем (может быть, будем проверять целостность, но и тут не факт), только отображать удобно. Солвер -- голова инженера. Для чего такое нужно? Для помощи со стороны компьютера в присмотре за вниманием в ходе архитектурной работы и работы над требованиями, речь идёт о киборгизация архитектора (вот тут про киборгизацию присмотра за вниманием: https://ailev.livejournal.com/1488271.html). Как над шахматными партиями удобней думать, если есть просто шахматная доска, на которую можно смотреть, так и архитектурный моделер помогает думать уже тем, что он помогает стабилизировать внимание архитектора.
2. Иметь полноценный текстовый язык представления знаний в качестве полноценного системного языка. Тут уж точно иметь eDSL, ибо к более-менее сложным архитектурным моделям и моделям требований захочется делать запросы.
В чате была дискуссия о том, что лучшим приближением к языкам представления знаний является common logic, и какой-нибудь FOL солвер. При этом SQL предлагался как успешный вариант языка для FOL -- без пояснения того, как это всё предполагается в работе у инженера. Ибо логические языки почему-то нигде не взлетели в их чистом логическом виде.
Тут ещё и социальные аспекты, конечно. Пара релевантных ссылок в Communications of ACM (http://cacm.acm.org/blogs/blog-cacm/173328-programming-languages-are-the-most-powerful-and-least-usable-and-learnable-user-interfaces/fulltext) -- там обсуждается вопрос, почему люди не хотят учить языки программирования (языки моделирования, языки мета-моделирования). Там вводят понятия cognitive load (http://en.wikipedia.org/wiki/Cognitive_load, связанные с использованием рабочей памяти умственные усилия), для разных людей они будут разные при изучении предмета. И далее говорится, что люди оценивают не реальную когнитивную нагрузку, а субъективно воспринимаемую (percieved) будущую нагрузку -- когда вы даже воспринимать её по факту не можете, ибо ещё не знакомы с предметом. Да, и полезность вы тоже представить не можете, ибо не знакомы с предметом. А решение "учить-не учить" принимается до изучения предмета. То есть бесполезно уговаривать что-то учить, потому как оно "полезно". Решение принимается не только и не столько по "пользе", сколько по "цене изучения" -- например, считает ли потенциальный ученик, что у него есть способности к предмету. Это всё expectancy value motivational theory -- https://www.researchgate.net/publication/265965932_Expectancy-Value-Cost_Model_of_Motivation. If students are not convinced they can learn it and they are not convinced of the value, then they don't learn it. Решение автор текста предлагает в повышении usability для изучаемых предметов (языков программирования/моделирования), но и learnability -- это разные свойства. Requirements нужно формулировать для обеих характеристик. Легко такую банальность предложить, трудно выполнить.
Вопрос мой в том, что современные информационные системы решают многие из тех задач, которые раньше считалось, что смогут решать только экспертные системы. И эти системы написаны на обычных языках программирования, а не на логических языках. Нет ли какого-то способа представления знаний, отличного от тупого использования логического языка? Логическая парадигма только одна из многих, и в языках программирования она явно не главная. Иначе мы бы видели вокруг сплошных потомков Пролога. Но нет, потомки Пролога везде маргинализуются, и никакая опенсорсовость им не помогает. CycL тоже делал OpenCyc, потом закрыл этот проект: не взлетело. Логическое не взлетает, на SQL делают только запросы в базу данных, а не программируют -- вот я и интересуюсь, что ещё на свете существует для представления знаний. Какая-нибудь Java для представлений знаний неудобна, но модели самых разных domain обрабатываются в мире главным образом на ней, а не на CycL или Agda. Получается, вся краса мира у нас уходит в язык программирования, который нужен для того, чтобы вызвать SQL над базой данных, в которых и отображён domain. При этом как domain отражается в реляционных базах данных - понятно, этому учат в университетах, и по большому счёту DDD (domain-driven design) тоже редко когда про язык программирования, чаще про базы данных.Ответа в чате я так и не получил, хотя обсуждение и было бурным. Так что за подробностями отправим в чат, а тут продолжим.
3. Иметь дифференцируемый язык представления знаний как eDSL, чтобы использовать этот язык не только для ручного ввода архитектурных моделей и моделей требований в рамках облегчения работы subject expert по knowledge aquisition, но и в рамках порождения/generation, а ещё в рамках оптимизации (про "дифференцируемое всё" я писал в https://ailev.livejournal.com/1464563.html). У Julia тут неплохая репутация: Viral Shah [один из разработчиков компилятора Julia] addressed the World Artificial Intelligence Conference, held in Shanghai Aug 29-31 with a discussion on "Julia: Generalizing Deep Learning with Differentiable Programming" (почему я и хотел бы держаться к Julia поближе, а не к C#, С++, R или каким-то другим языкам, не приспособленным для численных методов). Порождаемые архитектуры, оптимизируемые архитектуры, фронтир - вот это всё тут, все эксперименты с искусственным интеллектом и компьютерным творчеством.
4. А ещё нужно будет реализовать mapper (генератор конверторов/адаптеров/плагинов/мостов и т.д. -- систему типа .15926 https://github.com/TechInvestLab/dot15926/, только не обязательно на ISO15926, зато с удобным порождением парсеров и генераторов данных, eDSL для этого), ибо любой архитектурный редактор быстро будет нуждаться в частных моделях из разных САПР, и дело быстро дойдёт до полноценной PLM. Когда будет реализовываться мэппер, там результат будет вполне дискретный и формальный и FOL внутри, а вот методы получения моделей данных могут быть с использованием нейросетей, вероятностных языков и разных других численных алгоритмов. В итоге получится гибрид, а не только нейросети или только строгая логика. Вот, кстати, пример такого "загрузчика данных" (мэппера) для табличек: о "импорту табличек в программу", Flatfile can automatically match 95% of imported columns, using a combination of machine learning and fuzzy matching. Users can upload data via CSV, XLS, or simply paste from the clipboard - https://venturebeat.com/2019/09/10/flatfile-pursues-intelligent-data-importing-with-2-million-round/. JuliaDB при этом тоже работает с файлами табличек, в колонках которых могут быть любые типы Julia, а не только числа или строки, но всё-таки мэппер должен работать не только с табличными форматами. Первое, о чём спросят инженеры, так это о мэппинге 3D-моделей современных САПР.
Задача представления системных знаний на SysMoLan сложная, поэтому решаем её эволюционным путём, а не "сразу всё во взаимоувязке". Системный подход не должен становиться болезнью, когда вгоняет проект в analysis paralysis и заставляет "учесть всё-всё" в один подход и один проход.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216230511529525
Когда-то и Fortran называли domain-specific, ибо он только для formula translations, а не универсальный, как машинный язык. И то же самое было со всеми языками высокого уровня, они были domain-specific. Тем не менее, domain-specific пока чётче ведёт к цели, чеми использование всяких других слов. Нам нужно делать еmbedded domain-specific languages (eDSL) с domain-specific types (как онтикой предметной области) и domain-specific solvers (для того, чтобы интерпретировать модели в онтике/типах предметной области, задавать вопросы/делать запросы/вычислять).
В группе "Аттик" мехмата МГУ рассказывали, что нашли причину, почему Паскаль никак не мог победить Фортран в своё время. Они считали, что Паскаль был безблагодатен по сравнению с пакетными языками (Modula, Ada), ибо не было "пакетов" как раз для реализации общей для нескольких программистов системы типов - нельзя было делать "пакеты" как eDSL для domain-specific работы (те самые domain-specific types и domain-specific solvers, в терминах группы Аттик domains -- это были миры и solvers -- исполнители для этих миров). В Фортране же это реализовалось на раз-два через common-блоки! Потом какие-то аналоги common blocks начали делать в паскаль-компиляторах (но это уже потом! в учебниках паскаля это не было свойством языка, а только свойством реализации в конкретном компиляторе). Потом появились на краткий исторический миг пакетные языки, а потом domain specificity начали понятными словами объяснять как делать в ООП и в реляционных моделях данных - тут все эти "пакетные языки" и деревянные с сетевыми базы данных начала восьмидесятых и смыло в унитаз истории, где они и находятся до сих пор.
Вся дискуссия в чате крутилась вокруг того, что удобных для программирования eDSL языков программирования/моделирования/запросов к базам данных/представления знаний нет. Так что я продолжаю придерживаться мнения, которое выработалось у меня на прошлом такте дискусии (https://ailev.livejournal.com/1487293.html): работать тогда будем с Julia как хост-языком. И на Julia будем реализовывать структуры данных и солверы SysMoLan как eDSL.
Вчера на докладе на митапе по Julia (https://juliameetup.timepad.ru/event/1047482/, слайды https://yadi.sk/i/yBeUJJj1iuiJXQ, видео https://vimeo.com/360541672#t=4940s) я высказал ещё пару идей. Солверы для eDSL отличаются тем, что эффективно обрабатывают частные случаи -- предоставляют оптимизированные для этих частных случаев решения. И в Julia как раз отрабатывается такой подход на примерах методов оптимизации (JuMP) и методов решения систем дифференциальных уравнений (DifferentialEquations). Солверы этих систем -- это просто коллекция самых разных солверов, эффективных для самых разных ситуаций. Итого eDSL выглядит как набор типов, в терминах которых удобно описывать предметную область, плюс набор эффективных солверов -- типы должны универсально отражать задачи предметной области, а солвер должен устойчиво работать и жужжать в части скорости. Поэтому типы должны быть более-менее богаты в части их конструирования для отражения объектов и отношений в domain (сравнимы в этом плане с богатыми типами статических языков программирования), но динамическими, чтобы по ходу дела в runtime подбирать оптимизацию для solver. Ну, и проблема двух языков: на одном и том же языке и компактно и красиво (с рафинадом) высокоуровнево выражать domain, но не теряя низкоуровневости в скорости. И настолько не теряя низкоуровневости, чтобы эта оптимизация докатывалась аж до уровня железа -- до GPU. Вот Julia как раз имеет примеры таких решений. Вот этим путём и хочется пойти для SysMoLan: иметь возможность самых разных солверов для предлагаемых SysMoLan как eDSL структур данных.
Идти туда, как мне кажется, нужно в несколько шагов:
1. Сделать простой (архитектурный и требований) текстовый моделер для простых архитектур и использовать его, например, для обучения инженерии требований и инженерии системной архитектуры. У меня проходит в год сотня студентов и курсантов по разным линиям, вот это будет учебный софт. SysMoLan в объёме реализации IEC81346-1 для моделирования системного разбиения (чтобы можно было показать функциональное и конструктивное системное разбиение в их взаимосвязи на пару уровней) тут вполне подойдёт. Это MVP. Ничего вычислять даже не будем (может быть, будем проверять целостность, но и тут не факт), только отображать удобно. Солвер -- голова инженера. Для чего такое нужно? Для помощи со стороны компьютера в присмотре за вниманием в ходе архитектурной работы и работы над требованиями, речь идёт о киборгизация архитектора (вот тут про киборгизацию присмотра за вниманием: https://ailev.livejournal.com/1488271.html). Как над шахматными партиями удобней думать, если есть просто шахматная доска, на которую можно смотреть, так и архитектурный моделер помогает думать уже тем, что он помогает стабилизировать внимание архитектора.
2. Иметь полноценный текстовый язык представления знаний в качестве полноценного системного языка. Тут уж точно иметь eDSL, ибо к более-менее сложным архитектурным моделям и моделям требований захочется делать запросы.
В чате была дискуссия о том, что лучшим приближением к языкам представления знаний является common logic, и какой-нибудь FOL солвер. При этом SQL предлагался как успешный вариант языка для FOL -- без пояснения того, как это всё предполагается в работе у инженера. Ибо логические языки почему-то нигде не взлетели в их чистом логическом виде.
Тут ещё и социальные аспекты, конечно. Пара релевантных ссылок в Communications of ACM (http://cacm.acm.org/blogs/blog-cacm/173328-programming-languages-are-the-most-powerful-and-least-usable-and-learnable-user-interfaces/fulltext) -- там обсуждается вопрос, почему люди не хотят учить языки программирования (языки моделирования, языки мета-моделирования). Там вводят понятия cognitive load (http://en.wikipedia.org/wiki/Cognitive_load, связанные с использованием рабочей памяти умственные усилия), для разных людей они будут разные при изучении предмета. И далее говорится, что люди оценивают не реальную когнитивную нагрузку, а субъективно воспринимаемую (percieved) будущую нагрузку -- когда вы даже воспринимать её по факту не можете, ибо ещё не знакомы с предметом. Да, и полезность вы тоже представить не можете, ибо не знакомы с предметом. А решение "учить-не учить" принимается до изучения предмета. То есть бесполезно уговаривать что-то учить, потому как оно "полезно". Решение принимается не только и не столько по "пользе", сколько по "цене изучения" -- например, считает ли потенциальный ученик, что у него есть способности к предмету. Это всё expectancy value motivational theory -- https://www.researchgate.net/publication/265965932_Expectancy-Value-Cost_Model_of_Motivation. If students are not convinced they can learn it and they are not convinced of the value, then they don't learn it. Решение автор текста предлагает в повышении usability для изучаемых предметов (языков программирования/моделирования), но и learnability -- это разные свойства. Requirements нужно формулировать для обеих характеристик. Легко такую банальность предложить, трудно выполнить.
Вопрос мой в том, что современные информационные системы решают многие из тех задач, которые раньше считалось, что смогут решать только экспертные системы. И эти системы написаны на обычных языках программирования, а не на логических языках. Нет ли какого-то способа представления знаний, отличного от тупого использования логического языка? Логическая парадигма только одна из многих, и в языках программирования она явно не главная. Иначе мы бы видели вокруг сплошных потомков Пролога. Но нет, потомки Пролога везде маргинализуются, и никакая опенсорсовость им не помогает. CycL тоже делал OpenCyc, потом закрыл этот проект: не взлетело. Логическое не взлетает, на SQL делают только запросы в базу данных, а не программируют -- вот я и интересуюсь, что ещё на свете существует для представления знаний. Какая-нибудь Java для представлений знаний неудобна, но модели самых разных domain обрабатываются в мире главным образом на ней, а не на CycL или Agda. Получается, вся краса мира у нас уходит в язык программирования, который нужен для того, чтобы вызвать SQL над базой данных, в которых и отображён domain. При этом как domain отражается в реляционных базах данных - понятно, этому учат в университетах, и по большому счёту DDD (domain-driven design) тоже редко когда про язык программирования, чаще про базы данных.Ответа в чате я так и не получил, хотя обсуждение и было бурным. Так что за подробностями отправим в чат, а тут продолжим.
3. Иметь дифференцируемый язык представления знаний как eDSL, чтобы использовать этот язык не только для ручного ввода архитектурных моделей и моделей требований в рамках облегчения работы subject expert по knowledge aquisition, но и в рамках порождения/generation, а ещё в рамках оптимизации (про "дифференцируемое всё" я писал в https://ailev.livejournal.com/1464563.html). У Julia тут неплохая репутация: Viral Shah [один из разработчиков компилятора Julia] addressed the World Artificial Intelligence Conference, held in Shanghai Aug 29-31 with a discussion on "Julia: Generalizing Deep Learning with Differentiable Programming" (почему я и хотел бы держаться к Julia поближе, а не к C#, С++, R или каким-то другим языкам, не приспособленным для численных методов). Порождаемые архитектуры, оптимизируемые архитектуры, фронтир - вот это всё тут, все эксперименты с искусственным интеллектом и компьютерным творчеством.
4. А ещё нужно будет реализовать mapper (генератор конверторов/адаптеров/плагинов/мостов и т.д. -- систему типа .15926 https://github.com/TechInvestLab/dot15926/, только не обязательно на ISO15926, зато с удобным порождением парсеров и генераторов данных, eDSL для этого), ибо любой архитектурный редактор быстро будет нуждаться в частных моделях из разных САПР, и дело быстро дойдёт до полноценной PLM. Когда будет реализовываться мэппер, там результат будет вполне дискретный и формальный и FOL внутри, а вот методы получения моделей данных могут быть с использованием нейросетей, вероятностных языков и разных других численных алгоритмов. В итоге получится гибрид, а не только нейросети или только строгая логика. Вот, кстати, пример такого "загрузчика данных" (мэппера) для табличек: о "импорту табличек в программу", Flatfile can automatically match 95% of imported columns, using a combination of machine learning and fuzzy matching. Users can upload data via CSV, XLS, or simply paste from the clipboard - https://venturebeat.com/2019/09/10/flatfile-pursues-intelligent-data-importing-with-2-million-round/. JuliaDB при этом тоже работает с файлами табличек, в колонках которых могут быть любые типы Julia, а не только числа или строки, но всё-таки мэппер должен работать не только с табличными форматами. Первое, о чём спросят инженеры, так это о мэппинге 3D-моделей современных САПР.
Задача представления системных знаний на SysMoLan сложная, поэтому решаем её эволюционным путём, а не "сразу всё во взаимоувязке". Системный подход не должен становиться болезнью, когда вгоняет проект в analysis paralysis и заставляет "учесть всё-всё" в один подход и один проход.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216230511529525