1 (изменено: Freeman, 04.08.2023 в 22:41)

Тема: Как придумать язык программирования?

Чисто публицистическая тема, изначально размещеная в корзине во избежание...

Черт возьми, имею же я право на собственном ресурсе хотя бы иногда публиковать непроверенные и спорные мысли!

Тема с compiler.su:

На сегодняшний день существуют тысячи языков программирования. Но ещё ни один автор языка не объяснил, почему это сделано именно так, и не доказал, что это наилучшее решение. Никлаус Вирт, один из самых «плодовитых» языкописателей, профессор, автор многих книг, не посчитал нужным комментировать процесс изобретения своих языков. Что же говорить об остальных, которые придумали один единственный язык программирования? Восполняя этот пробел, будем стараться комментировать ход своих мыслей, аргументировать свои предложения.

Создание языка начинается не с описания грамматики. Должны родиться какие-то идеи, потом они должны пройти, как минимум, проверку на непротиворечивость концепций. Затем должны выкристаллизоваться основные идеи как синтаксиса, так и семантики языка. И лишь потом — формальное описание.

Мой ответ — типа абстрагированный опыт разработки Кантора, дано кликбейтное название.

  • Придумывание языка — социальный процесс.

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

  • В языке должно быть критическое число нововведений.

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

  • Признание есть заимствование.

Придумывание языка — социальный процесс: «как пасти котов, расширенная версия». Коты дикие, сначала их нужно приручить. Чтобы приручить дикого кота, нужно смотреть на мир глазами дикого кота. Смотрите на свой язык глазами потенциального программиста. Кого вы видите в роли пишущего на вашем языке? От чего он страдает? Не делайте необоснованных предположений, общайтесь с потенциальными пользователями языка прямо или косвенно. Исходите из того, что ваш взгляд как автора языка программирования уже искажен, и ради понимания задач нужно общаться с теми, кто их решает. Общайтесь, даже если вы раньше сами решали такие же или похожие задачи — ваш способ решения мог быть характерен только для вас или вашей команды, а теперь он еще искажен мыслями о языке.

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

Возможна ошибка выжившего в моем исполнении

Сам-то я весьма критично относился к сторонним мнениям, хотя годные идеи творчески перерабатывал, вплетая в канву проекта.

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

Если же вы в том или ином виде задумываетесь об использовании существующего кода вместо написания нового, это означает одно из двух:

  • Вы сами не верите в свой язык. Еще раз подумайте, пересмотрите жизненные приоритеты, скорректируйте цели.

  • Вы разрабатываете не язык, а метасистему или платформу, типа LLVM, Haxe или Кантора. В этом случае основные нововведения должны быть привязаны к платформе, а не к языку. Язык будет лишь воплощением платформы — полным, частичным или одним из многих, — в зависимости от выбранных вами целей.

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

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

Мечты, мечты...

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

Никто не любит, когда старые вещи называют новыми именами, не меняя сути. В среде программистов такой подход считается маркетинговым и не приветствуется. А вот наоборот — очень даже можно и нужно: смело называйте новые вещи старыми именами, попутно разъясняя смысл различий. Новые термины нужны лишь тогда, когда вы придумали нечто принципиально новое и готовы нести ответственность за свои теории, будучи поначалу обвиненным в маркетинге. Да-да, обвинение в маркетинге неизбежно, даже если вы гений и придумали нечто совершенно передовое и сногсшибательное. Отсутствие негатива со стороны — повод задуматься, не настолько ли очевидна ничтожность ваших идей, что не вызывает даже желания потроллить. Реальность жестока, увы.

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

Примеры притянуты за уши

Пример Оберона: расширение понятий типа на ООП без внедрения понятия объекта в Оберонах получило признание и заимствовано некоторыми языками, среди которых самый популярный — Питон.

Пример Эйфеля: обозначение привычных понятий ООП новыми словами в Эйфеле не получило признания, и, концепция свойств, будучи заимствована в Delphi и C#, была обозначена привычными для программистов ключевыми словами и стала стандартом де-факто.

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

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

Краткая история Кантора от 7 марта 2016 года

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

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

У меня в коде начало́ что-то получаться лишь тогда, когда я перестал относиться к нему как «вот сейчас сяду и одной левой всё напишу», а настроился на длительную кропотливую работу. Поначалу казалось, что только и буду выбрасывать написанное, но постепенно концы сошлись...

...На раннем этапе, еще даже до названия «Оно», я слушал разных советчиков и метался из стороны в сторону. Сначала думал писать на .NET/C#, потом на Обероне. Познакомившись и с тем, и с другим, понял, что они отнюдь не являются серебряной пулей, требуют долговременного изучения, а в случае Оберона — еще и поиска годных инструментов. Пришел к пониманию, что нельзя писать сложный концептуальный проект и одновременно изучать язык, на котором пишешь. Альтернатив Delphi не осталось, но решение писать на Delphi потребовало определенного мужества, хотя казалось бы...

Примерно в то время я узнал про проект Максима Кизуба — идеи его JADE перекликались с моими. Он написал всё на Java. Решение писать интерпретатор или прослойку на другом интерпретаторе мне показалось странным. Для меня это был одновременно и положительный, и отрицательный пример: человек написал на том, что знает — оно работает, но тормозит™.

После решения писать на Delphi горизонт принятия технических решений резко сузился — нужно было лишь определиться, до какого уровня опускаться.

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

Пробовал с KOL, но с ней не задалось. KOL я пробовал несколько раз — до и после этого, ибо это единственная альтернативная библиотека под Delphi, но каждый раз натыкался на непонятные баги и начинал сомневаться в качестве ее кода. На современном этапе, уже имея кое-какие свои наработки, качество кода KOL нашел для себя неприемлемым. На вопрос: «Готов ли я поддерживать проект на KOL?» — ответил отрицательно. Теперь тема KOL для меня окончательно закрыта. Подозреваю, что именно качество кода не дало ей возможность взлететь.

В конце концов всё решили строки. У меня было два, даже три требования:

  • Разработка на Delphi 6/7, чтобы была возможность использовать облегченный модуль System — отрываться с хакерскими штучками и держать в уме «Колибри».

  • Юникод. Под Delphi 6/7 его поддержку надо писать вручную.

  • Строки как объекты, вписанные в общую объектную модель библиотеки, чтобы не приходилось городить отдельные контейнеры для строк и остальных объектов (у меня же полный ООП). Попутно, раз уж строки будут писаться вручную, это должны быть «компиляторные строки» — то есть умеющие разделять общий буфер, когда срез строки создается без копирования данных.

На поиск нужного API у меня ушло 3-4 года. Первые коммиты в SVN датированы вроде 2007 годом, но я прерывался на 2 года на разработку вики, которая писалась на PHP и в итоге ничего не дала для развития проекта в коде.

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

Дополнительные пункты:

  • Простых задач в ИТ не осталось. Для успеха разработки нужно придумать, каким образом вписывать в архитектуру языка вновь выявляемые сложности (по аналогии со вновь выявляемыми объектами культурного наследия). Без этого принципа язык не выживет, оставшись маргинальным и неспособным решить сколь-нибудь серьезные практические задачи.

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

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

    • Обучение программированию будущих программистов в качестве первого языка программирования.

    • Упрощение разработки средств малой автоматизации в терминах прикладной области — условных формул в Excel и прочих одноразовых/нетиражируемых решений — непрограммистами или недоучившимися прикладными программистами, при тесном взаимодействии с заказчиком в условиях постоянно меняющейся постановки задачи.

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

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