Есть ли механизм, чтобы сделать язык программирования более стабильным (совместимым) для изменений?

Существует большое количество языков программирования. Некоторые из них вырастают и становятся очень популярными. Люди используют такие языки все чаще и чаще. Основатель такого языка (или основатель организации / сообщества) может попытаться внести изменения, чтобы сделать язык лучше. Но иногда трудно внести некоторые изменения из-за обратной совместимости, и такие уродливые вещи существуют в языке уже много лет и используются многими пользователями.

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

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

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

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

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

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

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

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

  • Могу ли я ввести нового оператора, например, |>не выходя из языка? Могу ли я выбрать приоритет и ассоциативность для этого оператора?
  • Какую церемонию я должен пройти для встроенной функции / лямбда / закрытия?
  • Могу ли я использовать существующий синтаксис языка для реализации синтаксиса цикла foreach? Например, Ruby и Scala могут сделать это с помощью своего гибкого синтаксиса вызова методов с лямбдами.

• Рассмотрим возможности для расширения семантики. Общие потребности:

  • Перегрузка операторов, когда пользовательские типы могут присваивать свои значения существующим операторам. Это делает язык намного более приятным в математических приложениях.
  • Буквальная перегрузка. Могу ли я сделать строковые литералы моего типа строки? Могу ли я сделать все числовые литералы в текущей области видимости bignums?
  • Протоколы метаобъектов. Если у языка нет признаков, могу ли я реализовать их в текущей объектной системе? Могу ли я реализовать другой порядок разрешения методов? Могу ли я поменять способ хранения объектов или методы отправки?
• Есть регрессионные тесты. Много испытаний. Не только написано языковыми дизайнерами, но и пользователями. Когда добавление функции нарушает эти тесты, тщательно сопоставьте преимущества этой функции с преимуществами обратной совместимости.
• Версия вашего языка. Не только в вашей документации, но и в самом исходном коде. Как только вы это сделаете, единственной частью вашего языка, которая не может измениться, является синтаксис этой версии прагмы. Примеры: Ракетка позволяет вам указать диалект. Perl позволяет вам use v5.20, что включает все обратно несовместимые функции Perl v5.20. Вы также можете загрузить отдельные функции, как явно use feature 'state'. Похожие: Питонfrom __future__ import division .
• Подумайте о том, чтобы спроектировать свой язык так, чтобы получилось несколько зарезервированных слов. classТот факт, что вводит класс, не означает, что я не смогу иметь локальную переменную с именем class. На практике это приводит к появлению ключевых слов, которые вводят объявления переменных или методов, что противоречит C-подобной традиции использования имен типов для представления объявлений. Другой альтернативой является использование сигил для вашего $variables, как в Perl и PHP.

На части этого ответа повлияла речь Гая Стила «Расти язык» (1998) ( pdf ) ( youtube ).

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

Например, я использую SBT для Scala или Leiningen для Clojure. Они оба позволяют мне объявить, какую версию языка я хочу использовать для каждого проекта . Таким образом, довольно просто запустить зеленые проекты на последней версии языка, одновременно обновляя существующие проекты более комфортными темпами, если вообще когда-либо.

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