Почему большие языки стремительно растут

Взято из темы обсуждения в сети, 2015 г.. Common Lisp - это не тема. Это лишь один из многих иллюстративных контрпримеров.

Я был членом комитета по стандартам JavaScript (TC39) с 2007 года. В 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-2015, я бы, вероятно, внес аналогичные дополнения.

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

Когда язык выходит за рамки определенной сложности - скажем, LaTeX, Common Lisp, C ++, PL / 1, современной Java - опыт программирования на нем больше похож на выделение подмножества функций для личного использования из того, что кажется бесконечным. море функций, большинство из которых мы смирились с тем, что никогда не узнаем. Когда язык кажется бесконечным, конкретные преимущества новой функции по-прежнему очевидны. Но общие затраты на добавленную сложность больше не очевидны. Те, кто обсуждает новую функцию, больше не чувствуют. Бесконечность + 1 === Бесконечность. Даже aLargeNumber + 1 === приблизительно AsLargeANumber. Это смерть тысячи порезов, из-за которой эти чудовища неограниченно разрастаются.

Поэтому, пожалуйста, я прошу всех, кто влияет на язык, при рассмотрении новой функции, пожалуйста, установите более высокую планку, чем «Было бы неплохо, если бы мы могли также написать это так?». Я считаю, что EcmaScript-2015 находится на той средней территории, где безудержный рост еще не неизбежен, но только если мы все будем сдерживать друг друга высокими стандартами в отношении любой предлагаемой новой функции. Как сообществу, нам нужно больше общего чувства паники по поводу размеров, до которых уже разросся EcmaScript-2015. В идеале наша паника должна увеличиваться, а не уменьшаться, с дальнейшим ростом, поскольку наш размер приближается к точке невозврата.

Некоторые отличия

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

  • Основной синтаксис - особые формы, которые нельзя точно объяснить локальным расширением до другого синтаксиса.
  • Семантическое состояние - состояние, которым манипулируют вычисления.
  • Встроенные функции ядра - часть встроенной библиотеки, обеспечивающая функциональные возможности, которые, если бы они отсутствовали, не могли быть предоставлены вместо этого пользовательским кодом.
  • Неядерные встроенные функции - встроенные библиотеки, которые могут быть реализованы на JavaScript, но от которых зависит семантическое состояние или встроенные функции ядра. Например, с прокси-серверами можно реализовать Array в пользовательском коде. Но другие встроенные функции ядра уже напрямую зависят от Array, что дает ему привилегированное положение по сравнению с любой заменой.
  • Синтаксический сахар - синтаксис, который можно объяснить локальным расширением основного синтаксиса.
  • Глобальные удобные библиотеки - могут быть реализованы с помощью непривилегированного пользовательского кода, но с заданными стандартными глобальными путями именования в первичном глобальном пространстве имен.
  • Стандартные удобные модули - добавление модулей, разработанных сообществом, в качестве стандартных.

Я перечислил их по порядку, исходя из моего понимания затрат на рост и безотлагательности минимализма. Для всего этого нам по-прежнему нужно проявлять дисциплину. Только в отношении последнего, рост абсолютных размеров следует считать неограниченным; ограничивая только скорость роста, поскольку мы ждем, пока кандидаты проявят себя первыми в рамках де-факто процесса принятия сообществом. В идеале TC39 в любом случае должен перестать быть узким местом на последнем этапе, поскольку внешние процессы de facto и de jure должны иметь полную способность независимо обсуждать и развивать стандартные удобные модули.