「速さ」は幻想か？AIアシスタントの期待と現実
引用元：https://news.ycombinator.com/item?id=44736967
LLMを使った作業って、しょっちゅう遅いんだよね。IDEの「refactor」機能は一瞬で終わるのに、速いアシスタントだと30秒、エージェント型だと15分もかかる。
終業間際に残り30分でHTTPエンドポイントを書くのをエージェントに頼んだんだけど、最初は「1日かかる作業が10分でできた！」って思ったけど、後で「4時間分の作業が20分でできたのかも」って考え直したよ。
次の日に見たら、ロジックは複雑だし、エラーハンドリングもうまくいってなかった。結局、手動でほとんど書き直す羽目になったよ。5時間かかってやっと完成したけど、自分で書くよりテストスイートもエラーハンドリングも良くなったのは確か。まあ、 https://www.reddit.com/r/programming/comments/1lxh8ip/study_… を見てみて。
このことについては、ここで何度も書いたけど、LLMがベンチマークスコアばかり追いかける今のトレンドは、少なくともプログラミングツールとしては間違った方向に行ってると思うよ。僕の経験では、かなりの確率で間違った答えを出すから、常にチェックしないといけないんだ。
結局LLMと行ったり来たりする羽目になるし、反応が遅いから本当に苦痛なプロセスになる。座って自分で考えた方が速いこともよくあるんだ。
僕が欲しいのは、ベンチマークスコアが80%じゃなくて60%だとしても、すぐに（1秒未満で）応答するエージェントだよ。
プログラマー（僕も含めてね）って、考えないためにめちゃくちゃ努力することが多いんだ。1時間考えるのを避けるために、コーディングアシスタントを使ったり使わなかったりしながら何時間も作業する、みたいな。あの格言なんだっけ？「1時間のデバッグ／プログラミングは、数分の思考を節約する」みたいなやつ。
結局、結局のところ、僕たちは考えなきゃいけないってことに気づくんだよね。
コーディングアシスタントは、頼まれたことをやろうとするんじゃなくて、僕たちが考えるのを助けたり（あるいは強制したりするような）質問を投げかけてくれる方が、もっと役立つと思うな。
「何か頼んだら、僕はまだ問題を深く考えてないって仮定して、何かする前にまず誘導的な質問をしてくれ」っていうコンテキストプロンプトが役に立つかどうか、気になるところだね。
Leslie Lamportがかつて言ってたけど、TLA+—思考を助けて強制する言語—を使うことへの最大の抵抗は、プログラマーが一番やりたくないことだから、ってね。
反例として（エージェントに関してね）、僕は簡単なタスクを日常的にClaude Codeに任せてて、ほぼ完璧な結果を得てるよ。でも、君みたいな経験、つまり時間を使ったのに結局何も得られなかった、っていう経験ももちろんあるんだ。
色々な種類のタスクを試し続けて、何がうまくいって何がダメか、良い直感が働くようになったよ。そのメリットは、スマホでリクエストを投げてポケットに入れといて、後でコードレビューできることだね。
このプロセスは僕にとって精神的な負担がすごく低いから、生産性向上に大きく貢献してるよ。
僕がLLMで作業が速くなった唯一のことは、一種の高度な検索置換だね。
「このコードでXXXを扱うロジックを全て、YYYにする／追加する／何かロジック変更する」みたいなプロンプトだよ。
こういう種類の変更にはかなり優秀で、手動で探し回って更新するよりも時間を節約できるんだ。まあ、巨大なコードベースでこれを試したことはないけどね。
スロットマシンみたいだね。APIトークンを入れて、そこそこまともなものが出てくる。またトークンを入れて、今度はうまくいくことを願う、って感じ。
もしかして、emacsのgrepモードとかvimのquickfixを試したことないの？変更が機械的なら、マクロを作って数秒で終わるよ。そうじゃなくても、高レベルの概要と素早いナビゲーションができるからね。
それいいね、どうやってスマホとClaudeのワークフローを統合してるの？
君のコメントには全体的に同意するけど、僕の分野だと、TLA+への抵抗は「考えること」じゃなくて、理論モデルが実際にコードにマッピングされる保証がないことにあると思うな。LeanやDafnyみたいなツールは、モデルからコードを生成してくれるから、そっちの方がずっと評価されてるよ。
DafnyとかLeanってTLA+より使われてないし、コードに厳密に仕様を紐付けるって問題は、コードよりはるかに高いレベルで仕様を作る時にだけ出てくるんだ。それこそが一番効果が出る場所だしね。TLA+はJavaで書かれた1MLOCのデータベースとか、C++の100KLOCのGCとかで、設計がデータ損失やメモリ破損につながらないか確認したい時に使うもの。Dafnyじゃ無理だし、Leanでも超ドMで何ヶ月もかけるならできるかもだけど、検証可能にコードと紐付けはできないよ。現実的な規模で仕様とコードをコストをかけずに正式に紐付けられるツールなんてないし、みんな欲しがるのは、結局いつかやらなきゃいけない思考から逃れたいからじゃない？LeanとTLA+は似てるけど、Dafnyは全然違うカテゴリだけどね。
シニアの仕事でAIアシスタント使うと、40〜60%もスピードアップしたって個人的な話や、みんなの体験談をよく聞くんだよね。エージェントは好きだけど、人間がまだ完全に楽して怠けられるってほどじゃないと思うけどな！
投入するトークンには意味があるし、ものによってはより良い結果を生むんだ。スロットマシンとは全然違うよ、マジで。スロットマシンは入力が1つしかなくて、当たる確率を上げる方法はないからね。
＞「XXXに関するロジックをコードで変更したい」みたいなプロンプト
もし俺がこんなプロンプトを便利だと感じるようになったら、それはコードの構造が間違ってるサインだって思うな。
ああ、スロットマシンじゃなくてポーカーだね。
変更箇所を探して飛ぶのは大体簡単だけど、単純じゃない変更って、単なる行ベースの正規表現置換だけじゃなくて、コードを理解する必要があるんだ。時間かけて全エッジケースを処理するマクロを録画するか、ASTベースの検索と置換を使うこともできるけど、cursor agentがバックグラウンドでうまくやってくれるから、それで十分だよ。
コード構造はシンプルだよ。難しいのはセマンティクスだね。だから、コードをよく理解してても（してなくても）、ああいうツールから得られる全体像や、追加される対話性は、必要なアクションを確認（理解）するのにいいんだ。＞cursor agentがバックグラウンドでうまくやってくれる。それって「うまくやる」の定義がすごく広いよね。結局、diffを確認して、各チャンクの周辺コンテキストもチェックしなきゃいけないし。生産性とか認知負荷みたいな指標で改善があるとは思えないね。何回もやり取りが必要なら特に。
いやいや、それはゼロサムゲームじゃないよ。何かと競ってるわけじゃなくて、何かと一緒に作業するんだ。ただ練習が必要で、少しばらつきがあって、無料じゃないツールってだけ。人生のほとんどのことと同じだよ。トウモロコシを買うとか、友達を持つみたいなもんさ。
建築の設計図ってすごく精密だよね。実際に建つものは、設計図にあるもののより詳細な形だ。でもTLA+の仕様と1MLOCのJavaデータベースはそうじゃない。設計通りの実装になってるか、指をクロスさせて願うだけ。物理的な壁が設計図通りの寸法か測れるけど、どうすればプログラムがTLA+の仕様に従ってるってわかるの？皮肉じゃなくて、これは大問題だと思う。Dafnyが答えじゃないかもしれないけど、洗練された方法を見つける努力をすべきだよ。ハードウェアではできるのに！ソフトウェアの方が本来は簡単であるべきなのにね。でもソフトウェアはワイルドウェストすぎるんだ。まずその問題を解決すべきだよ。
＞TLA+の仕様と1MLOCのJavaデータベースはそうじゃない。そんなことないよ。もちろん、それがそうだとTLA+の証明を書く人はいない。だって、もしリソースがあったとしても、そのROIは良くないからね。10時間の作業で4つの大きなバグを避けられるなら、さらに2つの小さなバグを避けるために余計に1万時間も働きたいとは思わないでしょ。ほとんどの人がROIが悪くなった時にやめて、完璧を目指さないのは問題じゃないんだ。問題は、完璧を保証するツールは何か（そんなものはない）じゃなくて、最小限の労力で最大数の（コストのかかる）バグを減らせるツールセットは何か、だよ。設計について厳密に考えるのを助けるツールは、そういうツールセットの一部なんだ。＞設計通りの実装になってるか、指をクロスさせて願うだけ。いつも自分が意図したものを実装したかどうかを検証するのと同じやり方だよ──指をクロスさせるだけじゃないよ──TLA+の仕事は、意図したものが（実装されれば）実際に機能することを保証することなんだ。＞Dafnyが答えじゃないかもしれないけど、洗練された方法を見つけるべきだ。TLA+はDafnyよりもはるかに強力な方法で洗練されてるよ。どちらも高レベルの設計から大規模で現実的なコードベースに、ましてや手頃な方法で、それをすることはできないけど、何もできないわけじゃない。それは問題かもしれないけど、僕らが解決できる問題じゃないし、解決できる他の大きな問題もあるんだ。
Emacsのマクロって同じじゃないんだよね。ファイル見てパターン見つけて、マクロを記録して、そのパターンが続くことを祈るしかない。LLMならこんなこと簡単にできちゃうよ。
Claude Codeは知らないけど、ビーチ休暇中に作ったウェブアプリのバグをCursorの”background agents”ツールで直してもらったよ。VM上でLLMエージェントが修正してプルリクまで。CI/CDでデプロイも楽ちん。ビーチで開発できるなんてマジでクレイジーだった！Rustfmtが面倒だったけど、AI活用は最高。休暇下手だけど、これはすごい経験だったよ、笑
grep-modeって正規表現の全一致をバッファに出してジャンプできるやつでしょ（俺はrg.el使ってる）。VSCodeの検索ツールとほぼ同じ。で、編集するにはマクロを記録するか手動でやるしかないじゃん？LLMが完璧だとは思わないけど、こういうリファクタリングには、あの2つより全然良い体験だと思うよ。
うーん、コード書く時間は減ったけど、レビューと修正にめっちゃ時間かかってるんだよね。全体で得してるかは正直微妙。でも、ボイラープレートが減って、より高レベルな開発ができるようになったから、今まで書かなかったようなコードも書けるようになったのは確かかな。
ポーカーって練習いるし、変動するし、タダじゃないじゃん。金賭けないと無駄に退屈な唯一のゲームだよ。LLMのワークフローは、DIYとかStack Overflow、ペアプロ、オフショアみたいな他のコード書く方法と競合してるんだ。
俺の開発環境はTermuxで完璧に動くんだ。Claude Codeもね。だから普通にclaudeって実行するだけで、デスクトップと全く同じように使えるよ。追記：明確化
評価はマーケットシェアと同じじゃないし、エンタープライズで形式的証明なんて法的な要件がない限りほぼないよ。TLA+モデルが書かれたJavaコードに正しくマッピングされてるか、どうやって検証するのか理解できないな。
プログラマーって（俺もそうだけど）、考えるのを避けるために何時間も作業しちゃうんだよね。”1時間のデバッグ／プログラミングが数分の思考を節約する”って格言があるけど、結局は考えなきゃいけないんだ。これ、良い観察だよな。プログラミングの過程が”考えない”行動を引き起こすみたいで、コンテキストスイッチを避けて”プログラミングフロー”に留まろうとするせいだと思うな。
俺個人のワークフローかもしれないけど、大幅な変更（変数名、依存関係の削除）はマクロで簡単だし、ピンポイントな変更（関数抽出、デカップリングなど）もある。どっちにしても、Emacs/Vimのツールと組み合わせれば編集は超速だよ。良いコードのメンタルモデルが要るけどね。まるでコードリストのムードボードを持ってるみたいだ。
俺のワークフローの肝は、問題を深く考えてないところからスタートすることだよ。まとまってない考えをテキストに書き出し、Claude CodeかGemini CLIに読ませてMarkdownで機能設計書を作らせる。それをレビューしAIに質問させて更新。ある程度固まったら、ローカルエージェントに技術設計書を書かせ、開発計画に分解して最初のフェーズを実装させるんだ。このエージェントはコーダーだけでなく、デザイナーやプランナーとしても優秀で、驚くほど良い選択をする。俺はいつでも方向転換できるし、問題が起きてもすぐ元に戻せるよ。
grep-modeとかのツールの話、それから動画も紹介しとくね。
https://youtu.be/f2mQXNnChwc?t=2135
https://youtu.be/zxS3zXwV0PU
Vim向けにはこれね。
https://youtu.be/wOdL2T4hANk
他のツールの標準検索・置換なんて、これらに比べたら全然だね。
もっとコメントを表示（1）
LLMアシスタントを使うとき、よく知ってる分野とそうじゃない分野で違いを感じる？LLMアシスタントはもっと広い文脈で機能的になるのを助けてくれると思うよ。それに、テストとレビューがめちゃくちゃ重要になるってのには全く同意だね。例えば、フロントエンドのデベロッパーがデータベースクエリを最適化するけど、存在しない変なクエリパラメータを渡されちゃうとかね。
昔、ソフトエンジニアだった頃、俺は高速化で評判だったんだ。顧客会議で副社長が「1秒短縮ごとに年間利益が100万ドル増える」って言って、速度にそんな価値を置くことにめちゃくちゃ驚いたよ。今でもキャリアのハイライトだね。記事の「速度への直接的な金銭的価値は稀」ってのは正しい。あと、誰かが冗談で「0秒で実行できたら無限に儲かる？」って聞いたら、誰も笑わなかったけど、俺は面白かったな。やあ、Doug！
「0秒で実行できたら無限に儲かる？」ってジョーク、意味がわからないな。1秒から0秒になっても、2秒から1秒になったのと同じで、年間利益に100万ドル増えるだけじゃないの？
もちろんジョークはくだらなかったね。でも、背景を説明すべきだったかも。俺たちは産業オートメーションソフトウェアを作ってたんだ。これが工場で動くんだよ。1秒短縮するごとに部品の製造時間が短くなって、工場全体の生産量が増えるんだ。ありえないレベルまで外挿すると、製造時間ゼロは工場あたりの無限の生産量ってことになるんだ（原材料は除くけどね）。
ああ、あれは言ってる本人だけが面白いと思ってて、まだ意味が通じないことに気づいてない類いのジョークだね。きっと後で、ホテルの部屋でシャワー浴びながら、たぶんスコッチ片手に「あれはマズかった」って思ったはずだよ。
そんなに人生って真剣に考えるものじゃないって俺は思うな。人を傷つけようとしてないなら、バカなこと言っても気にしなくていいんだよ。きっと彼らは最高に気分良くて、このくだらないジョークのことなんてすぐに忘れたはずだよ。
彼らのジョークは皮肉と解釈される可能性もあったね。皮肉を言うなら、自分が正しいって二重に確認したいものだよ。でも、真面目な会話にちょっとしたユーモアをもたらすのは良いことだって点では、俺も君に同意だよ！
インターネットのコメディアンには必読だよ。
https://whatever.scalzi.com/2010/06/16/the-failure-state-of-…
ありがとう！昔ながらのブログって恋しいね。
重要な顧客の重役の前じゃダメだよ。彼らはお金儲けに関しては驚くほどユーモアないからさ。
キャリアの初期はそういうジョークとかメールのコメント、魅力的だったなぁ。でも結局、特に”年上”とか数年キャリア積んだ人たちは、ほとんど冗談言いたがらず、会議の目的を達成することだけを求めてるって気づくんだよね。
うわー。そういう人たちとは絶対仕事したくないな。
プロセスが0秒で済むってことはさ、1年で31540000秒/0秒＝無限回実行できるってことだよね。利益も無限に増やせるってことになるじゃん。
いつから制約が”これを何回実行できるか”になったんだっけ？
原理的にはさ、『ここで節約された1秒が$xの価値がある』って言うのは、そのプロセスを実行するとお金が生まれて、時間を節約することで、より頻繁に実行できるからなんだよ。
少なくとも理論計算機科学ではよくある話だけど、それは全く別の話だね。
タスクスケジューリングシステムで仕事してた時、飛行機が1分遅れるごとに1万ドルかかるって言われたんだよ。これ90年代の話だから、それに合わせて調整してくれよな。
で、それ速くしたの？
残念ながら、単一のボトルネックはなかったんだ。俺だけじゃなくて、大勢でいろんな箇所のパフォーマンスを少しずつ改善するために必死で頑張ったよ。その複合的な改善は、確か顧客を満足させるものだったと思う。
P.P.S.のユーモアがマジで最高！めちゃくちゃ面白かったよ。
もしあのエンジニアの名前を思い出したらさ、そのジョークがマジでウケたって伝えておいてよ。
製品が期待外れだったのに、なんでそれを「ハイライト」って数えてるの？
ソフトウェアで「速さ」って明示的には求められないけど、誰もが当たり前だと思ってる。RustがRubyより遅かったら誰も使わなかったし、C++より速いって言ったから注目されたんだ。HNとか見てるとわかるけど、「速さ」こそがユーザーを惹きつける唯一の要素だよ。
言語なら速さもわかるけど、フレームワークだと話は別。みんなが求めてるのは機能や互換性で、Electronだって全然使われてるじゃん。
フレームワークで速さがどうでもいいってのは違うね。例えばReactはVirtual DOMが速いって言って注目されたんだし。機能や互換性も大事だけど、それは「速い」って前提があってこそ。だから「より速い」ってのがマーケティングでは超有効なんだよ。比較対象がないと、ユーザーは今のものが速いと思い込んじゃうもんね。
なのに、ウェブアプリとかはユーザー入力に数秒かかるくらいめちゃくちゃ遅いのが現状だよね。速さで人は惹きつけられるはずなのに、日々のPC作業は驚くほどノロノロなんだからさ。
「速い」ってのは比較対象がないと意味ないんだ。もし遅いウェブアプリしか知らなかったら、それが最高速だと思っちゃうでしょ？ユーザーは常に速さを求めてるんだけど、現状が一番速いって思い込まされちゃうんだよね。だから「速い」ってマーケティングがめちゃくちゃ効果あるんだよ。今のやつが実は遅かったって気づかされるからね。
「速さ」にこだわるのはHNにいる一部のプログラマーだけだよ。ほとんどのユーザーや開発者は、遅くても気にしないし、UIが良ければOKって感じ。Gitコマンド覚えたら10倍速いのに、GitHub Desktop使ってるデータサイエンティストとか普通にいるしね。
結論が違うよ。「速さ」が勝負を決めるのは、同じ機能をより速く提供する場合だけ。君の例にあるように、「Xと同じだけど、速い」って時にみんなそっちに飛びつくんだ。でもそれって、Xより速くなくても機能が増えたり、UXが良かったり、安くなったりする「X＋α」に人が移るかどうかは関係ない話だよね。
HNユーザーは、遅いモバイル接続の安価なデュアルコアスマホに3.8MBものJavaScriptを11秒かけて送って、150語と1枚の画像を見るだけの12秒セッションを「高品質なUX」だと思い込んでるみたい。速さは全然重要じゃなくて、トップ5にも入らないよ。みんな「利便性」に中毒になってるんだ。
もっとコメントを表示（2）
えー、HNの連中は速いのが好きなんじゃないかな、だって今のほとんどの技術は、もっと速くできるはずなのに、不当に遅すぎるんだもん。
「見て、コンポーネントを50回もすっごい速くレンダリングできるんだぜ！」
GitHub DesktopってGit CLIよりも差分レビューするのに断然良いよ。CLIツールを好む人と一緒に働いてきたけど、彼らはいつも全部addしてcommitしちゃうから、コミット前に視覚的な差分レビューしてれば防げたはずのエラーがPRに多くなるんだよね。
チャットボット使うのがマジで嫌なんだけど、そいつがタイピングしてるフリしたり（多分、事前に用意された定型文を探してるだけだろうけど）するのが超ムカつくんだよ…もう使わなきゃいけないってだけでイライラしてんのに、これ以上怒らせないでくれよ。
「見て、ユーザーがキーを押すたびにアプリ全体をものすごく速くレンダリングできるんだ！」
これってControlledコンポーネントとUncontrolledコンポーネントのすっごく面白い話だよね。ControlledはデータがuseState()で一元管理されるのが好きだけど、キーを打つたびに再レンダリングされちゃう。UncontrolledはReactと実際のフォームに状態が散らばるカオス状態になる可能性もある。このライブラリ（https://react-hook-form.com/）はUncontrolledフォームの問題に対する合理的な答えを持ってて、すごく良いと思うよ。
嫌だけど、これホントなんだよな。見てよ、俺の冷蔵庫に外の天気教えてくれるタブレットが内蔵されてるんだぜ。ちょっとうるさいとか、ドアがギシギシ言うのは気にしないってか。天気教えてくれるんだぜ！
Reactって遅いフレームワークの一つじゃないの？このリンク見てみてよ。
https://krausest.github.io/js-framework-benchmark/current.ht…
＞ you have to assume
そんなこと仮定する必要ないよ。JavaScriptが多くのケースで遅いこと、バンドルを減らさないとパフォーマンスが低下すること、コンテンツの量に関しては少ない方が良いってことは分かってるんだから。今のWebアプリが抱えるこの膨大な荷物が「必要」かどうかは主観的だけど、多くの開発者が違う方法を知らなかったり、暗黙の常識から外れるのを嫌ってるって点には同意できるな。
それ、本当にそうかな？みんな速度のためなら機能を犠牲にすることなんてしょっちゅうあるよ。Gitがbzr、hg、svn、darcs、monotoneなんかに比べて選ばれてるのを見ればわかるでしょ。
マジで速いってのはこれだよ。前にも言ったけど、Quest Diagnostics社の採血技師が使うアプリがすごいの。ブラウザのタブで動いてるみたいなんだけど、昔のWindowsのGUIアプリみたいで、署名パッドとかスキャナー、プリンターと連携するんだけど、爆速なの。ダイアログはすぐ出るし、データ入力しててもアプリが待たせることはまずない。一方で、俺が処方箋をリフィルしようとすると、ビーチボールが出たり、キラキラするボックスが出たり、空白とスクロールばっかりで超遅い。薬の名前と薬局の住所を読み込んで、4つイエスノー質問するだけなのに。Questのアプリ見てると、この時代にこんなに速いのがあるなんて口あんぐりだよ。
それって正直どうなの？俺が「速い」って言ったのは、インタラクティブな応答時間のことだってハッキリさせたはずだろ。それについては、確かに比較対象があるし、だいたいどのWebアプリもネットワークの往復時間でかなり制限されてて、インタラクティブ性が悪いんだ。十分なオフラインキャッシュを使うWebアプリなんて、マジでレアだよね。アプリが最速だなんて思い込むのもアホらしいよ。改善の余地はいつも絶対にあるのに、ただ優先されてないだけ。そこが肝心なポイントなんだよ。
みんなは意識してないかもしれないけど、速さってのは常に求められるものだと俺は思うな。Amazonが「常緑」として力を入れたもの、つまり「より速い配送、より豊富な品揃え、より低いコスト」みたいなもんだよ。
「速さ」は比較対象がないと意味がない、っていうのは違うんだよ。みんなが使ってる「遅い」って言われるアプリだって、実は代替案よりは速いか、何らかの速度面で優位性があるから使われてるんだ。つまり、ユーザーはもう自分の使い方に合わせて速度を最適化してるんだよ。「遅いアプリを使ってる人いっぱいいるじゃん！みんな速度なんて気にしないんだ！」って言うけど、ユーザーはもう自分のケースで速度を最適化済みってことを分かってないんだ。例えば、アプリAがBの50%の速さだとしても、Aが今すぐツールバーから使えるなら、Bの存在を知ってインストールして使い方を覚えるのに何時間もかかるよりずっといい。もしAとBが同じ条件で並んでたら、ユーザーは毎回Bを選ぶよ。慣れもあるしね。もしBがAより5%しか速くなくて、Bに切り替えるのに数日分の初期コストがかかるなら、それは隠れた速度コストだから、ユーザーはBがそれに見合うまでAを選び続けるんだ。全てが同じ条件なら、速度ってのはほぼ常にユーザーが選ぶ普遍的な特性なんだよ。ただ、速いものが存在していても、それがニッチで使いにくい（よく使われる「遅い」選択肢と条件が同じじゃない）からって、人々が速度を拒否してるわけじゃない。ただ、新しいことを学ぶのに最初は「遅く」感じるから、その時間を使いたくないだけなんだ。
それは、とんでもなくバカな基準と比べたら速いってだけだね。でも、Reactが速いって話が普及の大きな要因だったのは確かだ。
遅いWebアプリだって、たぶん前のソリューションよりは速いんじゃないかな。
Reactivityのアイデア自体は、Reactが流行る前のやり方よりもデータやDOM/UIの更新をより効率的に管理できるようにしてくれた。でも、Reactがきっかけでフロントエンドチームがバックエンドチーム（彼らはもっと保守的でパフォーマンス重視の傾向がある）から孤立するようになり、ビューのほとんどが不必要にブラウザのレンダリングに押し付けられ、すべてのページで20個ものJSONエンドポイントが使われたり、ポーリングやプッシュでオーバーヘッドが増えたりした結果、あらゆる面でWebを遅く、複雑にしたんだ。これは、デザイン管理が少し楽になった（しかも毎年変わる必要がある）代償だよね。VDOMフレームワーク自体の具体的な部分は、全体的にはそんなに重要じゃないのかも。もしその設計がそういったことを減らすように促すものなら別だけど（新しいものの多くはそうだけど、Reactは柔軟だからね）。
Hum、個人的にはGitは常にそれ以上の機能を持っていると思うよ。全部は知らないけど、Gitがリリースされたとき、特に分散型とrebaseっていう機能で他と差別化してたんだ。そしてhgやbzrがGitより機能が多いと思ったことは一度もないし、むしろ似たような機能で、Gitが同じ機能なのに速かったから勝った良い例だと思うね。
糖蜜だってパックごと投げれば速いよ！
冗談はさておき、その通りだよね－なんでこんなことになってるのかよく考えるんだ。人々が本当に速さを気にしてないのか、それともeコマースのウェブサイトとかはもうたくさんの要素で競争してるから（あるいは独占してるから）、速さがそんなに関係ないのか。
彼らは速さを気にするよ。だからページロードがたった数秒遅れるだけで、保持率が大きく落ちるのを見ているんだ。ただ、彼らは同じ言い方をしないだけだよ。iPhoneを買う理由を「最速のCPUと最も反応性の高いOSだから」とは言わないで、「ただ動くから」と言うだけだね。
個人的には、最高のインターフェースはMagitだよ。VS Codeでそのクローンを使ってるんだけど、ほとんど同じくらい良いんだ。CLIの速さを持ちつつ、個別のチャンクをステージしたりアンステージしたりするのがすごく簡単で、これってCLIユーザーがあまりやってない部分だと思うな。
これはよく知られてるけど、4年前のこの動画[1]はコンセプト実証なんだ。Casey MuratoriがMicrosoftの新しいWindows Terminalのパフォーマンスの遅さを指摘したんだけど、人々はもっと速いターミナルを作るのは不可能、実用的じゃない、維持できない、彼の「毎秒数千フレーム」という主張は大げさだって反論したんだ。ある人は「博士課程レベルの研究プロジェクト」だって言ったくらい。
これに対してCaseyは1週間もかけずにRefTermを作ったんだ。骨格だけのプロトタイプだけど、Microsoftの人が持っていたのと同じ制約で、Windows APIを使ったり、GPUレンダリングでDirectDrawを使ったり、ターミナルエスケープコード、色、点滅、カスタムフォント、フォントの代替、行の折り返し、スクロールバック、Unicode、右から左へのアラビア語の結合文字なんかを扱ったんだ。RefTermはWindows Terminalより10倍速いスループットで、毎秒6000～7000フレームで動いたんだ。シングルスレッドで、プロファイリングもチューニングも、高度なアルゴリズムも使ってないし、ごまかしもなし。速くするのに役立ったのは、たくさんの抽象化がないシンプルなコードと、一般的な文字の再レンダリングを避けるためのLRU（Least Recently Used）グリフキャッシュだけ。思いついた最初のやり方で書かれたんだ。当時、彼はそのYouTubeチャンネルで最適化に関する一連の動画を公開してて、「最適化」について話すのはあまりにも希望的すぎる、「非悲観化」について話すべきだ、と主張してた。ほとんどのソフトウェアが遅いのは、避けられない複雑さやメンテナンスを助けるために必要な抽象化があるからではなく、イデオロギー的な理由で追加された、メンテナンスもパフォーマンスも損なう大量の何もしないコードや抽象化レイヤーに窒息させられているからだってね。
[1] https://www.youtube.com/watch?v=hxM8QmyZXtg - ”How fast should an unoptimized terminal run?”
この動画[2]も具体的な詳細についてで、Jason Boothがゲーム開発の経験について話してる。データレイアウトやC++コードを変更して、より少ない作業で、よりキャッシュフレンドリーに、より良いメモリアクセスパターンで、複雑さをほとんど追加せずに、時には複雑さを取り除いて何桁も速くする方法の実例を話してるんだ。
[2] https://www.youtube.com/watch?v=NAVbI1HIzCE - ”Practical Optimizations”
Casey Muratoriの動画を見るのは、好きでもあり嫌いでもあるんだ。好きなのは彼が日常的にこういうことをしてくれるから。嫌いなのは、職場で同じような会話をすることがあまりにも多いのに、誰も気にしないからなんだ。
最近、HNで誰かが彼らのワードゲームCobble[1]を投稿してたんだけど、このゲームはいくつかの文字を与えられて、与えられた文字をすべて使って2つの英単語を見つけ、その2つの単語を合わせたものができるだけ短くなるようにするっていうチャレンジなんだ。
素朴な総当たりソルバーだと、Cobbleの6万4千語のワードリストを使って、すべての単語とすべての単語を比較するから、6万4千 × 6万4千 ＝ 40億回のループになるんだ。そして内側のループでは、結合された文字をループする。結合された単語が平均10文字だとすると、コード構造だけで400億回の操作になるし、それに加えて文字のテストやカウント、カウントを保存するデータ構造もある。現代のコンピューターならマイクロ秒で解けるはずのパズルが、数秒から数分の作業になるんだ。
ごく単純に説明できる問題で、ごくわずかなデータ、そして4行のネストされたループなのに、現代のCPUを数分間窒息させるほどの作業を生成できるっていうのは、いつも地味に面白いなと思うんだ。そして、3Dゲームがミリ秒でどれだけの作業をこなしているかを考えると、それは1960年代のアルゴリズム研究がいかに印象的だったかを際立たせるよね。初期のコンピューターで何かを合理的な時間で実行する方法を見つけたんだから。ましてや、複雑な問題パターンを高速に通過する方法を見つけたなんて。あるいは、存在する可能性のある何十億もの問題の中で、人間の心とコンピューターがアプローチできるものを見つけたのかもしれないね。
[1] https://news.ycombinator.com/item?id=44588699
もちろん、Cobbleパズルの最適な解法は、君が説明したような計算を実際には必要としないよ。単一のパスで限られた候補単語のセットを見つけて、それらで解決策を出すことができるんだ。
うん、Casey Muratoriが「普通の開発者はパフォーマンスを気にする必要はない、コンピューターは十分速い、パフォーマンスはニッチな問題だ」って主張する人がいるって言ってたけど、俺はどれだけ少ないデータで－6万4千件なんて現代人にとっては何でもない量なのに－速い答えを求める人は、リストを前処理したり、有望な候補を先にソートしたり、速い言語を使ったり、並列処理に気づいたり、といったパフォーマンスについて考えざるを得なくなるのか、ってことをただ考えてたんだ。
Windows TerminalをRefTermに置き換えられる世界に住んでみたかったな－もしそうなったら、RefTermが、WinTermを長年遅くしてきた何十億もの機能から忍び寄る微妙なバグの一つを適切に再実装しなかったせいで、Fortune 500の企業が操業停止に追い込まれるまでに何時間かかるかを測るためだけにね。
[1] https://xkcd.com/1172/
