21.06.2025 10:07
vi_is_raven 16 956 Источник

Задумывались ли вы, сколько раз при написании кода хотелось:

  • Сократить избыточные конструкции?

  • Улучшить читаемость "запутанного" места?

  • Убрать архаичные элементы грамматики?

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

1. Краткость как основа

"Краткость — сестра таланта" — этот принцип стал нашим главным ориентиром.

Сокращение ключевых слов
Умеренные сокращения экономят время без потери смысла:

  • function → fn

  • namespace → space

  • composite (аналог struct) → type

Интуитивные коллекции
Заменяем "скобочный ад" на лаконичную нотацию:

(: <int>*)* <type>

  • : — маркер коллекции

  • Необязательные числа (<int>*) — размерности (например, :3 для массива из 3 элементов)

  • Последовательность двоеточий определяет вложенность: :: → двумерный массив

  • Тип элемента указывается в конце: :3 String

Доступ к элементам
Унифицированный оператор : для индексов и ключей:

strings:2 // Третий элемент массива (индексация с 0)

ages:"Tom" // Значение по ключу "Tom" в словаре

Как часто во время написания кода вы задумываетесь над тем, что в каком-то месте можно было конструкцию сократить, где-то код невозможно сделать читабельным, или какой-то элемент грамматики — это вообще устаревшее наследство? Данная статья повествует о том, как я провёл небольшое исследование в диванных условиях для того, чтобы разработать идеальный синтаксис для собственного языка программирования. Статью я разбил на три этапа, соответствующих трём принципам, которым я следовал во время разработки синтаксиса. Так же я работал с учётом возможности реализовать парсер на базе генератора LALR(1), что сильно связывает руки по сравнению с рукописным вариантом.

2. Естественность чтения

Код должен читаться как предложение на человеческом языке.

Префиксные типы и "лёгкие" блоки

  • Типы объявляются перед именем: String text

  • Фигурные скобки обязательны только для многострочных блоков

Пример на псевдокоде:

int counter = 100
while counter > 0 {
    puts($"{101 - counter}")
}
string text = Input()
If text.contains("б****") puts("Не материтесь!")

Читается почти как обычный текст, сохраняя техническую точность.

3. Читаемость без "шума"

Убираем синтаксический мусор, который не несёт смысловой нагрузки.

Принцип минимализма:

  • Отказ от обязательных разделителей (например, точек с запятой)

  • Чёткие границы конструкций через контекстную грамматику

  • Ошибки отлавливаются уже на этапе парсинга: некорректный код просто не разберётся

Пример на Honey:

int main() {
    :3 string names = ["Alice", "Bob", "Charlie"]
    puts(names:1)  // Выведет "Bob"
    if names:0 == "Alice" puts("Привет, Алиса!")
}

Никаких лишних скобок, точек с запятой или закрывающих тегов.

Итоги

Мы создали синтаксис, где:

  1. Операции занимают на 30-40% меньше символов

  2. Код интуитивно понятен даже новичкам

  3. Грамотно расставленные ограничения предотвращают "мусорный" код

Ключевая мысль: Лаконичность ≠ сложность. Чем меньше "воды" — тем выше плотность смысла.

Синтаксис Honey — радикален, но целенаправлен. Он заточен под конкретные задачи:

  • Минималистичные исходные текста

  • Чёткую структуру данных

  • Быстрое чтение кода

Проект открыт для развития:
Telegram-канал Hexa (ОС HexaOS + язык Honey)

