Я написал собственный язык программирования на Node.js — и вот что из этого вышло

[Gippsland]

Язык программирования написал, а на GitHub заливаешь архив 🤔

[SlywerX]

Да, пока так :) В демо-версии сейчас слишком много промежуточных файлов и настроек для ВМ, которые нужно постоянно перекидывать. Чтобы не мучиться с конфликтами путей при каждой итерации в технической части, залил архивом. Это временно, скоро причешу репозиторий и разложу всё по полочкам!

[MasterMentor]

Скачал код, в целом всё ОК! Карма/подписка/статья: +++.

По мелочам,

насколько я понял:

-- границами логических единиц языка (выражение (expression), инструкция (statement)) служат ключевые слова swx sx wx. Явный разделитель ; лучше. На его отсутствии погорели return в JS и корявая поделка от гугла go.

-- sx - определение функции, нужна ли там => чтобы задать её тело или достаточно было скобок {}? ИМХО => и -> это была дань глупой моде в 2010-х и эти обозначения слабо прижились в реальном мире.

[SlywerX]

Спасибо за подробный фидбек и за карму! Рад, что в целом зашло. По вашим замечаниям: 1. Разделители vs ключевые слова (swx/sx/wx вместо ;) Согласен, что ; — проверенный временем подход, и проблемы JS с ASI (Automatic Semicolon Insertion) и Go с принудительной вставкой ; после return — хорошие антипримеры. Но здесь идея была в другом: ключевые слова-границы работают не как "разделитель между инструкциями", а скорее как маркеры контекста — они сообщают парсеру (и читателю), какой тип логического блока начинается/завершается. Это ближе к подходу Lisp (где скобки определяют структуру) или Ruby (where do/end обрамляют блоки), чем к С-подобному ;. Проблема return в JS/Go возникает именно потому, что ; — невидимый разделитель, который компилятор вставляет по своим правилам. Здесь же границы явные и читаемые, поэтому такой класс багов исключён by design. Но замечание принимаю — если язык будет расти, вопрос "а не добавить ли ; как опциональный разделитель внутри блоков" точно встанет. 2. => в определении функций (sx) Тут полностью понимаю скепсис. => действительно стало мемом 2010-х (CoffeeScript → ES6 → Kotlin → Dart...). В моём случае => используется не как "стрелочная функция" в духе JS/Kotlin, а как визуальный разделитель между сигнатурой и телом: sx myFunc(a, b) => { ... } ^сигнатура^ ^тело^ Можно было обойтись просто {}, как в C/Go: sx myFunc(a, b) { ... } Но тогда возникает неоднозначность: { после ) — это начало тела функции или объектный литерал / блок данных? => убирает эту двусмысленность для парсера и для человека. Если коротко: => здесь не дань моде, а disambiguation token. Но если предложите более элегантное решение — с удовольствием рассмотрю, язык ещё в стадии формирования. Ещё раз спасибо за конструктивный разбор! 🙏

[FocusDev]

Интересный опыт. Если честно, не раз задумывался о том, чтобы написать свой язык, но не хватало мотивации довести это до конца. Автору удачи, будем ждать проектов, написанных на этом языке!

[SlywerX]

Спасибо большое! 🙏 Мотивация — это главная проблема. У меня тоже было несколько попыток, которые забрасывал на полпути. Сейчас решил довести до конца хотя бы минимальный рабочий прототип: парсер + интерпретатор + базовый набор библиотек. Если интересно — подписывайтесь, буду выкладывать прогресс. Возможно, вдохновлю вас начать свой проект! 😄 Удачи и вам!