ストブダグラス・クロックフォードは、彼の最新著書『How JavaScript Works』（Virgule-Solidus 出版、2018 年、約 24.19 ポンド、279 ページ）の冒頭の章で、読者に押し付けることになる英語の言語的特異性をいくつか紹介しています。
中でも最も衝撃的なのは「one」の綴りだ。そう、そう、あのケリーの目、あの無力な掛け算、チャールズ皇太子が自ら呼ぶあの名。クロックフォードはそれを「wun 」と綴り続ける。何度も何度も。愛らしいバリエーションが無料で追加されている。somewun 、anywun、no wun、I wunce wrote a constructor、wunth、そして覚悟しておいてほしいが、twoth。
これはかなり迷惑で気が散りますが、大西洋を横断するエコノミークラスのフライトで、座席の背もたれがポアソン分布で 1 分あたり約 4.7 回のラムダで跳ね上がる、規律の悪い ADD の男の子の前に、窮屈な中央通路側の席が座っている状況よりはましです。
デイジー・アシュフォード、アラン・アレクサンダー・ミルン、あるいは他の奇想天外な児童文学作家の作品で、この「wun」という綴りを見たことがあったはずです。私たちは、荒々しいワールドワイドウェブに「さようなら」と手を振りました。そして、ウンの百エーカーの森に降り立ったのです。
良い部品
この限りなく有望なスタートを考えると、JavaScript に詳しくないReg読者は、私たちがなぜここにいるのかと当然疑問に思うかもしれません。
理由は歴史的なものです。2000年代初頭、プログラミング最高司令部はJavaScriptをおもちゃの言語とみなし、醜悪なウェブページでマウスオーバーイベントをうまく操作できず、上から目線で反論するだけの言語として扱いました。「いやいや、Javaと混同しているじゃないですか。Javaとは全く関係ありません！マーケティングに騙されただけでしょう！はははは。」
しかし、ダグラス・クロックフォードは、君が絶対にしないと約束したことを実行した。彼は彼らをぶっ殺したのだ。そして、その結末は驚くべきものだった。彼はJavaScriptの流行りの波括弧、不格好な比較演算子、そして不可解なスコープ規則の裏に埋もれていた、プログラミング環境を汚染する数多くのC言語風スクリプト言語とは全く異なる、非常に強力な言語を発見したのだ。
クロックフォードは実践を通して証明しようと試みました。彼はJavaScriptオブジェクトにプライベートな隠しフィールドを持たせることが可能であることを実証し、自身のウェブサイトで公開しました。これは当時の教科書では不可能とされていた偉業でした。彼は大規模なプログラムを適切に独立したモジュールに分割しました（これもまた同様です）。
彼はJavaScriptのオブジェクトリテラルを、データ交換フォーマット「JSON」の基盤として用いました。これは現在誰もがあらゆる用途で使用しているJSONであり、1つの短いウェブページですべてを記述します。（当時、ウォーターストーンズの棚は、JSONの不動のライバルである、言葉にするのも読むのも難しいXMLの利点を説く、分厚くて読みやすい書籍で溢れていました。中には自動閉鎖式の防火扉を押さえるほど重いものもありました。）
彼は、ユーザーをクロックフォードが推奨する健全な JavaScript の道へと導くプログラムである JSLint を作成し、このツールを悪用することを「IBM、その顧客、パートナー、および手下」に寛大に許可したことで有名です。
何よりも重要なのは、彼が書いた『JavaScript: The Good Parts』です。この「気難しいパンフレット」（説明文 © D Crockford）は、K&R、Stroustrup、Klabnik and Nicholsに最も近いJavaScriptの代替として、かなりの支持を集めました。最初のプログラムにはHello, Worldまで含まれていました。
イーヨーの暗い場所
10年経ち、Crockfordの貢献に大きく支えられ、この言語の重要性はn倍に増大しました。その結果、近年、この言語は度重なる改ざんを受け、最終的には標準規格が毎年改訂されるに至っています。Good Partsは時代遅れとなっています。
How JavaScript Works はGood Partsの焼き直しではありませんが、基本的なアプローチは同じです。Crockford 氏は言語の機能を一つ一つ解説し、落とし穴を指摘し、危険な装飾と見なす機能を却下し、回避策やテクニックを提案しています。
JavaScriptブログの専門用語で言えば、これは意見が固いリソースです。「もし私があなたの一番好きな機能について言及しなかったら、それはその機能がひどいからでしょう」とあります。もし彼がその機能について言及したとしても、あなたは後で後悔するかもしれません。以下は彼の嫌いな機能のほんの一部です。
- コールバック、Promise、そしてasync/await。これらは、Node.jsプログラマーが古今東西を問わず使用する3つのコードシーケンス構造です。クロックフォード流に「3つの間違い」と呼ばれています。
- ES6 ジェネレータ (「標準化プロセスが深刻な Python 羨望に悩まされていた時期に追加されました」。代替案を示す Crockford のコード スニペットははるかにすっきりと洗練されており、標準化委員会が共同で額を叩いて「うわっ!」と叫ぶはずです)
- 例外を再スローする（「C++ によって普及したひどい習慣」）
- ファット矢印
=>(「オナラは関数を記述する省略された方法です」。嫌いな理由: ファット矢印を使用してオブジェクトを返すときにあいまいな中括弧の問題があり、それを および と混同する危険性があります<=。>=本当ですか?) - キーワード
class（「これを使ったプログラマーたちは、class自分がどれほど惨めだったかを知ることなく死ぬだろう」）
JSの新機能の中には、より温かく歓迎されるものもあります。例えば、このArray.reduceメソッドは「なかなか素晴らしい」と評価されています。しかし、こうした熱意は実に控えめに使われています。
ちなみに、今流行りのReactキッズやNode.jsの発明者Ryan Dahl、そして私自身も絶賛しているTypeScript言語については触れられていません。Crockford氏が型安全性について低い評価（「型は、難解で複雑で疑わしいコーディング手法を採用させてしまう可能性がある」）を表明し、さらに「トランスパイラは本番環境では決して使用すべきではない」と斜体でアドバイスしていることを考えると、TypeScriptは彼の「ゴミ」の山にしっかりと埋もれていると考えて間違いないでしょう。うわー。
ティガーが跳ねる
この本は決して悲観的な内容ばかりではなく、むしろ悲観と救済を扱っています。
最初の章を見てください。ここではJavaScriptの数値型、つまり64ビットIEEE浮動小数点数を扱っています。数分おきに、世界のどこかで、初心者のJavaScript開発者がこの落とし穴に陥ります。
0.1 + 0.2 === 0.3 // false、結果
クロックフォードがこの点を強調するのは当然である。（一方で、このしわ寄せに関する彼の報告は
(1 / 0) === (1 / -0) // これも false
読者を楽しませるためだけに存在している。私にとってはそれでいい。
number次の部分は巧妙だ。彼は、を追加するという標準的な提案に反対しBigInt、通常の倍精度整数の下位24ビットを取り出して、それを任意精度整数ライブラリの基礎とするために酷使した。しかし、これで満足せず、彼は整数ライブラリを拡張して「大きな浮動小数点」ライブラリを作成した。これは巧妙に設計されており、10分の1の加算が適切に行われるようになっている。さらに、分数（いかに粗雑な分数でも）を扱う「大きな有理数」ライブラリも作成した。
どれもとても独創的です…でも、使用済みのヴェスタでタイタニック号の模型を作るのも独創的です。そして、パフォーマンスが心配です（演算性能であって、マッチの性能ではありません）。ちなみに、私のデータソースは晴れた日でも14ビットの精度を出すことは滅多にありません。金融計算をする人ならきっと感謝するでしょう。
この一般的なアプローチはテンプレートを設定します。つまり、言語の問題を特定し、回避策を提供します。
…しかし、この回避策が常に必要だとは私には思えません。「リクエスター」は、Node.jsのコールバック、プロミス、そしてasync/await関数のCrockfordによる代替案です。最初の2つが問題であることは議論の余地がありませんが、私が理解する限り、Crockfordがasync/awaitに反対しているのは、その基盤となるメカニズムがユーザーから隠蔽され、結果としてユーザーがその動作を理解できないという点です。
これは、パイプを吸い、革の肘当てをしていた世代がずっと昔に唱えた、Z80アセンブリを習得するまではC言語を使うべきではないという古い議論に似ているように私には思えます。私はそれには賛成できません。それに、私は悲惨な保守主義者なので、コードベースが既に他の3つのコールバック機構の入り組んだ混乱した状態で、4つ目のコールバック機構を開発することには抵抗を感じています。
はるかに有望なイノベーションは、JSCheckです。これは、一般的なユニットテストフレームワークの強力なバリエーションです。TDDassertEquals()派の偏狭な処方箋に従って、プログラマーに退屈なテストを一つずつ書かせるのではなく、JSCheckのテストは、結果が良好であればtrueを返す述語関数を用いて構成されます。JSCheckが起動されると、対象コードには自動生成されたランダム値が大量に送信されます。従来のユニットテストというよりは、ファジングに近い印象で、実際に試してみるのが楽しみです。
本書は、ゲイリー・バーンハートによる有名なWAT講演（これは間違いなく、クロックフォードの『Good Parts』付録「Bad Parts」に影響を受けたと思われる）に基づく章で締めくくられている。JavaScriptの最も厄介な部分が暴露されている。いつものように、JavaScriptの不当な等価演算子と空配列は、
[] == [] // 偽 [] == ![] // 真
子供たちに何時間もの楽しみを提供します。
トンスタント・ウィーダーは飛び上がらない
偶然『How JavaScript Works』を見つけました。この本は出版されてからほぼ1年経ちますが、私が聴いているポッドキャストで取り上げられたことはありません。Eggheadの講座で取り上げられているわけでもなく、この記事を書いている時点ではamazon.co.ukにはかなり辛辣なレビューがあるだけです。
JavaScriptの重要性と本書の由来を考えると、これは驚くべきことです。「有名」な出版社から出版されていないことが問題の一因ではないかと考えています。実際、自費出版の痕跡はいくつも見られます。表紙には「舞台裏の蓋を剥ぎ取る、衝撃の大ヒット作！」というユーモラスな見出しが添えられています。
クロックフォードは常に陽気に破壊的であり、アプローチではなく目的に真剣であるべきだという3代目ドクターの格言を常に守ってきた。
これらは称賛に値する資質ですが、絶え間ない冗談好きはレンズを曇らせがちです。彼には編集者が必要でしょう。私のサービスはご利用いただけますが、驚くほどお値打ちです。ご依頼いただければ、wunceでwunの問題を解決します。®
ベリティ・ストブは、ロンドンを拠点とするソフトウェア開発者のペンネームです。1988年以来、.EXE誌、Dr. Dobb's Journal、そして2002年からはThe Register誌に「ベリティ・ストブ」コラムを執筆しています。
