Адаптировано из обсуждения 2015 года. Здесь Common Lisp служит лишь одним из многих наглядных примеров
Будущее JavaScript?
Мы ценим простоту языка, но со временем утратили бдительность. Я с 2007 года работаю в комитете по стандартам JavaScript (TC39). Нам следует разобраться, почему так происходит естественным образом, какова цена и что с этим делать. Сложность стала неконтролируемо расти. Учитесь на наших ошибках!
Algol, Smalltalk, Pascal и ранний Scheme любили как маленькие и красивые языки. Эта статья адресована не только коллегам из TC39, но и всем, кто хочет повлиять на траекторию разработки JavaScript или любого стандарта, столкнувшегося с аналогичным давлением. Но они тоже были маленькими, и это очень ценилось. Ранний C и JavaScript за многое справедливо критиковали и их редко называли красивыми. Мне нравится, что не осталось никаких неизвестных деталей». Когда язык небольшой, наша оценка часто определяется чувством: «Я могу всё выучить и овладеть им», а потом: «Я всё знаю. Тем не менее, ощущение «маленького языка» во многом обусловило удовлетворение от повседневного использования. Но в случае C и JavaScript вряд ли у кого-то возникало чувство полного овладения языком, поскольку детали на самом деле были дьявольски сложными.
Я активно участвовал в разработке EcmaScript-5 и EcmaScript-2015, и в обоих случаях горжусь своим вкладом. Эстетика минимализма JavaScript сохранилась в стандарте EcmaScript-5. Учитывая, с чего мы начали, невозможно было улучшить JavaScript без такого увеличения размера. EcmaScript-2015 намного вырос в размерах, но привнёс с собой улучшения. Если вернуться назад, вероятно, во многих случаях я предложил бы аналогичные дополнения. Я не жалею о большинстве дополнений, которые привели к раздуванию 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 перестанет быть узким местом, поскольку внешние процессы де-факто и де-юре вполне смогут независимо разрабатывать стандартные модули для удобства.
