В последнее время набирают популярность low-code и no-code платформы. В них для разработки приложений предлагается использовать визуальное программирование. При таком подходе, разработчики, в качестве которых выступают обычные бизнес-пользователи, вместо написания программного кода создают приложение при помощи мыши в графическом интерфейсе. Также визуальное программирование в некотором виде используется, например, в Конфигураторе 1С.

Однако, возникает вопрос. Какие преимущества дает визуальное программирование по сравнению с Domain Specific Language ? Безусловно это зависит от области применения. С одной стороны, в классических языках визуальное программирование практически не используется. В то же время при разработке графического интерфейса такой подход конечно же имеет много преимуществ. Однако, при создании интерфейсов, например, с помощью популярной библиотеки React все-таки больше используется плоский код.

Плюсы и минусы

В использовании DSL я вижу следующие плюсы :

  • Поддержка системы контроля версий. В визуальном программировании значительно менее удобно следить за изменениями в логике программы и решать конфликты в коммитах.

  • Возможность копирования/вставки, поиска и замены по текстовым значениям, генерации кода.

В визуальном программировании к плюсам можно отнести следующее :

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

  • Лучшая наглядность при создании пользовательского интерфейса.

Следует отметить, что DSL и визуальное программирование не являются альтернативами друг друга. При правильном подходе визуальный конструктор может и должен генерировать DSL. В качестве такого языка часто используется XML. Однако, читабельность XML оставляет желать лучшего.

Сфера применения

Одним из главных недостатков визуального программирования все-таки является слишком ограниченная сфера его применения. Да, для создания простых CRUD приложений оно подходит достаточно неплохо. Однако, когда требуется некоторое усложнение логики, то все равно приходится возвращаться к программному коду. Тем самым создается определенный семантический разрыв, когда часть логики создана визуально, а часть при помощи классического кода. 

Использование DSL, в свою очередь, позволяет создавать достаточно сложные приложения со значительно меньшими усилиями. Написание кода на специализированным языке может казаться для пользователей сложной задачей. Однако, не стоит забывать, что язык SQL создавался именно для обычных пользователей, и до сих пор используется не только программистами. И если DSL является таким же высокоуровневым как SQL, использует обычные слова вместо специальных символов, то порог вхождения значительно снижается (вот пример одного из таких языков).

Безусловно, для управления “динамическими” системами графический интерфейс подходит значительно лучше, чем текстовый. Например, большинство пользователей все-таки используют графическую оболочку операционных систем, а не командную консоль (хотя для управления серверами, на мой взгляд, консоль местами удобнее). Однако, программы являются более статическими системами. Как правило, изменение работы программ осуществляется регламентно, достаточно редко и могут приводить к другим значительным изменениям (например, миграции данных). И в этом случае значительно повышается важность проверки сделанных изменений, что значительно проще делать именно с плоским программным кодом.

IDE

Одной из отличительных особенностей визуального программирования является то, что разработчик сразу видит все возможности среды разработки. Тем самым ему значительно реже приходится обращаться к документации. С другой стороны, это создает визуальную сложность, тем самым “размывая внимание”. Разработчику сложнее понять, какие именно настройки он изменил, а какие установлены по умолчанию. В плоских файлах все изменения можно легко увидеть при помощи системы контроля версий.

В целом же, использование DSL позволяет создавать значительное более мощные IDE за счет того, что все современные IDE имеют мощные механизмы по разработке плагинов под кастомные языки. Поэтому можно легко создать мощную IDE, значительно более удобную в использовании, чем написанных с нуля IDE для визуальной разработки. Что мы собственно говоря и сделали, получив при этом IDE значительно превосходящую по возможностям тот же Конфигуратор 1С.

Заключение

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

Человек, который сможет более-менее нормально проектировать решения с использованием визуального программирования, без проблем сможет освоить и DSL. При этом, в сложной разработке, плоский код будет ему значительно удобнее по той же причине, почему и в классическом программирование используется именно язык вместо визуального программирования (возможность Copy/Paste, Find/Replace, VCS и т.д.). 

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

