このような構文をjavascriptに追加するというイニシアチブをサポートするつもりはありません。 さらに、誰かがこれを行うことを志願した場合、そのような事業を埋めるために最善を尽くします。 そして、ここに理由があります。
開発者は、Algol、Smalltalk、Pascal、およびSchemeの以前のバージョンが、サイズが小さく美しい構文であることを称賛しました。 JavaScriptとCはさまざまな点でかなり批判されており、優れた構文の言語と間違えることはほとんどありませんでした。 しかし、仕様のサイズは小さく、開発者は常にこれを高く評価していました。 プログラミング言語の記述が小さい場合、そのような言語は「構文を完全に学習でき、それにより言語を完全に習得できる」と認識され、「構文を完全に知っています。 私は知らない言語には何も残っていないという事実が好きです。」 もちろん、JavaScriptとCの場合、実際にこれらの言語を完全に知っているのは実際にそう思う人のほんの一部です。 暗いコーナーには、多くの悪魔のような複雑な詳細が隠されていました。 それにもかかわらず、これらの感情は、プログラミング言語の日常的な使用に満足を加えました。
小さな言語仕様の美学は、ES5まで続きました。 私はES5とES6の両方の開発に積極的に参加しましたが、この言語への貢献を誇りに思っています。 はい、ES6の仕様はES5の仕様よりもはるかに大きくなっていますが、それでも、言語自体はずっと良くなっています。 どこから始めたのかを考えると、ES6の仕様を大幅に拡張しない限り、ES6の使いやすさを向上させることはできなかったでしょう。 また、ES5をES6にしたほとんどのアドオンを後悔していません。 過去に戻ってすべてを再生する機会があれば、おそらく同じことをするでしょう。
しかし、ES5をES6に変えた各アドオンは、非常に高い水準を満たす必要がありました。 心理学的には、これは私たちにとって大きな役割を果たしました。ES5から始めたので、仕様サイズはまだ高く評価されています。 仕様のサイズが小さい場合、それに追加される各改善は、仕様の「重量」の大幅な増加のように見えます。 機能の利点は、それらを提供する人々にはっきりと見えます。 しかし、仕様が小さい言語の場合、そのような機能の価格は誰にでもはっきりと見えます。言語にどれだけ複雑さが加わるかです。
LaTex、Common Lisp、C ++、PL / 1、または最新のJavaなど、プログラミング言語の複雑さが特定の値を超えると、そのような言語を使用した経験は、この言語の機能の見かけ上無限の海からの「機能セット」の痛ましい選択に変わります。 そのほとんどは決して勉強したくない。 それでも、言語の一連の機能が無限に思える場合でも、1つの新しい機能の利点を簡単に理解できます。 しかし、この機能が言語に追加する複雑さを評価するのはそれほど簡単ではありません。 そのような言語の新機能について議論する人は、これらの機能によって追加された複雑さを「感じる」方法ではなくなりました。 とにかく、無限に1を足したものはとにかく無限です。 これらの巨大な舌を制限なしに成長させるまさに「千切りからの死」。
同僚の皆さん、この言語の新機能を評価する際には、「もっと書くことができたら楽しいだろう」よりも高い基準を設定してください。 ES6仕様は、無限の成長を回避できる状態にあると考えています。 しかし、これは、いくつかの機能を追加することを制限し、言語に追加するすべてのものの最高品質基準のみを順守する場合にのみ可能です。 コミュニティとしては、ES6仕様のサイズに関して多少のパニック感はありません。 理想的には、言語仕様のサイズがノーリターンのポイントに近づくにつれて、このパニックは減少するのではなく増加するでしょう。
よろしく
マーク
翻訳者のメモ
マークがこのメモを書いた後の提案は、 ここにあります 。 代わりに構文糖を追加することを提案しました。
{ // let a = 2, b, c; // ... }
のようなものを書く
let (a = 2, b, c) { }
翻訳者はマークの意見を共有します。 さらに、このような「letブロック」でコードの一部を分離する必要がある場合は、この部分を関数、メソッド、mixinなどにリファクタリングする時が来たと思います。 複雑さは眠っておらず、 Millerの財布はぽっかりとしたプログラマーに必要なものを切り取るのを待っているだけだからです。