Вашему вниманию предлагается перевод письма Марка Миллера, одного из участников комитета по стандартизации JavaScript. В этом письме Марк рассказывает, к чему может привести «ползучий фичеризм» при дизайне языков программирования. И почему он не хочет добавлять в javascript синтаксис «let-block».

Я не собираюсь поддерживать инициативу добавления такого синтаксиса в javascript. Более того, если кто-нибудь вызовется это сделать, то я приложу все усилия, чтобы закопать такое начинание. И вот почему.

Разработчики хвалили Algol, Smalltalk, Pascal и ранние версии Scheme за малый размер и красивый синтаксис. JavaScript и C аргументировано критиковали за разное, и мало кто мог принять их за языки с красивым синтаксисом. Но у них был малый размер спецификации, и это всегда ценилось разработчиками. Когда описание языка программирование невелико, то такой язык часто воспринимается как “я могу выучить синтаксис полностью и тем самым овладеть языком в совершенстве”, которое затем меняется на “я знаю синтаксис полностью. Мне нравится тот факт, что в языке не осталось ничего, о чем бы я не знал”. Хотя, конечно, для JavaScript и C только немногие из тех, кто так думают, на самом деле досконально знают эти языки. В их темных уголках сокрыто множество дьявольски запутанных деталей. Тем не менее, эти ощущения добавляли удовлетворения при каждодневном использовании языка программирования.

Эстетика маленькой спецификации языка сохранялась вплоть до ES5. Я активно участвовал в разработке как ES5, так и ES6, и горжусь своим вкладом в язык. Да, спецификация ES6 сильно больше чем у ES5, но, тем не менее, сам язык стал намного лучше. Учитывая, с чего мы начинали, мы бы не достигли такого прогресса в юзабельности ES6 без значительного расширения его спецификации. И я не жалею о большинстве дополнений, которые превратили ES5 в ES6. Если бы у меня была возможность вернуть в прошлое и все переиграть, то я скорее всего сделал бы все так же.

Но каждое из дополнений, которые превратили ES5 в ES6, должно было соответствовать очень высокой планке. Психологически это играло большую роль для нас, так как мы начинали с ES5, размер спецификации которого мы все еще ценили. Когда размер спецификации невелик, каждое добавляемое в нее улучшение выглядит как значительное увеличение “веса” спецификации. Польза фичей ясно видна тем, кто их предлагает. Но для языка с небольшой спецификацией всем также ясно видна цена такой фичи — сколько сложности она добавляет к языку.

Когда сложность языка программирования превышает некое значение — к примеру, как у LaTex, Common Lisp, C++, PL/1 или современной Java, то опыт использования такого языка превращается в мучительный подбор “набора фичей” для персонального использования из кажущегося бесконечным океана фичей этого языка. Большую часть которых мы не хотим никогда изучать. Тем не менее, даже если набор фичей языка кажется нам бесконечным, мы можем легко оценить преимущества отдельно взятой новой фичи. А вот сложность, которую эта фича добавит к языку, оценить уже не так просто. Те, кто обсуждают новые фичи для таких языков уже не способы “чувствовать” добавляемую этими фичами сложность. Ведь бесконечность плюс один — это все равно бесконечность. Та самая “смерть от тысячи порезов”, которая заставляет эти монструозные языки расти безо всяких ограничений.

Коллеги, я прошу вас, когда вы оцениваете новую фичу для языка — ставьте более высокую планку нежели “было бы прикольно если мы могли писать еще и так”. Я верю, что спецификация ES6 все еще в том состоянии, когда есть возможность избежать ничем не ограниченного роста. Но это возможно только в том случае, если мы будем ограничивать себя в желании досыпать еще чуток фичей, и придерживаться только самых высоких стандартов качества для всего, что мы хотим добавить в язык. Как сообществу, нам не помешает легкое чувство паники относительно размера спецификации ES6. Идеально, если эта паника будет расти, а не уменьшаться, по мере того, как размер спецификации языка приближается к точке невозврата.

С уважением,
Марк

Примечание переводчика

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

{ // блок для защиты локальных переменных
  let a = 2, b, c; // локальные переменные
  ...
}

писать что-то вроде

let (a = 2, b, c) {
}

Переводчик разделяет мнение Марка. Более того, я считаю, что если в коде появилась необходимость изолировать его часть в такой “let block”, то пора эту часть рефакторить нафиг в функцию, метод, миксин или что-нибудь еще. Потому что сложность не дремлет, а Кошелек Миллера только и ждет, чтобы оттяпать зазевавшемуся программисту что-нибудь нужное.