Адаптировано из обсуждения 2015 года. Здесь Common Lisp служит лишь одним из многих наглядных примеров
Будущее JavaScript?
Я с 2007 года работаю в комитете по стандартам JavaScript (TC39). Мы ценим простоту языка, но со временем утратили бдительность. Сложность стала неконтролируемо расти. Нам следует разобраться, почему так происходит естественным образом, какова цена и что с этим делать. Эта статья адресована не только коллегам из TC39, но и всем, кто хочет повлиять на траекторию разработки JavaScript или любого стандарта, столкнувшегося с аналогичным давлением. Учитесь на наших ошибках!
Algol, Smalltalk, Pascal и ранний Scheme любили как маленькие и красивые языки. Ранний C и JavaScript за многое справедливо критиковали и их редко называли красивыми. Но они тоже были маленькими, и это очень ценилось. Когда язык небольшой, наша оценка часто определяется чувством: «Я могу всё выучить и овладеть им», а потом: «Я всё знаю. Мне нравится, что не осталось никаких неизвестных деталей». Но в случае C и JavaScript вряд ли у кого-то возникало чувство полного овладения языком, поскольку детали на самом деле были дьявольски сложными. Тем не менее, ощущение «маленького языка» во многом обусловило удовлетворение от повседневного использования.
Эстетика минимализма JavaScript сохранилась в стандарте EcmaScript-5. Я активно участвовал в разработке EcmaScript-5 и EcmaScript-2015, и в обоих случаях горжусь своим вкладом. EcmaScript-2015 намного вырос в размерах, но привнёс с собой улучшения. Учитывая, с чего мы начали, невозможно было улучшить JavaScript без такого увеличения размера. Я не жалею о большинстве дополнений, которые привели к раздуванию EcmaScript-5 до EcmaScript-2015. Если вернуться назад, вероятно, во многих случаях я предложил бы аналогичные дополнения.
Каждое из дополнений должно было преодолеть очень высокую планку. Психологически это имело смысл, потому что мы равнялись на минимализм EcmaScript-5. Когда язык мал, каждая дополнительная функция интуитивно ощущается как значительное процентное увеличение размера языка. Конкретные преимущества функции всегда видны её сторонникам. Для небольшого языка вклад новой функции в увеличение общей сложности также по-прежнему виден всем.
Как только язык выходит за рамки определённой сложности — скажем, LaTeX, Common Lisp, C++, PL/1, современная Java — программирование становится больше похоже на вырезание подмножества функций для личного использования из бесконечного моря функций, большинство из которых мы никогда не освоим и смирились с этим. Как только язык воспринимается «бесконечным», конкретные преимущества новой функции всё ещё понятны. Но общие издержки, связанные с дополнительной сложностью, больше не очевидны. Они больше не ощущаются теми, кто обсуждает новую функцию.
.
Даже 
.
Это смерть от тысячи порезов, которая заставляет этих монстров расти без всяких ограничений.
Поэтому прошу всех, кто влияет на язык, при рассмотрении новой функции применить более высокую планку, чем «неплохо иметь ещё и такую возможность, разве нет?». Я считаю, что EcmaScript-2015 находится на той пограничной территории, где безудержный рост ещё можно предотвратить, но только если мы начнём сдерживать друг друга высокими стандартами для любой предлагаемой новой функции. Как сообществу, нам нужно больше общего чувства паники по поводу того размера, которого уже достиг EcmaScript-2015. В идеале, с ростом языка, когда размер приближается к точке невозврата, паника должна увеличиваться, а не уменьшаться.
Некоторое различия
Сохранить минимальное неравномерное давление
Актуальность минимализма ослабевает по мере перехода от базового языка к библиотекам. Стандартный язык в целом можно представить как следующую структуру:
- Фундаментальный синтаксис: специальные формы, которые невозможно точно выразить локальным расширением на другой синтаксис.
- Семантическое состояние: состояние, которым манипулирует вычисление.
- Встроенные в ядро модули (kernel builtins): часть встроенной библиотеки, предоставляющая функциональные возможности, которые не может предоставить пользовательский код сам по себе.
- Не встроенные в ядро модули (non-kernel intrinsics): встроенные библиотеки, которые могут быть реализованы в JavaScript, но от них зависит семантическое состояние или модули, встроенные в ядро. Например, через прокси можно реализовать массив в пользовательском коде. Но в других встроенных в ядро модулях уже есть зависимость от Array, что даёт этому конкретному массиву привилегированное положение над любой предполагаемой заменой.
- Синтаксический сахар: синтаксис, который можно выразить локальным расширением до фундаментального синтаксиса.
- Глобальные библиотеки для удобства: могут быть реализованы непривилегированным пользовательским кодом, но с учётом стандартных глобальных путей именования в изначальном глобальном пространстве имён.
- Стандартные модули для удобства: разработанные сообществом модули, одобренные в качестве стандарта.
Я перечислил их по порядку, в соответствии с моим ощущением увеличения издержек роста и настоятельной необходимостью минимализма. Для всего этого необходимо проявлять дисциплину. Только по последнему пункту мы можем допустить неограниченный рост, но желательно, чтобы кандидаты прошли проверку сообществом и принимались сначала де-факто. В идеале, комитет TC39 перестанет быть узким местом, поскольку внешние процессы де-факто и де-юре вполне смогут независимо разрабатывать стандартные модули для удобства.
Автор: m1rko
