Зачем делать новый язык программирования?

Копия статьи с Хабра от 31.01.2024

Когда в публичном пространстве появляется информация о новом языке программирования, поднимается волна неприятия. Негатива столько, что хоть святых выноси!

Причин у этого явления много и, скорее всего, сделать с ним ничего нельзя, такова уж человеческая природа.

Однако можно подойти к вопросу рационально, и все-таки попробовать поискать ответ на вопрос, а зачем, собственно, создавать новый язык программирования?

Попробуем разобрать мотивы, подвигающие людей на такую работу.

Личный творческий порыв

Зачем люди пишут статьи (включая эту), картины, идут в горы, спускаются на дно океана, вышивают крестиком, вяжут рыболовные сети и режут из дерева?

Зачем вообще люди занимаются творчеством?

Этим вопросом занимаются разные науки, для многих людей творчество — это экзистенциальный опыт, кто-то «не может не творить». Сам по себе ответ на вопрос «зачем люди творят» выходит далеко за рамки статьи о создании языков программирования.

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

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

Сам факт того, что компьютеру можно что-то «объяснить», написав код и запустив его, завораживает и потрясает воображение. А уж возможность управлять этим процессом в самом глубинном значении этого слова вызывает внутренний восторг и благоговение.

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

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

Академический интерес

Очень близко к творчеству стоит научная деятельность. Нередко языки программирования создаются для проверки или реализации той или иной концепции.

Так, язык Brainfuck вырос из попытки создать Тьюринг-полный язык программирования, для которого можно создать минимально возможный компилятор. Первая версия компилятора для Amiga OS 2.0 занимала 240 байт, позднее размер удалось сократить и он стал занимать менее 200 байт.

Языки Agda, Coq, Idris разработаны для проведения исследований в области спецификаций и доказательств.

Многие исследовательские проекты, изначально написанные, скажем, на Haskell или OCaml, нередко перерастают в самостоятельные языки.

В хабе Ненормальное программирование немало статей как раз про языки такого рода.

Поддержка предметной области

Перейдем к более приземленным материям.

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

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

В России таким примером служит язык 1С, разработанный для автоматизации задач бухгалтерского учета. Другие примеры подобного рода — AutoLISP для CAD, Asymptote для подготовки математических иллюстраций, G-Code для управления станками с ЧПУ и т.д.

Такие языки принято называть DSL (domain specific language) или по-русски — предметно-ориентированный язык.

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

Предоставление интерфейса к набору библиотек

При разработке большой программной библиотеки может возникнуть ситуация, когда сама по себе библиотека становится «предметной областью». Тогда можно создать язык программирования, построенный поверх этой библиотеки. Пример такого подхода — язык QMLиз библиотеки QT. И, хотя сам язык разрабатывался как средство разработки интерфейсов пользователя, построенный поверх QT, фактически из него можно вызывать почти всё (если не строго всё) содержимое библиотеки, в свою очередь написанной на C++.

Есть и другие примеры такого подхода. Так, к таким языкам можно отнести JavaScript, хотя он заметно шире, чем представлено в настоящем параграфе. Похожими свойствами обладает язык TISript из проекта Sciter (позже, впрочем, замененный на JavaScript).

Благодаря легкости встраивания и легкости синтаксиса, свойство «быть надстройкой над библиотекой» появляется при встраивании языка Lua или ECL (Embeddable Common Lisp) внутрь более крупного проекта.

Причины коммерческого характера

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

Microsoft пыталась договориться с Sun Microsystem (разработчиком Java) о разных аспектах использования языка, в том числе в рекламных материалах, но в какие-то моменты стороны шли в суд, поскольку не удавалось прийти к соглашению.

В том числе, для того, чтобы не зависеть от других компаний в своем бизнесе, компания Microsoft начала разработку языка C#. Больше того, оба этих языка в начале своего пути были схожими концептуально, но позже значительно разошлись.

Безопасность

Если посмотреть на индексы TIOBE и PYPL, то окажется, что в обоих индексах языки из первой десятки прямо или косвенно (через спонсорство) контролируются американцами и европейцами. В текущих реалиях неплохо бы задуматься, каким инструментарием приходится пользоваться в нашей стране.

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

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

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

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

Производительность

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

К таким областям, на мой взгляд, стоит отнести математические вычисления (в просторечии «числодробилки»). В этой среде есть несколько значимых языков, но особо хочу выделить язык Julia.

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

Укрупнение или сужение семантики

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

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

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

Так, например, код с языка высокого уровня может переводиться в ассемблер или, что бывает значительно чаще, в форму LLVM IR.

Бывают и примеры обратного преобразования, когда код из более низкоуровневого представления преобразуется в более высокоуровневое.

Имиджевые причины

Разработка языка — это долго и дорого. Если вместе с языком разрабатывать ещё и компилятор, это ещё дольше и ещё дороже. (Если предыдущая фраза показалась вам странной, то да, разработка языка и разработка компилятора к нему — разные процессы). Позволить себе такое могут либо совсем упертые профессионалы, либо организации, способные оценить потенциальные выгоды от такой разработки и вложить несколько человеколет в разработку.

Зачем я все это пишу?

Я сам уже почти 10 лет профессионально занимаюсь созданием языков программирования и компиляторов, меня лично трудно смутить негативом по отношению к плодам своего труда.

Мне хочется, чтобы читатель, при виде очередного языка, «непонятно зачем созданного, то же самое можно сделать на языке Х» вспомнил, что у такой работы и такой публикации есть вполне рациональные мотивы. Ведь есть множество причин, способных побуждать к изготовлению языка.

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

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

Да, международное сотрудничество идет, пусть и в виде приема патчей в репозитории. Пока идет. Важно не упустить момент, когда станет поздно и окажется, что «станки для программистов» делать и некому, и незачем.

Импортозамещение, каким бы казенным ни было это слово, важно делать и тут. Логичным развитием ситуации с языками и компиляторами в стране считаю дополнение нормативной базы о реестре отечественного ПО таким образом, чтобы компаниям было выгодно разрабатывать софт с помощью инструментария, сделанного в России.

P.S. На КДПВ святой Георгий Победоносец, по преданию победивший дракона.

P.P.S. Если вы знаете какую-то компанию или людей, делающих языки, компиляторы и другой подобный инструментарий в нашей стране, упомяните их в комментариях. Страна должна знать своих героев!