Это куда проще, чем городить монструозный гибридный язык.
Вы уверены, что монолит, представляющий из себя спагетти из разных подходов, будет удобен в дальнейшей поддержке и, не дай бог, модификации?
Во что обойдется, например, расширение логики в виде добавления нескольких полей в таблицу? Или изменение условий отбора объектов для последующей разработки?
Я надеюсь, что он не будет монструозным. По крайней мере, цель как раз в том, чтобы упростить работу с бизнес-логикой. Чтобы ее можно было выразить более кратко и четко по сравнению с традиционным ООП подходом, в том числе облегчить ее модификацию.
Т.е. Вы хотите сказать, что сможете поднять такой язык, довести его до уровня стандартизации, поддерживать его?
Нет, самостоятельно я конечно сделать этого не смогу. Но могу поделиться своими идеями с IT сообществом.
Кроме того, в серьезных приложениях всегда приходится искать баланс между простотой кода, его эффективностью (скоростью работы) и загрузкой машины.
Кроме того, сложные задачи часто не ограничиваются только бизнеслогикой, нужна еще обвязка
Согласен, но именно в этом я вижу преимущества гибридного подхода — каждую задачу можно решить с помощью наиболее подходящих инструментов. Основную часть бизнес логики можно реализовать в логическом стиле, там где нужна тонкая оптимизация — разбавить логический стиль функциональным или императивным. А вся обвязка будет реализована так же как и раньше — в функциональном или ООП стиле.
Ну и насчет популярности — можете назвать другие, кроме ILE от IBM, попытки реализации подобного подхода? Я вот не сталкивался с таким.
Я тоже не сталкивался. Я имел в виду, что ILE технология не является мейнстримом, пока что это скорее нишевое решение для специфических задач. Думаю, что это потому, что писать код одновременно на нескольких языках неудобно, а взаимодействие таких частей кода будет довольно ограниченным, например, только вызовами процедур. Гибридный подход позволяет соединить компоненты гораздо более тесно.
Да, согласен. Сейчас у меня есть реализация proof-of-concept версии вычислителя, которая умеет выполнять запросы к модели. А так же я сделал два модуля к ней. Первый умеет считывать содержимое CSV файлов и использовать его в качестве входных данных для модели. А второй умеет с помощью Selenium считывать содержимое Web-страницы включая фактические цвета, размеры и расположение элементов. И можно построить модель страницы на семантическом уровне так как ее воспринимает человек а не на основе DOM. Получился простейший прототип Robotic Process Automation приложения.
В планах собрать вариант вычислителя, который будет вместо выполнения запроса транслировать модель в код на SQL, Cypher или SPARQL. Также была идея реализовать фреймворк для in-memory вычислений взяв за основу Spark, но на основе объектной логики в дополнение к RDD джоинам и SQL. К сожалению, на все это катастрофически не хватает времени.
Отвечу сначала про «фичи». Они могут быть связаны как с новыми возможностями вычислительного ядра (например, автоматическая сборка мусора у JAVA по сравнению с С++) так и с синтаксисом языка (например, Scala и Kotlin имеют то же вычислительное ядро, что и JAVA, именно синтаксис помог завоевать им своих сторонников). Так что синтаксис тоже может быть «килер-фичей», если он делает программирование более простым, удобным или надежным.
Я описал особенности синтаксиса и способы моделирования данных. За этим синтаксисом спрятано вычислительное ядро, способное логически выводить сущности обектов из описания модели. В его основе лежит фреймовая (объектная) логика и SLD резолюция. Я планирую описать это ядро в будущих публикациях. Это ядро может быть реализовано разными способами:
— встроено в полном объеме в новый язык программирования;
— встроено с некоторыми ограничениями в один из существующих языков на основе JVM;
— можно попробовать создать на его основе фреймворк по типу GraphQL, что, правда, еще немного органичит его возможности;
— можно создать DSL на его основе и сделать его основой для приложения бизнес-аналитики, автоматизированного тестирования или RPA;
— с некоторыми ограничениями и модификациями его можно использовать в качестве движка запросов для мультимодельной СУБД или для какой-нибудь облачной платформы, интегрирующей данные из разных источников.
Это те варианты, которые я считаю возможными. Но я еще не выбрал, на каком из них стоит сконцентрироваться.
Сейчас я описываю не столько синтаксис, сколько общие идеи и механику языка. Но поскольку этих идей оказалось очень много и они получились очень масштабными, то реализовывать их можно в разном порядке и объеме. У меня еще нет окончательного видения, как будет этот язык реализован, возможны разные варианты.
«Киллер-фич» будет несколько.
Во-первых, с моей точки зрения, возможностей языка SQL в некторых случаях недостаточно. Например, в области бизнес аналитики запросы могут большой размер и сложную вложенную структуру. Я хочу заменить монолитный запрос набором маленьких, описывающих структуру понятий бизнес логики, которые можно компоновать и повторно использовать. Есть некоторые диалекты SQL, умеющие работать с JSON, но для этого его объектную структуру они преобразовуют в плоскую табличную форму. Я хочу объектную струкутуру сделать в модели основной. Язык SQL имеет ограниченные возможности для создания рекурсивных запросов. Я хочу отказаться от этого ограничения и разширить область применения языка моделирования и на графовые базы данных. Другими словами я хочу заменить язык запросов языком моделирования. Об этом я планирую написать в следующей статье.
В во-вторых, я хочу протащить свой язык моделирования на уровень приложения и сделать определения понятий элементом первого уровня гибридного языка. Чтобы с его помощью можно было описать модель предметной области и сделать ее «каркасом» или «скелетом» приложения. Я думаю, что объектная форма языка моделирования должна помочь в решении проблемы объектно-реляционного импеданса. Также он будет удобен при работе со сложными иерархическими стурктурами данных, XML, HTML документами и т.п.
Я считаю, что декларативный логический стиль программирования недооценен и мог бы быть полезен при разработке приложений, богатых бизнес-логикой и ориентированных на данные. На стороне БД такой стиль реализован в виде SQL. Элементы такого стиля начинают проникать и на уровень приложения, например в виде LINQ или GraphQL. Я хочу объединить возможности LINQ и GraphQL, построить объединенное решение на базе формальной логики, использовать его для описания структуры понятий бизнес-логики и сделать их элементами первого класса в гибридном языке.
Механическое объединение нескольких языков не позволит этого сделать. Оно усложнит код, его понимание, разработку, отладку. Оно может быть полезен в некоторых задачах, например, при поддержке legacy кода, но так и не смогло завоевать популярности.
Еще нужно учесть, что вся подготовка ничего не гарантирует. Интервью это лотерея с не такими уж большими шансами. Попалась знакомая задача — есть шанс показать хороший результат. Если попалась незнакомая, то 40 минут явно мало для того, чтобы изобрести решение, отладить его и обсудить оптимизации.
Ну почему же, я очень открыт к компромиссам и вижу несколько потенциальных вариантов реализации языка. Вариант с JVM очень интересен. О возможных вариантах применения языка на практике и его реализации я планирую написать отдельную статью.
А JS я выбрал только в качестве proof of concept, чтобы проверить свои идеи по интеграции логической и имеперативной компонент на практике. Просто потому, что это один из самых простых и быстрых вариантов в реализации.
Возможно такая ситуация и возникнет. Но на данном этапе мне сложно представить, какую форму она примет, и какие инструменты в язык стоило бы добавить, чтобы было удобно их выявлять.
В нашей дискуссии смешались два вопроса: выразительность логики в общем и конкретно мой язык. Если говорить о логике в целом, то выразительность безусловно важна. Но в каждой области ее применения будут свои компромисы между выразительностью, decidability и эффективностью алгоритмов вывода.
Конкретно мой язык направлен не на доказательство теорем или построение сложных логических теорий. Он преднаначен для интеграции разнородных данных, имеющих вложенную объектную структуру. Поэтому он должен быть удобен скорее для трансформации объектов, связанных логическими отношениями. А удобство доказательств от противного в нем не будет иметь большого значения.
Безусловно, четырехзначная логика будет более выразительной.
Но я специально хочу ее ограничить. На практике такие противоречивые наборы правил будут встречаться очень редко. И лучше заставить разработчиков избегать противоречий и преформулировать правила вручную, чем постоянно иметь дело с четырехзначной логикой. Это упростит рассуждения, разработку, отладку, обучение, реализацию языка.
Да, это было бы хорошо. Пока что я могу рассказать, какия я хотел бы видеть язык программирования. И где он мог бы быть полезен. А после этого можно будет попробовать организовать его реализацию. В одиночку от начала до конца сделать это нереально.
Про бесполых существ в этих формулах ничего не говорится. Если вообще нет фактов, о том, какого пола Х, то в Stable Model Semantic делается вывод, что возможны оба варианта, Х может быть как мужчиной, так и женщиной. Бесполых существ надо вводить в формулы отдельно:
male(X) ← person(X) AND NOT female(X) AND NOT neutral(X)
female(X) ← person(X) AND NOT male(X) AND NOT neutral(X)
neutral(X) ← person(X) AND NOT male(X) AND NOT female(X)
Чем больше в логике возможных значений, тем сложнее с ней работать, алгоритмы логического вывода тоже становятся сложнее. Думаю, что «абсурдная» логика была бы удобна, если в явном виде нужно работать с утверждениями, противоречащими друг другу. На практике в области разработки ПО в большистве случаев достаточно двоичной логики.
Что касается семантики стойких моделей, то утверждения p ← not q и q ← not p рассматриваются не как абсурдные, а как дополняющие друг друга. Оператор отрицания в Stable model semantics понимается так же утверждения по умолчанию в Default logic. То есть
not q понимается не как безусловное отрицание, а как некое дополнительное подтверждение остальных правил, которое имеет смысл, только если оно согласуется с ними.
Например, в
male(X) ← person(X) AND NOT female(X)
female(X) ← person(X) AND NOT male(X)
NOT female(X) и NOT male(X) это дополнительные утверждения, которые можно отбросить, если они противоречат остальным правилам. Т.е., если мы знаем, что male(alex) истинно, то not female(alex) можно проигнорировать. И эти правила трансформируются в утверждения, что все люди по умолчанию мужчины, кроме тех, про кого точно известно, что они женщины (так же и наоборот).
Да, если логику высшего порядка использовать необдуманно, то можно легко выстрелить себе в ногу. Как с точки зрения запутанности кода, так и производительности.
Я предполагаю, что логика высшего порядка будет полезна в тех случах когда нужно определить общие отношения между понятиями, не привязываясь к их имени. Например, родитель-потомок, больше-меньше, геометрические отношения, отношения во времени и т.п. В большинстве случаев такие отношения будут использоваться не сами по себе, а совместно с другими понятиями. Например, отношение ParentRel можно использовать для поиска каких-нибудь вложенных элементов: concept NestedElements (parent = e1, child = e2) from Element e1, ParentRel r(parent = e1, child = e2), Element e2 where ...
Сначала будет найдет элемент e1, это позволит связать название понятия в отношении ParentRel с «Element», а затем найти все вложенные элементы и отфильтровать нужные из них. Также это отношение можно применить и к другим понятиям, например, к иерархиям подразделений в компании. На мой взгляд, к дополнительной сложности, запутанности и излишнему росту связей подобные конструкции приводить не должны.
Это можно считать аналогом generic классов в ООП модели. В которой, например, контейнеры списков можно применить к любому одержимому не привязываясь к конкретным его классам.
Если же в таком отношении имя родительского понятия на момент вызова будет неопределно, то это будет аналогом запроса к схеме данных. Будут найдены все понятия, удовлетворяющие заданным условиям.
Я бы копал в сторону среды исполнения, которая должна сама находить противоречия в модели.
Да, пока этой задачей я не занимался. Но это интересная тема. Надеюсь, я когда-нибудь смогу до нее добраться.
Я надеюсь, что он не будет монструозным. По крайней мере, цель как раз в том, чтобы упростить работу с бизнес-логикой. Чтобы ее можно было выразить более кратко и четко по сравнению с традиционным ООП подходом, в том числе облегчить ее модификацию.
Нет, самостоятельно я конечно сделать этого не смогу. Но могу поделиться своими идеями с IT сообществом.
Согласен, но именно в этом я вижу преимущества гибридного подхода — каждую задачу можно решить с помощью наиболее подходящих инструментов. Основную часть бизнес логики можно реализовать в логическом стиле, там где нужна тонкая оптимизация — разбавить логический стиль функциональным или императивным. А вся обвязка будет реализована так же как и раньше — в функциональном или ООП стиле.
Я тоже не сталкивался. Я имел в виду, что ILE технология не является мейнстримом, пока что это скорее нишевое решение для специфических задач. Думаю, что это потому, что писать код одновременно на нескольких языках неудобно, а взаимодействие таких частей кода будет довольно ограниченным, например, только вызовами процедур. Гибридный подход позволяет соединить компоненты гораздо более тесно.
В планах собрать вариант вычислителя, который будет вместо выполнения запроса транслировать модель в код на SQL, Cypher или SPARQL. Также была идея реализовать фреймворк для in-memory вычислений взяв за основу Spark, но на основе объектной логики в дополнение к RDD джоинам и SQL. К сожалению, на все это катастрофически не хватает времени.
За комментарии и ссылки на статьи спасибо!
Я описал особенности синтаксиса и способы моделирования данных. За этим синтаксисом спрятано вычислительное ядро, способное логически выводить сущности обектов из описания модели. В его основе лежит фреймовая (объектная) логика и SLD резолюция. Я планирую описать это ядро в будущих публикациях. Это ядро может быть реализовано разными способами:
— встроено в полном объеме в новый язык программирования;
— встроено с некоторыми ограничениями в один из существующих языков на основе JVM;
— можно попробовать создать на его основе фреймворк по типу GraphQL, что, правда, еще немного органичит его возможности;
— можно создать DSL на его основе и сделать его основой для приложения бизнес-аналитики, автоматизированного тестирования или RPA;
— с некоторыми ограничениями и модификациями его можно использовать в качестве движка запросов для мультимодельной СУБД или для какой-нибудь облачной платформы, интегрирующей данные из разных источников.
Это те варианты, которые я считаю возможными. Но я еще не выбрал, на каком из них стоит сконцентрироваться.
Во-первых, с моей точки зрения, возможностей языка SQL в некторых случаях недостаточно. Например, в области бизнес аналитики запросы могут большой размер и сложную вложенную структуру. Я хочу заменить монолитный запрос набором маленьких, описывающих структуру понятий бизнес логики, которые можно компоновать и повторно использовать. Есть некоторые диалекты SQL, умеющие работать с JSON, но для этого его объектную структуру они преобразовуют в плоскую табличную форму. Я хочу объектную струкутуру сделать в модели основной. Язык SQL имеет ограниченные возможности для создания рекурсивных запросов. Я хочу отказаться от этого ограничения и разширить область применения языка моделирования и на графовые базы данных. Другими словами я хочу заменить язык запросов языком моделирования. Об этом я планирую написать в следующей статье.
В во-вторых, я хочу протащить свой язык моделирования на уровень приложения и сделать определения понятий элементом первого уровня гибридного языка. Чтобы с его помощью можно было описать модель предметной области и сделать ее «каркасом» или «скелетом» приложения. Я думаю, что объектная форма языка моделирования должна помочь в решении проблемы объектно-реляционного импеданса. Также он будет удобен при работе со сложными иерархическими стурктурами данных, XML, HTML документами и т.п.
Механическое объединение нескольких языков не позволит этого сделать. Оно усложнит код, его понимание, разработку, отладку. Оно может быть полезен в некоторых задачах, например, при поддержке legacy кода, но так и не смогло завоевать популярности.
А JS я выбрал только в качестве proof of concept, чтобы проверить свои идеи по интеграции логической и имеперативной компонент на практике. Просто потому, что это один из самых простых и быстрых вариантов в реализации.
Конкретно мой язык направлен не на доказательство теорем или построение сложных логических теорий. Он преднаначен для интеграции разнородных данных, имеющих вложенную объектную структуру. Поэтому он должен быть удобен скорее для трансформации объектов, связанных логическими отношениями. А удобство доказательств от противного в нем не будет иметь большого значения.
Но я специально хочу ее ограничить. На практике такие противоречивые наборы правил будут встречаться очень редко. И лучше заставить разработчиков избегать противоречий и преформулировать правила вручную, чем постоянно иметь дело с четырехзначной логикой. Это упростит рассуждения, разработку, отладку, обучение, реализацию языка.
male(X) ← person(X) AND NOT female(X) AND NOT neutral(X)
female(X) ← person(X) AND NOT male(X) AND NOT neutral(X)
neutral(X) ← person(X) AND NOT male(X) AND NOT female(X)
not q понимается не как безусловное отрицание, а как некое дополнительное подтверждение остальных правил, которое имеет смысл, только если оно согласуется с ними.
Например, в
male(X) ← person(X) AND NOT female(X)
female(X) ← person(X) AND NOT male(X)
NOT female(X) и NOT male(X) это дополнительные утверждения, которые можно отбросить, если они противоречат остальным правилам. Т.е., если мы знаем, что male(alex) истинно, то not female(alex) можно проигнорировать. И эти правила трансформируются в утверждения, что все люди по умолчанию мужчины, кроме тех, про кого точно известно, что они женщины (так же и наоборот).
Я предполагаю, что логика высшего порядка будет полезна в тех случах когда нужно определить общие отношения между понятиями, не привязываясь к их имени. Например, родитель-потомок, больше-меньше, геометрические отношения, отношения во времени и т.п. В большинстве случаев такие отношения будут использоваться не сами по себе, а совместно с другими понятиями. Например, отношение ParentRel можно использовать для поиска каких-нибудь вложенных элементов:
concept NestedElements (parent = e1, child = e2) from Element e1, ParentRel r(parent = e1, child = e2), Element e2 where ...Сначала будет найдет элемент e1, это позволит связать название понятия в отношении ParentRel с «Element», а затем найти все вложенные элементы и отфильтровать нужные из них. Также это отношение можно применить и к другим понятиям, например, к иерархиям подразделений в компании. На мой взгляд, к дополнительной сложности, запутанности и излишнему росту связей подобные конструкции приводить не должны.
Это можно считать аналогом generic классов в ООП модели. В которой, например, контейнеры списков можно применить к любому одержимому не привязываясь к конкретным его классам.
Если же в таком отношении имя родительского понятия на момент вызова будет неопределно, то это будет аналогом запроса к схеме данных. Будут найдены все понятия, удовлетворяющие заданным условиям.
Да, пока этой задачей я не занимался. Но это интересная тема. Надеюсь, я когда-нибудь смогу до нее добраться.