Комментарии 8
Ваши статьи читать познавательно, но есть сомнения с выбранном способе достижения цели (разработке мультипарадигмного языка). Мне кажется, что вы очень сильно сконцентрировались на грамматике и делаете упор на разработку синтаксиса.
Но с грамматикой всем не угодишь (146%), поэтому чтобы вы не предложили, будут как противники, так и сторонники вашего подхода. Но помните, что тратя время на грамматику, вы тем самым отнимаете время на разработку реализации самого языка!
Более того, я так и не понял, что конкретно вы планируете реализовать кроме самого синтаксиса? Какая «киллер-фича» планируется у языка?
Но с грамматикой всем не угодишь (146%), поэтому чтобы вы не предложили, будут как противники, так и сторонники вашего подхода. Но помните, что тратя время на грамматику, вы тем самым отнимаете время на разработку реализации самого языка!
Более того, я так и не понял, что конкретно вы планируете реализовать кроме самого синтаксиса? Какая «киллер-фича» планируется у языка?
«Киллер-фич» будет несколько.
Во-первых, с моей точки зрения, возможностей языка SQL в некторых случаях недостаточно. Например, в области бизнес аналитики запросы могут большой размер и сложную вложенную структуру. Я хочу заменить монолитный запрос набором маленьких, описывающих структуру понятий бизнес логики, которые можно компоновать и повторно использовать. Есть некоторые диалекты SQL, умеющие работать с JSON, но для этого его объектную структуру они преобразовуют в плоскую табличную форму. Я хочу объектную струкутуру сделать в модели основной. Язык SQL имеет ограниченные возможности для создания рекурсивных запросов. Я хочу отказаться от этого ограничения и разширить область применения языка моделирования и на графовые базы данных. Другими словами я хочу заменить язык запросов языком моделирования. Об этом я планирую написать в следующей статье.
В во-вторых, я хочу протащить свой язык моделирования на уровень приложения и сделать определения понятий элементом первого уровня гибридного языка. Чтобы с его помощью можно было описать модель предметной области и сделать ее «каркасом» или «скелетом» приложения. Я думаю, что объектная форма языка моделирования должна помочь в решении проблемы объектно-реляционного импеданса. Также он будет удобен при работе со сложными иерархическими стурктурами данных, XML, HTML документами и т.п.
Во-первых, с моей точки зрения, возможностей языка SQL в некторых случаях недостаточно. Например, в области бизнес аналитики запросы могут большой размер и сложную вложенную структуру. Я хочу заменить монолитный запрос набором маленьких, описывающих структуру понятий бизнес логики, которые можно компоновать и повторно использовать. Есть некоторые диалекты SQL, умеющие работать с JSON, но для этого его объектную структуру они преобразовуют в плоскую табличную форму. Я хочу объектную струкутуру сделать в модели основной. Язык SQL имеет ограниченные возможности для создания рекурсивных запросов. Я хочу отказаться от этого ограничения и разширить область применения языка моделирования и на графовые базы данных. Другими словами я хочу заменить язык запросов языком моделирования. Об этом я планирую написать в следующей статье.
В во-вторых, я хочу протащить свой язык моделирования на уровень приложения и сделать определения понятий элементом первого уровня гибридного языка. Чтобы с его помощью можно было описать модель предметной области и сделать ее «каркасом» или «скелетом» приложения. Я думаю, что объектная форма языка моделирования должна помочь в решении проблемы объектно-реляционного импеданса. Также он будет удобен при работе со сложными иерархическими стурктурами данных, XML, HTML документами и т.п.
Вы ответили опять про особенности синтаксиса и моделирование неких данных, что опять же является грамматикой языка, но не его особенностью.
Вот представьте, что вы уже реализовали свой SQL подобный диалект взаимодействия с БД, например, на препроцессоре С/С++. Но от этого новой «фичи» у С/С++ не появится. Будет новый диалект, а его реализация останется той-же самой (например, gcc).
Чтобы язык превратился в описываемую вами задумку, вам потребуется реализовать некое вычислительное ядро, которое и будет анализировать и выполнять запросы, возвращать данные пользователю и т.д. Вот про это ядро я и задавал вопрос.
У него на вход будет поступать некая информация (например, параметры запроса пользователя), и для него совершенно не важно, в каком синтаксисе эти запросы описаны и какими ключевыми словами (это будут проблемы парсера).
Поэтому уточню вопрос. Какая «фича» языка заставит его изучать новых пользователей или даже бизнес, который умеет считать не только деньги, но и риски?
Вот представьте, что вы уже реализовали свой SQL подобный диалект взаимодействия с БД, например, на препроцессоре С/С++. Но от этого новой «фичи» у С/С++ не появится. Будет новый диалект, а его реализация останется той-же самой (например, gcc).
Чтобы язык превратился в описываемую вами задумку, вам потребуется реализовать некое вычислительное ядро, которое и будет анализировать и выполнять запросы, возвращать данные пользователю и т.д. Вот про это ядро я и задавал вопрос.
У него на вход будет поступать некая информация (например, параметры запроса пользователя), и для него совершенно не важно, в каком синтаксисе эти запросы описаны и какими ключевыми словами (это будут проблемы парсера).
Поэтому уточню вопрос. Какая «фича» языка заставит его изучать новых пользователей или даже бизнес, который умеет считать не только деньги, но и риски?
Отвечу сначала про «фичи». Они могут быть связаны как с новыми возможностями вычислительного ядра (например, автоматическая сборка мусора у JAVA по сравнению с С++) так и с синтаксисом языка (например, Scala и Kotlin имеют то же вычислительное ядро, что и JAVA, именно синтаксис помог завоевать им своих сторонников). Так что синтаксис тоже может быть «килер-фичей», если он делает программирование более простым, удобным или надежным.
Я описал особенности синтаксиса и способы моделирования данных. За этим синтаксисом спрятано вычислительное ядро, способное логически выводить сущности обектов из описания модели. В его основе лежит фреймовая (объектная) логика и SLD резолюция. Я планирую описать это ядро в будущих публикациях. Это ядро может быть реализовано разными способами:
— встроено в полном объеме в новый язык программирования;
— встроено с некоторыми ограничениями в один из существующих языков на основе JVM;
— можно попробовать создать на его основе фреймворк по типу GraphQL, что, правда, еще немного органичит его возможности;
— можно создать DSL на его основе и сделать его основой для приложения бизнес-аналитики, автоматизированного тестирования или RPA;
— с некоторыми ограничениями и модификациями его можно использовать в качестве движка запросов для мультимодельной СУБД или для какой-нибудь облачной платформы, интегрирующей данные из разных источников.
Это те варианты, которые я считаю возможными. Но я еще не выбрал, на каком из них стоит сконцентрироваться.
Я описал особенности синтаксиса и способы моделирования данных. За этим синтаксисом спрятано вычислительное ядро, способное логически выводить сущности обектов из описания модели. В его основе лежит фреймовая (объектная) логика и SLD резолюция. Я планирую описать это ядро в будущих публикациях. Это ядро может быть реализовано разными способами:
— встроено в полном объеме в новый язык программирования;
— встроено с некоторыми ограничениями в один из существующих языков на основе JVM;
— можно попробовать создать на его основе фреймворк по типу GraphQL, что, правда, еще немного органичит его возможности;
— можно создать DSL на его основе и сделать его основой для приложения бизнес-аналитики, автоматизированного тестирования или RPA;
— с некоторыми ограничениями и модификациями его можно использовать в качестве движка запросов для мультимодельной СУБД или для какой-нибудь облачной платформы, интегрирующей данные из разных источников.
Это те варианты, которые я считаю возможными. Но я еще не выбрал, на каком из них стоит сконцентрироваться.
Вот теперь ОК.
Согласен, что синтаксис тоже может быть «фичей», но вряд ли он будет «киллер» ;-) В любом случае, новый язык придется учить, а это уже значительный минус.
Поэтому я и написал, какая особенность у языка планируется, причем, это должен быть не синтаксис, а уникальная особенность, ради которой и новый синтаксис выучить можно. А уж если он будет понятным, то вообще супер!
И если так, то попробуйте набросать простенькую реализацию вычислителя (как я уже отмечал выше, синтаксис для него не важен, пусть этим занимается парсер). Или просто прикинте, чем этот вычислитель будет принципиально отличаться от сервера БД или какого нибудь навороченного ORM?
Не пробовали начать именно с этой части? Ведь грамматика языка, это только интерфейс взаимодействия с ядром (компилятором) и не более того.
Мне очень интересно, т.к. я тоже иногда размышляю над подобными вопросами (Интернациональное программирование на естественных языках, Проблема логических языков программирования)
Согласен, что синтаксис тоже может быть «фичей», но вряд ли он будет «киллер» ;-) В любом случае, новый язык придется учить, а это уже значительный минус.
Поэтому я и написал, какая особенность у языка планируется, причем, это должен быть не синтаксис, а уникальная особенность, ради которой и новый синтаксис выучить можно. А уж если он будет понятным, то вообще супер!
И если так, то попробуйте набросать простенькую реализацию вычислителя (как я уже отмечал выше, синтаксис для него не важен, пусть этим занимается парсер). Или просто прикинте, чем этот вычислитель будет принципиально отличаться от сервера БД или какого нибудь навороченного ORM?
Не пробовали начать именно с этой части? Ведь грамматика языка, это только интерфейс взаимодействия с ядром (компилятором) и не более того.
Мне очень интересно, т.к. я тоже иногда размышляю над подобными вопросами (Интернациональное программирование на естественных языках, Проблема логических языков программирования)
Да, согласен. Сейчас у меня есть реализация proof-of-concept версии вычислителя, которая умеет выполнять запросы к модели. А так же я сделал два модуля к ней. Первый умеет считывать содержимое CSV файлов и использовать его в качестве входных данных для модели. А второй умеет с помощью Selenium считывать содержимое Web-страницы включая фактические цвета, размеры и расположение элементов. И можно построить модель страницы на семантическом уровне так как ее воспринимает человек а не на основе DOM. Получился простейший прототип Robotic Process Automation приложения.
В планах собрать вариант вычислителя, который будет вместо выполнения запроса транслировать модель в код на SQL, Cypher или SPARQL. Также была идея реализовать фреймворк для in-memory вычислений взяв за основу Spark, но на основе объектной логики в дополнение к RDD джоинам и SQL. К сожалению, на все это катастрофически не хватает времени.
За комментарии и ссылки на статьи спасибо!
В планах собрать вариант вычислителя, который будет вместо выполнения запроса транслировать модель в код на SQL, Cypher или SPARQL. Также была идея реализовать фреймворк для in-memory вычислений взяв за основу Spark, но на основе объектной логики в дополнение к RDD джоинам и SQL. К сожалению, на все это катастрофически не хватает времени.
За комментарии и ссылки на статьи спасибо!
Может быть будет интересно про реализацию RPA habr.com/ru/company/testo_lang/blog/521682
Сейчас я описываю не столько синтаксис, сколько общие идеи и механику языка. Но поскольку этих идей оказалось очень много и они получились очень масштабными, то реализовывать их можно в разном порядке и объеме. У меня еще нет окончательного видения, как будет этот язык реализован, возможны разные варианты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проектируем мультипарадигменный язык программирования. Часть 6 — Заимствования из SQL