P.S. Статья намеренно короткая — мы ценим ваше время. Примеры кода и документация доступны в репозитории проекта.

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


  1. tsp1000
    21.06.2025 10:18
    #28466212

    послать компилятор куда подальше

    эх, я надеялся, что это будет рофло-статья про использование ассемблера / машинных кодов в продакшене.


    1. vi_is_raven Автор
      21.06.2025 10:18
      #28466216

      я и такую планировал написать) но как-нибудь потом;)


  1. wataru
    21.06.2025 10:18
    #28466220

    Плохая идея. Брейнфак еще лаконичнее, но его не спроста так назвали. Скорость печатанья уж точно не является узким местом. Главное, чтобы код было легко и понятно читать.


    1. vi_is_raven Автор
      21.06.2025 10:18
      #28466226

      попрошу заметить, что там речь не только о краткости, но и о читабельности. читаем мы код всё таки значительно чаще чем пишем.


  1. rsashka
    21.06.2025 10:18
    #28466250

    "Краткость — сестра таланта"

    Если вы думаете, что чем короче - тем лучше, то сократите размер ключевых слов до одного символа, должно стать еще "талантливее" (Brainfuck - идеал краткости и лаконичности).

    Естественность чтения

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

    Код должен читаться как предложение на человеческом языке.

    Синтаксис языка должен передавать алгоритм программы, а не писать на нем "Войну и мир". Кстати, с этой точки зрения, тип переменных правильнее указывать после имени, так как для описания алгоритма имя переменной важнее, чем тип её значения.

    Отказ от обязательных разделителей (например, точек с запятой)

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


    1. vi_is_raven Автор
      21.06.2025 10:18
      #28466264

      Напоминаю, что истина достигается в балансе. Я и не делал прям естественный язык — я сделал более приближенно. Так же, синтаксис не то чтобы кардинально отличается от распространенных среди C-like: по сути, статья — это как раз описание отличий, и, как видно, их не слишком много. То есть, будучи С/++ разработчиком, человеку не будет тяжело изучить синтаксис Honey. Ну и еще раз повторюсь, читаем мы код чаще, чем пишем. Глупую синтаксическую ошибку исправить один раз, а копаться глазами в сотнях бесполезных разделителей придется куда чаще.


    1. vi_is_raven Автор
      21.06.2025 10:18
      #28466268

      И попрошу обратить внимание, в статье я четко написал: "*умеренные* сокращения"


      1. rsashka
        21.06.2025 10:18
        #28466326

        Так может дело вообще не в синтаксисе?


  1. gev
    21.06.2025 10:18
    #28466316

    Все уже давно украдено придумано до нас:

    https://lionet.livejournal.com/124973.html


    1. vi_is_raven Автор
      21.06.2025 10:18
      #28466442

      Ну, перебор =)


      1. gev
        21.06.2025 10:18
        #28466474

        В самый раз!


  1. panzerfaust
    21.06.2025 10:18
    #28466560

    От всех этих "fn вместо fun/func/function" попахивает навязчивой идеей. Кому-то просто хочется свой собственный язык погромирования. Хорошо принимают языки, которые реальные проблемы решают, а не просто слова сокращают.

    Код должен читаться как предложение на человеческом языке.

    На каком из? Что естественно для инглишспикера, то полная хрень для финна, венгра, армянина и поляка. А думают они на родных языках, даже если английским владеют.


  1. pnmv
    21.06.2025 10:18
    #28466572

    :3 string

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

    строка, начинающаяся с двоеточия, это... я даже не знаю, что это. просто, хочется взять и спросить:

    ну зачем?
    ну зачем?

    почему не пойти дальше, и не начать понимать, что, если, после знака равенства, имеется структура, содержащая в себе парные кавычки, то это сразу строки?

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

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


  1. skywarp
    21.06.2025 10:18
    #28466768

    На мой взгляд, это плохая идея сокращать 'function' до 'fn'. Я понимаю ещё 'func' как в Go, но 'fn' это прям такой перебор, может вообще 'f', что уж мелочиться? Автодополнения в редакторах кода и так допишут func, или даже function. Зато читабельнее будет. Вот 'def' у Python, в целом, компромиссный вариант. Три символа, а не два, в плане читабельности воспринимаются лучше.


    1. gev
      21.06.2025 10:18
      #28466798

      Не нужно останавливаться на fn! https://habr.com/en/articles/920544/comments/#comment_28466316


    1. yurrig
      21.06.2025 10:18
      #28467166

      C/++ как-то вообще без function обходится, и ничего