Комментарии (27)


  1. rsashka
    26.04.2023 11:20

    Визуальное программирование vs DSL

    Это не взаимоисключающие понятия, так как среда визуального программирования вполне способна генерировать код на DSL.


    1. CrushBy Автор
      26.04.2023 11:20

      Да, в принципе так и должно быть. Но тут дело в том, что многие среды визуальные программирования (разные Low-code и No-code конструкторы) игнорируют это, не создают прослойки в виде DSL, а сериализуют все или в XML, или в какой-нибудь бинарный формат. Возможно, разработчики считают, что никто не будет править вручную DSL.


    1. LordDarklight
      26.04.2023 11:20

      Вот вот, поэтому пункт "Возможность копирования/вставки, поиска и замены по текстовым значениям, генерации кода" несколько сомнителен да и далее автор сам же пишет

      Следует отметить, что DSL и визуальное программирование не являются альтернативами друг друга. При правильном подходе визуальный конструктор может и должен генерировать DSL. В качестве такого языка часто используется XML. Однако, читабельность XML оставляет желать лучшего.

      Редактировать XML так же возможно со всеми копированиями и вставками - хотя признаю, что делать это сложнее, чем в plan-text представлении DSL языка. Хотя тут многое так же зависит от редактора XML.

      Но хочу так же сказать - что правильная IDE (или визуальный конфигуратор) могла бы сделать этот процесс ещё более удобным, чем plan-text редактирование - но таких визуальных редакторов я ещё не встречал - просто эта тема практически не развивается, а вот plan-text IDE в XXI веке развивались очень активно.

      Но моё мнение такое - правильная NoCode (и тем более LowCode) система обязательно должна иметь и текстовое представление структуры алгоритма (в идеале в виде DSL описания, и в идеале так его и хранить, при необходимости создавая структурированный индекс поиска), имея лишь возможность визуализировать и редактировать его визуально!

      • Поддержка системы контроля версий. В визуальном программировании значительно менее удобно следить за изменениями в логике программы и решать конфликты в коммитах.

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

      В итоге - визуальное программирование хорошо тогда, когда за ним стоит и plain-text представление!

      Но тут ещё один момент - лично я не думаю, что пользователи массово будут заниматься NoCode (и тем более LowCode) разработкой. У пользователей своих дела хватает. По своей практике чаще всего пользователям проще свалить даже банальную первичную настройку ПО на любого IT-шника доступного в организации. Всё-так пользователи слишком ленивы, чтобы что-то конфигурировать. Максимум на что их хватает - это на формулы в EXCEL. Но, безусловно, среди пользователей есть исключения, и их не так уж мало.

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

      Ну я бы не назвал такой язык удобным для восприятия. Даже ЯП 1С и то попроще воспринимаемся. Пользователям этот ЯП 100% не годится.

      получив при этом IDE значительно превосходящую по возможностям тот же Конфигуратор 1С.

      Нашли с чем сравнить - конфигуратор 1С практически не развивался уже более 10 лет - да и 20 лет назад он был не таким уже продвинутым, чтобы было на что ровняться даже тогда. Более менее продвинутые IDE это Visual Studio и Rider/IDEA - да и то - прогресс у них только последние годы, да и сейчас они ещё далеки от совершенной IDE - но постепенно движутся с ней.

      Автор та же упустил ещё два метода программирования:

      1. Командный - когда программа полностью редактируется путём отправки команд редактору (вроде бы на Хабре была статья на эту тему, но навскидку не нашёл, может я и ошибаюсь - но идея вполне интересная, особенно на фоне стремления некоторых к переходу на голосовое управление и редактирование с применением возможностей ChatGPT) - тут могут быть как команды к plain-text так и к визуальному представлению

      2. Схематичный - в принципе это подвид визуального (но я считаю, что его стоит выделить как отдельное направление) - когда алгоритм строится в виде блок-схем на плоскости (в 3D ещё не видел, хотя с развитием VR этот вариант вполне может получить развитие)

      А вообще статья получилась ну очень маленькая и очень скромная - по сути тема так и осталась не раскрытой ни с точки зрения постановки проблематик, ни с точки зрения проработки их решения :-(


      1. CrushBy Автор
        26.04.2023 11:20
        +1

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

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

        По своей практике чаще всего пользователям проще свалить даже банальную первичную настройку ПО на любого IT-шника доступного в организации

        Тут в целом согласен. Платформа low-code в данном случае больше нужна, чтобы именно сделать из пользователя IT-шника. Однако, возьмем, например, одну из популярных low-code платформу с визуальным программированием. У них на Github 25.6К звезд. Вряд ли это все вот трушные программисты. Значит видимо и пользователи что-то делают.