Компания
239,93
рейтинг
11 января в 08:50

Разработка → Перевод: Трагедия common lisp перевод

Вашему вниманию предлагается перевод письма Марка Миллера, одного из участников комитета по стандартизации 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”, то пора эту часть рефакторить нафиг в функцию, метод, миксин или что-нибудь еще. Потому что сложность не дремлет, а Кошелек Миллера только и ждет, чтобы оттяпать зазевавшемуся программисту что-нибудь нужное.
Автор: @yaroslavb Mark S. Miller

Комментарии (8)

  • +3
    Не понял ссылку на кошелек Миллера. Чего в хорошем языке должно быть 7±2? Более уместной аналогией была бы бритва Оккама — не плодить лишних сущностей без надобности.
    • +1
      Быть может, строчек в методе? Речь скорее не о языке, а о коде, который на нем пишется. К тому же, как автор статьи про Кошелек Миллера дал знать, дело вовсе не в 7±2, а скорей N±ε, где эти значения сильно зависят от контекста.
  • +5
    Желание ввести подобного рода сахар скорей всего возникло именно для того, чтобы подчеркнуть функциональную натуру javascript'а, потому что подобного рода let-блоки встречаются повсеместно в разного рода функциональных языках. Марк прав в отношении данной фичи: Это не тот сахар, который бы значительно облегчил жизнь разработчикам, и не тот, который значительно улучшил бы читаемость кода, как и сказал переводчик, скорей всего, этому блоку будет лучше житься в отдельной функции.

    Да и к тому же, будем честны: JS использует огромное количество людей и вряд ли хотя бы треть из них когда нибудь писала на языках типа Lisp или Haskell. Подобного рода сахар оценила бы лишь маленькая ниша разработчиков, который тащятся от разных функциональных плюшек, да и те, скорей всего, в свободное время пишут на ClojrueScript.
  • +1
    Стоит отметить, что Миллер-Автор-Кошелька и Миллер-Автор-Письма — это два разных человека. Даже не родственники.

    И ещё. Рассматривать такую проблему лучше через призму KISS + YAGNI, чем через кошелёк Миллера. Кошелёк Миллера это про несколько другое.
  • 0
    Мне нравится Parser-3 в этом смысле. При том что язык богатый и весьма быстрый в разработке, оглавление его спецификации умещается на один экран открытого chm-файла.
  • +3
    При наличии анонимных arrow-функций, которые вполне могут инлайниться компилятором, синтаксис let-block имеет мало смысла, т.к. можно написать так:

    (() => { /* тут что угодно */ })();
    
    • 0
      Но зачем, если вместо этого можно написать
      { /* тут что угодно */ }
      • 0
        Потому не не надо плодить сущности :)

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

Самое читаемое Разработка