Более чем год назад мы публично представили нашу открытую и бесплатную платформу lsFusion. Многие тогда задавали нам вопрос : зачем мы создавали свой собственный язык, ведь уже существует огромное множество других популярных языков.

Да, мы прекрасно понимали, что собственный язык значительно увеличивает порог входа в технологию. Нет, нам нужен был специализированный синтаксис не потому, что все остальные обладают фатальным недостатком. Мы - не сторонники изобретения велосипедов, и при разработке платформы, в отличие от 1С, старались максимально использовать уже готовые открытые решения.

Но оглядываясь назад я, к сожалению, не вижу вариантов, как мы могли поступить иначе. В этой статье я попытаюсь объяснить почему.

Текущее положение дел

Предположим, что вы хотите разработать небольшое приложение по учету ИТ-активов, рассмотрению каких-либо заявок, простому финансовому учету, бюджетированию, обычному складскому учету или любое другое бизнес-приложение. Данные в этом приложении должны храниться в РСУБД - для надежности и скорости работы. Пользователю необходимо предоставить простой и удобный веб-интерфейс.

Для реализации этой задачи будем использовать, например, Java-stack технологий (хотя ничего принципиально не изменится, если это будет тот же Python). Посмотрим, знание каких языков нам для этого понадобится :

• Java. Основной язык, на котором будет реализовано большинство логики приложения.

• XML. Мало кто считает его языком, тем не менее, даже с точки зрения названия (Extensible Markup Language) он им является. Хотя конечно же, это не язык программирования, а язык разметки. Нам он так или иначе понадобится, поскольку именно его используют для конфигурирования множество библиотек (например, Spring, log4j или тот же Apache Tomcat). Кроме того, при разработке фронтенда придется использовать HTML, который, можно сказать, является разновидностью XML.

• SQL. Теоретически можно обойтись без него, и использовать какую-нибудь ORM технологию (например, Hibernate). Однако, при обработке хоть сколько-нибудь большого объема информации все равно придется переходить или на плоский SQL, или на псевдо-SQL (вроде HQL).

• JavaScript. Придется использовать, так как мы хотим современный, быстрый и удобный веб-интерфейс, а не перегружать страницу при любом действии как в древние времена.

• CSS. Тоже язык разметки со своим специфическим синтаксисом (хоть и довольно простым).

Проблемы

Каждый из этих языков имеет свой отличительный синтаксис, кардинально отличающийся от остальных. Разве что JavaScript похож на Java, но если мы возьмем более модный Python, то будет еще один совершенно новый синтаксис.

Следует отметить, что за каждым из этих языков своя архитектура и логика, которую потребуется изучить перед началом использования. Да, большинство современных разработчиков привыкло к текущему положению вещей, и для них это кажется нормальным. 

Но представьте себя на месте человека, который только “вошел в ИТ”, и не хочет глубоко заниматься программированием, а просто хочет разрабатывать бизнес-приложения. Например, до этого он был бизнес-аналитиком, системным администратором или просто менеджером. При первом взгляде на то, что ему придется знать, у человека может легко случиться приступ депрессии, и он просто бросит эту затею.

Многие конечно возразят, что нечего непрофессионалам браться за разработку приложений. Каждый должен заниматься своим делом, и для реализации такой задачи нужно взять фронтенд, бэкенд и SQL разработчиков, где каждый будет специалистом в своей области и языке. Более подробно эту проблему мы описывали в этой статье.

Во-первых, это то же самое, что сказать, что для того, чтобы вырыть яму на дачном участке нужно обязательно пригласить проектировщика, бульдозериста и разнорабочего. Все-таки разные задачи требуют решений разной сложности. 

Во-вторых, каждый, кто когда либо занимался управлением проектом знает, что взаимодействие нескольких человек - это всегда дополнительные проблемы, которые ведут к удорожанию и задержкам проекта. Недаром в последнее время в цене Full-stack разработчики.

Решение

Оценивая все вышесказанное, при разработке платформы возник резонный вопрос : а что если мы хотим, чтобы вся логика задавалась в одном универсальном языке, где задается и доменная логика, и логика вычислений и пользовательский интерфейс. 

Во-первых, это будет проще для изучения новичку. 

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

В-третьих, языки всегда описывают некоторую архитектуру. Платформа имеет декларативную функциональную логику, и существующие императивные языки не очень хорошо подходят для ее описания.

Приняв решение о том, что для решения такой проблемы без собственного языка никак не обойтись, нужно было решить какой синтаксис из уже имеющихся взять за основу. Вариантов по большому счету было два : C-ишный синтаксис, который используется в Java/JavaScript (построенный на специальных символах), или SQL-подобный синтаксис (построенный на ключевых словах).

Мы выбрали второй вариант, так как одной из целей была простота языка, а SQL изначально создавался для бизнес-пользователей, а не разработчиков. Кроме того, SQL, как и lsFusion, описывает декларативную логику, а не императивную, как Java и другие универсальные языки. Еще одним фактором такого решения стало то, что мы хотели встроить в язык достаточно большое количество возможностей, и нужно было много ключевых слов для этого. Сложное сочетание спецсимволов и ключевых слов могло быть не очень интуитивно понятно. Стоит отметить, что похожий синтаксис использовался в ранее популярном языке для работы с данными и бизнес-приложениями FoxPro. 

Выбрав решение с ключевыми словами, нужно было еще определиться ,в каком регистре они должны быть. Для SQL на эту тему ведется много баталий. Для первоначальной реализации мы все-таки выбрали схему с большими буквами для ключевых слов, чтобы отделять их от идентификаторов при работе без IDE. Именно такая схема была в первоначальной логике SQL и того же FoxPro, и лишь потом начали практиковаться разные виды регистров. В следующих версиях lsFusion мы также планируем разрешить использовать разный регистр букв для ключевых слов.

Дальше было лишь делом техники реализовать свой язык. Для этого мы взяли ANTLR для разбора языка, а также реализовали плагин для IntelliJ IDEA. Как именно это было сделано, мы возможно расскажем в будущих статьях.

Язык lsFusion получился достаточно похожим на SQL, с той лишь поправкой, что SQL описывает таблицы и запросы, а lsFusion - функциональную логику. Пример того, как логика, описанная в SQL, соответствует такой же логике в lsFusion описана в статье Функциональная СУБД. Примеры остального синтаксиса можно увидеть вот здесь : императивная логика, GUI. Более подробное описание языка можно найти в одних из первых трех статей блога (1, 2, 3).

Надеюсь, что у читателя статьи создалось представление, почему мы решили использовать свой собственный язык, а не создавать очередной Java/Python/Ruby-framework.