Если честно, я давно планировал написать свой язык. Просто надоело на каждом проекте писать одинаковый бойлерплейт, ловить неожиданные ошибки в рантайме, натыкаться на компоненты аля LoanPreloanInterractNDFL6.2ReportViewComponent - и гадать - что имел ввиду художник...
В итоге получилась Марка — штука, в которой типы живут во время выполнения, ошибки обрабатываются сами, а из REPL можно сразу дергать сервер и смотреть, что приходит на клиенте. Как давно мечтал.
Но раскидав исходники по знакомым, получил неутешительный фидбэк: читать трудно! Встал дурацкий вопрос: как это должно выглядеть в коде, чтобы было удобно? Я набросал 4 варианта синтаксиса — от LISP-стиля до почти Python - нотации. У каждого есть плюсы и минусы, и я уже неделю не могу выбрать.
Т.к. язык русскоязычный, все варинаты сделаны так, чтобы в процессе кодинга не пришлось переключать раскадку. Для некоторых действиет правило:
- `фун(эл1 эл2)` символ без пробела перед скобкой - значит вызов функции
- `(эл1 эл2)` нет символа без пробел перед скобкой - значит список
Поэтому хочу обратиться за помощью к вам: какой вариант был бы реально удобен в ежедневной работе? Не теоретически, а когда надо быстро накидать фичу и не думать о запятых.
Проголосуйте, какой из них самый удобный для написнания и чтения лично вам?
Если заинтересовал проект - уже сейчас доступна playground площадка для экспериментов
http://marka-lang.ru/playground.php
Комментарии (104)
Void-Cowboy
13.08.2026 11:45а чем вас 1С не устраивает с таким подходом?
на нем вроде даже GUI и мультиплатформа есть
pantagruel74 Автор
13.08.2026 11:45Закрытый код, проприетарность, мутации переменных, громозкий синтаксис, нет возможности разрабатывать через REPL
DMGarikk
13.08.2026 11:45громозкий синтаксис
Это у 1Сто который срисовали с бейсика с оглядкой на яву? глядя на ваши скриншоты - это как раз у вас синтаксис еще учить надо и объяснять себе - почему тут именно так, а не как у всех
нет возможности разрабатывать через REPL
а зачем? (странный вопрос, но в принципе)
pantagruel74 Автор
13.08.2026 11:45REPL + тайпчекинг вместе дадут очень-очень быструю обратную связь при разработке. Что здорово бустанет скорость разработки. А если ИИ еще правильно к этому прикрутить - вообще бомба будет. По крайней мере в мечтах :)
qvvah
13.08.2026 11:45По закрытости и проприетарности - есть более свободная реализация, OneScript. И серьёзно, зачем ещё один кириллический ЯП, когда уже есть 1С?
Neyrobute
13.08.2026 11:45Зачем тогда столько разных ЯП на латинице, если уже есть условный Бэйсик?
qvvah
13.08.2026 11:45Латинских ЯП десятки и очень многие из них активно используются в самых разных сферах. Из кириллических ЯП к успеху пришёл только единственный 1С (и в школьном образовании, местами, - Кумир, активно вытесняемый Pascal и Python), думаю преимущественно через монополию в своей сфере. Было бы логичнее именно его и развивать, а не создавать ещё один.
rsashka
13.08.2026 11:45Вы не правильно расставляете акценты.
1C - это торговая сеть, которая разрабатывает программные продуты. И её система 1С бухгалтерия с языком 1С - это реализации вендор лок для данного продукта. Другими словами, пришёл к успеху только один 1С не из-за того, что он такой классный и национальный, а как конкретное решение от монополиста без учета мнения пользователей, удобства синтаксиса или архитектуры решения.
А в текущей статье автор наоборот просит оценить именно синтаксис на предмет удобства использования и его понятности.
qvvah
13.08.2026 11:45Я ровно это и написал: 1С пришёл к успеху из-за своей монополии. Что до синтаксиса, проголосовал за вариант 4: чем меньше скобок - тем лучше читаемость. Сам долго отучался от избыточных
(((( )))), мне казалось что они добавляют "конкретности", уверенности в том что интерпретатор/компилятор поймёт код правильно, но когда их >=3 подряд - это перебор.
DMGarikk
13.08.2026 11:451) Зачем еще один язык? чтобы те кто с ним столкнется - выкинул код на нем написанный и переписал на том что все (и он) знают?
2) Почему русский? мало возможности переменные по русски называть во всех современных ЯП? очередной раз создать мертворожденный продукт который еще дополнительно закопать уходом от латиницы? мало вам хейта 1Сного поделия по этому вопросу?
pantagruel74 Автор
13.08.2026 11:45Потому что существующие решения не подходят под мое идеальное видение, "каким должен быть ЯП чтобы делать большие системы, писать лаконично, малыми силами, надежно и быстро" по нескольким параметрам. Отличная возможость предложить что-то свое. В процессе разработки мобильных телефонов тоже было много чудоковатых вариантов, и один из них всё же выстрелил!
У 1С не русскоязычность главная проблема, на мой взгляд. А возможности писать на русском в популярных ЯП, но сломав что-то важное патчами, дейсвительно нехватает.. ИМХО
DMGarikk
13.08.2026 11:45Потому что существующие решения не подходят под мое идеальное видение, "каким должен быть ЯП чтобы делать большие системы, писать лаконично, малыми силами, надежно и быстро" по нескольким параметрам
это хорошо, но язык с чисто-таким подходом так и останется в виде статьи на хабре и паре ваших проектов
В процессе разработки мобильных телефонов тоже было много чудоковатых вариантов, и один из них всё же выстрелил!
в разработке для мобилок, выстрел произошел по причинам с инструментами совсем не связанным...потому что не программисты решают - будет ли инструмент популярен или нет
А возможности писать на русском в популярных ЯП, но сломав что-то важное патчами, дейсвительно нехватает
то что у популярных ЯП чёто отваливается от UTF кода, я согласен (почему я всегда буду против тех кто пытается на яве-питоне-шарпе-ещегдето по русски писать).
а то что комуто не хватает русскоязычного языка программирования...ну это странно, у меня (да и у многих) искажение конечно профессиональное от привычки писать на английском... но не понятен всёравно какойто глобальный смысл...зачем? что это решит? читаемость? тот кто язык не знает всёравно ничего не поймет, даже если там по русски написано ...все эти (сп: список(эл):сч ).... разбор =(т эл) - понятней чтоли стало от того что тут русский?
а те кто язык знает, то для них и английский не проблема будет
===
кмк чем плодить сотни языков, лучше в опенсорсные решения занести глобальный способ решения проблем с UTF символами и дотолкать до прода... гораааздо было бы полезнее
unclegluk
13.08.2026 11:45Если у вас есть ваше идеальное видение ЯП, то зачем спрашивать чье-то мнение?
StrongerProgrammer7
13.08.2026 11:45Больше похоже на то что есть проблемы с научным и техническим английским , поэтому и создалась цель создать яп свой страны . Хотя мб это выходец из ркн и он что то знает ?...
MasterPoni
13.08.2026 11:45А зачем вообще знания английского для программирования?
Vydra77
13.08.2026 11:45Как минимум сильно проще. Одно дело учить незнакомые абракадабры, совсем другое – использовать слова языка, который знаешь. Например, если бы языки программирования были бы на основе казахского, я бы осуществила мем с девочкой и букварём.
Einherjar
13.08.2026 11:45писать лаконично
С русским в основе это практически невозможно, большинство терминов слишком многобуквенные. Это всегда будет выбор между нечитаемой мешаниной из сокращений или нечитаемой поэмой из не влезающих в экран строк
Кстати, в голосование забыли добавить пункт "ни один"
Lampadov
13.08.2026 11:45Автор является товарищем майором. Все, кто в комментариях высказывается против ЯП на русском, уезжают в отпуск
rsashka
13.08.2026 11:45Кстати, на тему синтаксиса: Если вы думаете, что знаете, чем отличается «Expression» от «Statement», то, скорее всего, вы ошибаетесь
Lucifurry
13.08.2026 11:45Спасибище. Порой полезно заглядывать на проходные статейки на Хабре ради таких годных наводок в комментариях)
lostero
13.08.2026 11:45Создатели ЯПшек, зачем вам доп. символы перед функциями? Сигнатура функции же
ф()|ф(p0:t0 p1:t1)илиф:|ф:p0:t0 p1:t1:и т.п.. Если сигнатуры не пересекаются с другими объявлениями, то зачем специально указывать, что это функция? Для простоты компилятора естьC, для вырвиглазного синтаксиса естьRust, а зачем вот это вот всё? Всегда не мог понять, зачем люди усложняют жизнь другим людям при разработке синтаксиса ЯП? Возьмите стандартную раскладку, попробуйте понабирать спецсимволы и удалите все, что требуют слишком много странных движений (оставшийся набор станет очень мал). Строго типизированный ЯП точно не взлетит, т.к. к удобству набора кода они имеют околонулевое отношение. Большинство типов переменных легко вычисляется на основе использования в коде. Подсветку таких типов и их несоответствие можно убрать в LSP. Т.е. мин. информации и писанины в тексте и макс. информации с LSP.
Ещё, заглавные и строчные во встроенных элементах ЯП - зло. Либо всё одним, либо только строчные.
Всем читающим - не плодите сущности, пожалуйста.DMGarikk
13.08.2026 11:45Строго типизированный ЯП точно не взлетит, т.к. к удобству набора кода они имеют околонулевое отношение
а строгая типизация языков и не для набора кода нужна, а скорее для облегчения работы компилятора и уменьшения рантайм ошибок
Вот Питончик есть, а в любом крупном проекте начинается ... тааак..внедряем mypy...внедряем сериалайзеры... везде начинаем указывать типы где только можно..
хотя по началу "ой как удобно, оно всё само понимает"
lostero
13.08.2026 11:45Так я про то, что объявлять их обычно не нужно. Напр., объявлена функция или переменные с типами. Либо всё соответствуют по вычисленным типам, либо нет. Это LSP и компилятор вычислят и поймают. Зачем программисту это постоянно прописывать?
А писать их везде явно - бред, LSP вам в помощь и не болейте C++ портянками шаблонов.
pantagruel74 Автор
13.08.2026 11:45Согласен со всем вышесказанным. Попробуй без статической типизации проект на 300 таблиц прорефакторить... Чудо если пару дней что-то еще работать будет..
Vladislav_Dudnikov
13.08.2026 11:45Потому что это снижает когнитивную нагрузку. Проблема не в том, что сложно парсить объявление без ключевого слова, а в том, что такой код становится сложнее именно читать. Лично моё мнение по поводу дизайна синтаксиса языков программирования - нужно быть максимально однозначным, даже если это стоит некоторого дополнительного времени на написания. И, как известно, большая часть разработки занимает не написание кода, а его продумывание. "Сложно писать - легко читать".
И ладно с функцией, её довольно просто распознать, но что, например, по поводу переменных и compile-time констант, как их отличать предлагаешь? А ещё становится сложно отличить объявление от присвоения, да есть известные сигилы ":=" и "=", но, опять же, это повышает когнитивную нагрузку и усложняет некоторые реализации, та же volatile-переменная или отложенная инициализация. Ну и это всё усложняет и замедляет парсер. Если язык нацелен на большие кодовые базы, то это становится более критично.
По поводу того, что "есть Си" и "есть Rust" - на них мир клином не сошёлся, создателям Rust тоже можно было сказать в своё время, есть же Cyclone, вы чё. Поскольку производные Си продолжают появляться и получать популярность, значит потребность есть (из относительно известных - Zig, Hare, Nim, Odin).
lostero
13.08.2026 11:45С LSP можно вставлять доп. элементы отображения, о чём я и писал. Набирать меньше, видеть больше.
Сложнее реализация - естественно. Кеширование промежуточных представлений давно придумали для больших проектов. Не нужно перебирать всё каждый раз.
Я про простоту реализации компилятора для синтаксиса C и вырвиглазный синтаксис Rust с его переусложнённым компилятором. Все ЯП имеют опр. цели и из поста мне непонятно, что за объективные цели у данного ЯП раз разработчик волнуется о синтаксисе.pantagruel74 Автор
13.08.2026 11:45У данного языка объективные цели - стать лучшим языком для разработки для интеграторов, инди-хакеров, фуллтеков в РФ. За счет быстрой обратной связи, надежности, возможности быстро получать обратную свзяь и быстро пилить проект.
О синтаксисе волнуюсь - потому что именно на него (вариант 1) многие знакомые обратили внимание, мол - неудобно читать. Решил обратиться к сообществу, посмотреть какие варианты понравятся больше.
1024rk
13.08.2026 11:45Если у проекта объективные цели - недостижимые, то заниматься им нет смысла.
Даже с человеческим (английским) синтаксисом задача "сделать лучший язык для нескольких разных сфер" невыполнима просто потому что потому. У вас же пет-проект, которым в пике будут пользоваться три с половиной человека, включая кошку автора, которая случайно влезла в IDE. Ещё и с неисправимым недостатком в виде языка с падежами в основе. Поэтому и относиться к проекту стоит соответствующе. Если хочется поковыряться в том, как работают языки, что-то для себя понять - в принципе можно, но чтобы потом не расстраиваться, лучше заранее снизьте ожидания.
Vladislav_Dudnikov
13.08.2026 11:45А к этой LSP ещё нужно приложить годную IDE, которая будет все рендерить. Я как любитель "сырого редактирования" такое не очень люблю. Ну и для нового языка с очень маленьким комьюнити это неподъёмная задача.
Ну так или иначе, я описал своё видение для чего все эти ключевые слова, не настаиваю.
rsashka
13.08.2026 11:45Как по мне, то когнитивную нагрузку значительно повышает не строгие правила, а контекстно зависимая грамматика, которая подобные правила нарушает
pantagruel74 Автор
13.08.2026 11:45Полностью согласен. но согласиси, в голосовании lisp - не в топе.. Да и парсинг ускорить иногда - надо. Поэтому надо искать какой-то компромисс...
rsashka
13.08.2026 11:45Строго типизированный ЯП точно не взлетит, т.к. к удобству набора кода они имеют околонулевое отношение. Большинство типов переменных легко вычисляется на основе использования в коде. Подсветку таких типов и их несоответствие можно убрать в LSP. Т.е. мин. информации и писанины в тексте и макс. информации с LSP.
Типизация языка не имеет отношения к удобству набора кода или к подстветке синтаксиса. Это никак не связанные между собой понятия.
anonymous
13.08.2026 11:45pantagruel74 Автор
13.08.2026 11:45Благодарю! Согласен со многим вышесказанным.
Разгрузить от пустых скобок пока по задумке невозможно, - потому что все типы в этом языке по умолчанию являются generic. Просто иногда generic без парметров, отсуда и пустые скобки. А у того-же выражения без скобок - совсем другая семантика задумана.
А знаки вопроса - это булевы да/нет
rSedoy
13.08.2026 11:45Устойчивый запах ответа от LLM и ТС даже ведется на такое.
pantagruel74 Автор
13.08.2026 11:45Ну ЛЛМ-ка - ЛЛМ-кой, а вывод - не худший, из всех прозвучавших выше..
bestuzheff
13.08.2026 11:45А правда для его еще один язык? Просто попробовать свои силы?
Если просто нравится писать на русском есть 1С Предприятие Элемент
А если еще хочется и опенсорс то есть https://oscript.io/
Timures
13.08.2026 11:45Интересно а Северной Корее тоже свой язык программирования?
Как будто готовитесь к чему то нехорошему
nin-jin
13.08.2026 11:45Лучше формат Tree использовать. Например:
Операторов всего несколько:
!- объявить имя для некоторого вычисления с опциональными параметрами.=- вычислить результат по имени с передачей именованных или позиционных аргументов.?- объявить параметр с именем и опциональным типом.:- объявить тип параметра.
nikolay-ermolenko
13.08.2026 11:45Сложно представить, чтобы врачи в терминах переходили с латыни на русский. Представляете, как потом на симпозиумах общаться?
Druzd
13.08.2026 11:45Один только хейт. Автор лисапед изобретаем в свои юные годы, а все фТопку. Занимайся автор своим пер проектом, набьешь шишек. После будет озарение - где тут кнопку удалить все? Зато сколько опыта!!! Да прибудет с тобой сила, юный джедай!
fire64
13.08.2026 11:45Автор, без обид, но ваш код мне как русскоязычному пользователю сильно тяжело читать.
Почему в 1С я читаю русский код и он адекватный или когда читаю C, C#, C++ там тоже понятно, но вот ваш код тяжело читать.
Procher
13.08.2026 11:45Выражу своё субъективное мнение, за которое вероятно могут как закидать какашками, так и вознести в лик святых:
Либо первый либо четвёртый варианты, НО скобочки используй «по стандарту» как во всех ЯП. Тело функции или выражения - фигурные скобки, массив - квадратные, остальная ерунда - круглые
Rerium
13.08.2026 11:45Попробуй посмотреть на си-подобный синтаксис или как у java. Все варианты довольно не читабельные...
А так, не слушай тех кто пишет "зачем ещё один яп?", ну будет ещё один язык, за то разберёшься в языках программирования и компиляторах
pintor
13.08.2026 11:45Т.к. язык русскоязычный, все варинаты сделаны так, чтобы в процессе кодинга не пришлось переключать раскадку.
Русская раскладка - беда для программирования. В целом, синтаксисы доволно устоявшаяся штука. И, мне вот кажется, что начинать нужно с раскладки клавиатуры заточенной для ЯП, иначе придется вот так как вы изголяться с синтаксисом, и он в любом случае будет получаться
вырвиглазнымкомпромисным.
randomsimplenumber
13.08.2026 11:45Еще и специальную раскладку учить..
Ndochp
13.08.2026 11:45А что ее учить? Ставим английские спецсимволы на правый альт, исключения -
1, 9, 0- единица за то что рядом с тильдой и у нее одинаковый восклицательный знак в рус/лат, 9 и 0 - за то, что тоже скобки. (ну и в рус/лате совпадают)ё 1 2 3 4 6 7 9 0 х ъ \ б ю ` ~ @ # $ ^ & { } [ ] | < >по вкусу добавить
NULL Json XDTO XML HTMLна буквы.(а, я понял, вам раскладка нужна на ключевые слова конкретного языка и стандартную библиотеку? моя заточена на 1С/русскоязычный ЯП в котором все равно нужны спецсимволы широкого набора)
Grey6000
13.08.2026 11:45В плане синтаксиса следует обратить внимание на https://github.com/tsoding/good_training_language не смотря на то что это 1 апрельская шутка, автор проделал серьезную работу в плане синтаксиса яп на русском языке, так чтобы минимизировать переключение раскладки
aamonster
13.08.2026 11:45Начните с определения целевой аудитории. Обычным программистам ЯП с русским синтаксисом определённо не нужен, так что опрос, скорей всего, следовало проводить не тут, а там, где могут быть потенциальные пользователи.
taliano
13.08.2026 11:45быстро накидать фичу и не думать о запятых
Покушение на святое.
; в конце строки это вообще лучшая часть работы.
randomsimplenumber
13.08.2026 11:45быстро накидать фичу и не думать о запятых
Казнить нельзя помиловать
enterаминь.
Artzver
13.08.2026 11:45Здарова. Не особо шарю за языки программирования. Помню только C++ с универа че-то как-то. Но, короче, мне больше понравился 4 вариант. Чище для глаза, удобнее читать, меньше всяких скобок и прочего.
tenzink
13.08.2026 11:45Поскольку критериев выбора синтаксиса у вас всё равно нет, то рекомендую посмотреть ещё в одну сторону. Самый красивый синтаксис который я видел, это в семействе ML-языков (Ocaml, Standard ML of New Jersey) или на худой конец в Haskell
pantagruel74 Автор
13.08.2026 11:45Согласен! Но проблема в ML-like и в C-like синтаксисе, что для программирования на русском, придется раскладку на каждом стейтменте пререключать.. Поэтому улыбаемся и импровизируем :)
Ndochp
13.08.2026 11:45Править ее надо, а не переключать. В типовой раскладке на слое AltGR в русском символа 3 всего кажется. Рубль, копирайт и кажется что-то еще.
tenzink
13.08.2026 11:45Русский язык - отдельное спорное решение.
Начнём с "эффекта зловещей долины". Код типа такого `список сложить(один, два, три)` лично у меня вызывает только брезгливость. Если это русский, то пусть будет хотя бы `сложи список (...)`. Иначе это воспринимается как безграмотность и издевательство над русским языком.
С практической точки зрения кодировать неудобно. Вероятней всего не избежать частого переключения раскладок.
И тут уже кто-то приводил аргумент, что язык математики не локализуют (синус, интеграл, и т.п.). Мне симпатична такая аналогия
tenzink
13.08.2026 11:45Чисто по фану, чтобы чуть меньше тошнило от коверканья русского языка
; Даны два массива целых чисел произвольной длины.\ ; Найди их пересечение с учётом повторяющихся элементов.\ ; Порядок элементов в результате не важен.\ ; ; Первый массив: [1, 2, 3, 2, 0, 2] ; Второй массив: [5, 1, 2, 7, 3, 2] ; Результат: [1, 2, 2, 3] подключи список подключи математику функция возьми_первый_массив(): список[целых] = ( (1 2 3 2 0 2) ) функция возьми_второй_массив(): список[целых] = ( (5 1 2 7 3 2) ) функция выполни(): список[целых] = ( функция найди_общие_значения(): список[целых] = ( верни ( возьми_первый_массив() |> список.оставь_без_повторов() |> список.пересеки_с( возьми_второй_массив() |> список.оставь_без_повторов() ) ) ) функция посчитай_вхождения( значения: целое в_массиве: список[целых] ): целое = ( верни ( в_массиве |> список.оставь( функция проверь( элемент: целое по_индексу: целое ): логическое = ( элемент = значения ) ) |> список.посчитай() ) ) функция сопоставь_значения_с_кратностью(): список[пар[целых]] = ( верни ( найди_общие_значения() |> список.преобразуй( функция сопоставь( значение: целое по_индексу: целое ): пара[целых] = ( ( значение математика.выбери_меньшее( посчитай_вхождения( значения: значение в_массиве: возьми_первый_массив() ) посчитай_вхождения( значения: значение в_массиве: возьми_второй_массив() ) ) ) ) ) ) ) верни ( сопоставь_значения_с_кратностью() |> список.сверни( функция добавь( в_результат: список[целых] значение_с_кратностью: пара[целых] по_индексу: целое ): список[целых] = ( функция повтори_значение(): список[целых] = ( верни список.повтори( значение: значение_с_кратностью[0] раз: значение_с_кратностью[1] ) ) верни список.соедини( в_результат с: повтори_значение() ) ) начиная_с: () ) ) ) выполни()
alcanoid
13.08.2026 11:45А как это всё уберегает вас от написания надоевшего «одинакового бойлерплейта»? Или вы вместо него теперь пишете одинаковые сковородки?
pantagruel74 Автор
13.08.2026 11:45Синтаксис - никак. Другие особенности языка - очень даже помогают.
nickmanecannotbeempty
13.08.2026 11:45Сообщество требует падежей!!! Любой славянский язык без падежей — это дурной тон и попрание святыни. А тем более, русский!!!
dmchmk
13.08.2026 11:45Поэтому хочу обратиться за помощью к вам: какой вариант был бы реально удобен в ежедневной работе?
Создавать не новый язык, а кириллическую версию какого-то уже имеющегося + транслятор в обе стороны.
Ну потому что если хочется именно русский, то, имхо, стоит именно русификацией и заняться) а языковую внутрянку отдать на откуп тем, кому она интереснее)
NeoCode2
13.08.2026 11:45Не позорьтесь, сделайте нормальный синтаксис на английском. Вообще не понимаю как русский текст воспринимать в качестве языка программирования. Вы же в математике пишете sin(x) а не синус(ы). Ну и в программировании то же самое. if, else, while, for и т.д. уже стандарт де-факто, они воспринимаются не как английские слова, а именно как абстракции вне какого-либо языка.
А вообще я даже в Visual Studio отключаю всякую русификацию, ибо в голове начинается какая-то путаница, когда пытаешься сопоставить привычные уже до автоматизма английские пункты меню с их русскими переводами. А еще есть сообщения об ошибках...
dmchmk
13.08.2026 11:45Не позорьтесь, сделайте нормальный синтаксис на английском.
да нет в этом ничего позорного, нормальный мысленный эксперимент
YuryZakharov
13.08.2026 11:45Так и не увидел, какую именно проблему решает русский язык в синтаксисе.
Читаемости он не добавляет, парсинг не облегчает, целевую аудиторию не расширяет.
@pantagruel74 , можете ответить?
Ndochp
13.08.2026 11:45Он добавляет читабельности если бизнес область для которой вы пишете имеет терминологию, не входящую в базовый технический английский. Так как юникодные кирилические переменные позволяет любой язык, но
if (НДСКВозмещению > 0){не читабельно на мой взглядYuryZakharov
13.08.2026 11:45не входящую в базовый технический английский
Хороший эвфемизм для "я не знаю этих терминов".
А каково соотношение терминов из предметной области к служебным? Как часто нужно будет писать "если" вместо "if"?
К тому же, терминологию предметной области в любом случае нужно будет изучать, так что это не ответ.
Ndochp
13.08.2026 11:45Так если заказчик русский, то терминологию проекта ты худо бедно изучишь, а перевод на английский - нет. И поэтому, чтобы термины в коде были похожи на термины в ТЗ и понадобятся в коде НДСКВозмещению.
Так как иначе будет все скакать между VAT и NDS.
ИНН и СНИЛС как например в английский переводить? Транслитом, разложить, перевести каждое слово а потом собрать в аббревиатуру, найти максимально похожий код в англоговорящей стране и использовать его? А если он в США и Англии отличается?YuryZakharov
13.08.2026 11:45Резонно. Но ограничивает разработчика одним единственным рынком.
То есть, обязательность русского языка на уровне синтаксиса сужает целевую аудиторию. Думаете, именно эту цель стаит автор?
Безотносительно темы разговора,
А если он в США и Англии отличается?
Он-таки отличается. И лечится это введением более общего термина, в который попадают оба варианта. Как сделано во всяких SWIFT, FIX и прочих.
Ndochp
13.08.2026 11:45Если мы не пишем решение для мира, а занимаемся инхаус разработкой в конкретной (пусть большой) организации, то гораздо проще не вводить более общие термины, включая переводчика в состав команды проекта, а писать код в терминах технического задания, с которым к вам пришел профильный эксперт. (на русском языке)
YuryZakharov
13.08.2026 11:45Вы лично планируете всю жизнь работать в этой организации?
Я же говорю, что вижу здравое зерно в Выших доводах, но в то же время считаю, что русификация ЯП очень сильно сужает аудиторию.
Стоит ли оно того - не знаю, поэтому и вопросы задаю, интересно...
pantagruel74 Автор
13.08.2026 11:45Мне казалось что именно для внутренней ЦА может добавить ценности. А по поводу читаемости - рано делать выводы пока не перепробуем все способы имхо..
Ну и важно, что глубокие доменнные и технические термины на русском писать и читать может оказаться гораздо проще, чем их творческий английский перевод от последнего программиста с проекта..
alekssan818
13.08.2026 11:45Сам пишу на Python, и сначала по привычке потянулся к 4-му варианту. Но потом подумал: если делать новый язык, зачем копировать то, что уже есть? Третий вариант видится идеальным балансом — он не пытается казаться Пайтоном, но при этом понятен и приятен для глаз.
А вот во 2-м варианте использовать знак процента
%для типов — спорная идея. Представьте задачу, где нужно посчитать реальный процент от продаж. В коде начнется путаница: один знак%означает тип данных, второй — математическую операцию. На больших проектах (от 5000 строк) это превратится в кашу, поэтому явные слова из 3-го варианта намного надежнее.Кстати, вопрос к автору: а ты не запускал бенчмарки на производительность? Как проект по скорости на одинаковых задачках по сравнению с другими языками, сравнивал?
pantagruel74 Автор
13.08.2026 11:45Ну, т.к. на текущем этапе язык на JS хостится - врядли похвастается рекордами. А вообще, т.к. язык простой и многие вещи заоптимизировать можно, думаю до уровня LuaJIT вполне возможно будет довести
Bedal
13.08.2026 11:45Никогда не будет хорошо, русский язык - синтетический, не годится для ЯП, там годятся только аналитические языки. Впрочем, и там COBOL не выжил, даже ALGOL не выжил. Сишный синтаксис потому и стал стандартом, что практически бессловесный. То, что всё же выросло в плюсах, жавах и прочих шарпах, не случайно ощущается уродством.
Emulyator
13.08.2026 11:45Но если взять какой-нибудь приятный язык типа Котлин и +- дословно перевести ключевые слова, воруя у 1с примеры удачного перевода и не трогая прочие символы и языковые конструкции, то, ИМХО, получится в разы лучше.
pantagruel74 Автор
13.08.2026 11:45из-за спецсимволов раскрадку придется переключать постоянно..
Emulyator
13.08.2026 11:45Ну это одна из главных причин почему русский не очень для программирования, если, например, не хочешь писать "больше" "меньше" вместо "<" ">". Как в вашем языке реализован оператор сравнения?
1024rk
13.08.2026 11:45Удобнее читать на английском. Не пиши русскоязычный яп.
Это очень. Плохая. Идея. Всегда.
AlexAiZzz
13.08.2026 11:45Если разрабатывается свой язык, то самый первый тест проверить синтаксис это написать на нем же собственный интерпретатор/компилятор.
AlexAiZzz
13.08.2026 11:45Если в тексте пишется что у всех четырех вариантов есть свои плюсы и минусы, то было бы неплохо их и описать, чтобы понять всю их серьезность.
Alsig
13.08.2026 11:45Диполь после привычки очень удобен был. Но на уровне оператора ЭВМ, а не программного инженера.
Stanislav_Z
13.08.2026 11:45Если цель нового ЯП - не переключать язык, то с английским так или иначе придётся работать. Внешние сервисы на английском же.
rsashka
Еще немного сталось :-)