Тема: Как придумать язык программирования?
Тема с compiler.su:
На сегодняшний день существуют тысячи языков программирования. Но ещё ни один автор языка не объяснил, почему это сделано именно так, и не доказал, что это наилучшее решение. Никлаус Вирт, один из самых «плодовитых» языкописателей, профессор, автор многих книг, не посчитал нужным комментировать процесс изобретения своих языков. Что же говорить об остальных, которые придумали один единственный язык программирования? Восполняя этот пробел, будем стараться комментировать ход своих мыслей, аргументировать свои предложения.
Создание языка начинается не с описания грамматики. Должны родиться какие-то идеи, потом они должны пройти, как минимум, проверку на непротиворечивость концепций. Затем должны выкристаллизоваться основные идеи как синтаксиса, так и семантики языка. И лишь потом — формальное описание.
Мой ответ — типа абстрагированный опыт разработки Кантора, дано кликбейтное название.
Придумывание языка — социальный процесс.
Язык придумывается для того, чтобы программисты заново написали на нем программы.
В языке должно быть критическое число нововведений.
Новые понятия должны обозначаться привычными словами.
Признание есть заимствование.
Придумывание языка — социальный процесс: «как пасти котов, расширенная версия». Коты дикие, сначала их нужно приручить. Чтобы приручить дикого кота, нужно смотреть на мир глазами дикого кота. Смотрите на свой язык глазами потенциального программиста. Кого вы видите в роли пишущего на вашем языке? От чего он страдает? Не делайте необоснованных предположений, общайтесь с потенциальными пользователями языка прямо или косвенно. Исходите из того, что ваш взгляд как автора языка программирования уже искажен, и ради понимания задач нужно общаться с теми, кто их решает. Общайтесь, даже если вы раньше сами решали такие же или похожие задачи — ваш способ решения мог быть характерен только для вас или вашей команды, а теперь он еще искажен мыслями о языке.
Не подменяйте собой экспертное мнение. Став разработчиком языка, вы перешли в сугубо технологическую область, а по прикладным вопросам теперь должны слушать сторонних экспертов. Эксперты должны быть независимы, чтобы высказывать собственное мнение — это не должны быть ваши подчиненные или родственники.
Языки программирования придумываются, чтобы на них программировали, то есть писали программы. Для автора языка программирования это означает, что программы на новом языке должны быть написаны заново. Всегда нужно помнить об этом и самому быть готовым заново написать любую программу из числа тех, для разработки которых предназначается ваш язык. Игру? Бухгалтерскую программу? Браузер? Операционную систему? Другой язык программирования, наконец?
Если же вы в том или ином виде задумываетесь об использовании существующего кода вместо написания нового, это означает одно из двух:
Вы сами не верите в свой язык. Еще раз подумайте, пересмотрите жизненные приоритеты, скорректируйте цели.
Вы разрабатываете не язык, а метасистему или платформу, типа LLVM, Haxe или Кантора. В этом случае основные нововведения должны быть привязаны к платформе, а не к языку. Язык будет лишь воплощением платформы — полным, частичным или одним из многих, — в зависимости от выбранных вами целей.
Нельзя придумать язык, копируя или комбинируя решения других языков и не придумывая своих. Это понимают все разработчики. При этом многие обычно упускают факт, что вы не можете заранее знать, какая из фишек языка выстрелит, расшив узкое место в той нише, на которую вы нацелились. Поэтому нельзя концентрироваться на одном-двух нововведениях, наивно полагая, что только они и будут востребованы. Единственный работающий способ избежать провала и безвестности — внести столько нововведений, сколько получится, не боясь потери совместимости и слома привычек программистов. Разработчик языка программирования — всегда технологический лидер. Чтобы вести людей за собой — нужно мыслить как лидер.
Посмотрите на задачу освоения языка с нуля глазами программиста: ведь это вызов его квалификации и хакерскому началу, сидящему внутри каждого программиста. Первыми программистами на вашем языке станут энтузиасты. Сделайте так, чтобы им было интересно изучать новое и приятно переписывать на новый лад старое — избавляясь от багов, грязи и неудовлетворенности кодом. Энтузиасты привлекут менее мотивированных, и со временем вокруг вашего языка сформируется сообщество пишуших. У здорового языка должно быть здоровое сообщество.
Никто не любит, когда старые вещи называют новыми именами, не меняя сути. В среде программистов такой подход считается маркетинговым и не приветствуется. А вот наоборот — очень даже можно и нужно: смело называйте новые вещи старыми именами, попутно разъясняя смысл различий. Новые термины нужны лишь тогда, когда вы придумали нечто принципиально новое и готовы нести ответственность за свои теории, будучи поначалу обвиненным в маркетинге. Да-да, обвинение в маркетинге неизбежно, даже если вы гений и придумали нечто совершенно передовое и сногсшибательное. Отсутствие негатива со стороны — повод задуматься, не настолько ли очевидна ничтожность ваших идей, что не вызывает даже желания потроллить. Реальность жестока, увы.
Желтая майка лидера означает, что теперь всегда найдутся те, кто будет против вас. Нельзя бы хорошим для всех. Ваша задача как лидера — собрать тех, кто на вашей стороне, и совместными усилиями отбиваться от недоброжелателей, защищая свое право на самобытность и новизну.
Признание идей означает их заимствование. Примите это за аксиому. Как только ваши идеи начали заимствовать и использовать в других языках — вы добились признания, даже если на словах вам говорят обратное. Если в процессе развития сторонних проектов ваши идеи выживут, пройдет совсем немного времени до придания им неофициального статуса общепринятых, без ссылки на автора. Другого способа получения признания и известности, увы, нет. Точнее, есть, но это маркетинг. Если вы хотите войти в историю как разработчик языка программирования, а не гений маркетинга, прикладывать усилия нужно сообразно желаниям, отдавая себе полный отчет о возможных побочных эффектах.
Признание идей совершенно не означает успеха языка — другие разработчики могут оказаться более успешны в реализации ваших идей. Нужно всегда быть к готовым к такому развитию событий, ибо нельзя добиться признания, не публикуя идеи и не рассказывая о них везде, где можно. Для противодействия утечке успеха весьма желательно, чтобы идеи были потенциально неотчуждаемы от языка или платформы — грубо говоря, чтобы для их заимствования нужно было скопировать значимую часть реализации, став безликим клоном на фоне сияющей и чистой авторской жемчужины. Это проще сказать, чем сделать, но не сказать тоже нельзя. Нужно быть честным хотя бы перед самим собой...
Дополнительные пункты:
Простых задач в ИТ не осталось. Для успеха разработки нужно придумать, каким образом вписывать в архитектуру языка вновь выявляемые сложности (по аналогии со вновь выявляемыми объектами культурного наследия). Без этого принципа язык не выживет, оставшись маргинальным и неспособным решить сколь-нибудь серьезные практические задачи.
Прислушивайтесь к новичкам. Их незамутненный взгляд порой может служить хорошей постановкой задачи.
Задачи облегчения программирования для новичков не существует — новички не должны вечно оставаться новичками. Существуют лишь три задачи:
Обучение программированию будущих программистов в качестве первого языка программирования.
Упрощение разработки средств малой автоматизации в терминах прикладной области — условных формул в Excel и прочих одноразовых/нетиражируемых решений — непрограммистами или недоучившимися прикладными программистами, при тесном взаимодействии с заказчиком в условиях постоянно меняющейся постановки задачи.
Разработка языка программирования для школы вместе с авторским учебным курсом, с прицелом на дальнейшую сертификацию в Министерстве образования... Короче, чтобы повторить успех КуМира, нужно быть государственным НИИ.
В перечисленных выше условиях важна инфраструктура, складывающаяся вокруг языка: библиотеки, инструменты, слои абстракций... Может оказаться, что задача «написать программы заново» превращается в «написать библиотеки заново», что намного более скучно для программистов, ибо не дает немедленной отдачи. Разработка библиотек — довольно часто разработка «в стол»...