ハクソク

世界を動かす技術を、日本語で。

ウィルスの復讐

110日前原文(jmoiron.net)

概要

  • Niklaus Wirth による「A Plea for Lean Software」と Wirth's Law の紹介
  • ソフトウェアの 複雑化と遅延、ハードウェア進化の関係性
  • クラウドコンピューティング による新たなトレードオフ
  • ORMの使い方 や LLM活用 におけるコスト意識の重要性
  • 効率性と利便性の バランス、現代ソフトウェア開発の課題

Wirthの法則とソフトウェアの膨張

  • Niklaus Wirth のエッセイ「A Plea for Lean Software」で提唱された Wirth's Law ソフトウェアがハードウェアの進化以上の速さで遅くなっている現象
  • 1970年代のテキストエディタやOSは 数KB で動作 現代の同等ソフトは 数MB を必要とする現状
  • 機能追加（ウィンドウ、カット＆ペースト、アイコン等）による 利便性向上 その一方で ランタイムコスト やパフォーマンス低下
  • 技術的観点だけでなく 社会的価値 も評価対象とすべきという指摘
  • Wirth の思想が後の開発者や筆者自身の設計思想にも影響

入力遅延と複雑性のトレードオフ

  • Dan Luu による2017年の入力遅延調査 Apple 2e（1983年）が最も低遅延という結果
  • 入力処理パイプラインの 複雑化 による遅延増加 柔軟性を得る代償としての レイテンシーコスト
  • 現代の低遅延システムは 複雑性の追加 で問題を解決 単純化ではなく、より高度な仕組みの導入による対応

クラウドコンピューティングの時代

  • 1995年当時、インターネット企業の インフラ要件 はシンプル 利用者数も少なく、 高可用性 も未要求
  • 2010年には利用者が 20億人 に増加 システム規模や 可用性要件 が飛躍的に拡大
  • データセンター運用 の複雑化、初期投資・運用負担の増大
  • クラウドサービス （AWS等）の登場により 柔軟なリソース利用・コスト最適化が可能に
  • クラウド導入で パイプラインの複雑性 は増すが、 アクセシビリティやリスク低減という明確な価値

ORM利用と「悪いWirthトレードオフ」

  • Djangoアプリ開発時の経験 ORMの 自動外部キー読込 によるパフォーマンス劣化
  • テンプレート内での 多重ループ が DB負荷増大 を招く
  • 全体最適化が難しい複雑なテンプレート構造
  • キャッシュレイヤー 追加による問題解決 複雑性を増やしてパフォーマンスを確保
  • 安易な利便性追求が 予想外のコスト を生む例

LLM時代の新たなコスト認識

  • LLMの登場で 非エンジニア層 もプログラミング的体験が可能に
  • LLMの利用は 計算資源消費 が非常に大きい 単純計算ですら 従来のPCの何万倍ものリソース を消費
  • ORM同様、 コスト意識の欠如 が無駄な消費を招くリスク
  • LLMに直接タスクを依頼するのではなく スクリプト生成 に活用し、効率的な自動化を図る手法が主流
  • LLMによるタスク実行は 信頼性や再現性 に課題 決定論的なプログラム構築の重要性

LLM利用の失敗例と教訓

  • LLMでレシピデータ変換を依頼したが 低速かつ不正確 な結果、手作業以下の効率
  • エンジニアがLLMを評価する際は スクリプト生成 等の補助的用途が中心
  • LLMを繰り返し使うタスクでの コスト爆発 例 Twitterの事例：リマインダー用エージェントがAPIを大量呼び出し 一晩で 約20ドル の無駄な課金発生

現代ソフトウェア開発における本質的課題

  • ソフトウェアの 複雑性増加 と 利便性向上 のトレードオフ
  • 技術的効率だけでなく 社会的価値 の評価視点
  • 新技術導入時の コスト意識 と 設計判断 の重要性
  • Wirth's Law の現代的再解釈と、 効率・利便性・持続可能性のバランス

このように、Wirthの法則は今なお現代のソフトウェア開発において重要な示唆を与えている。ソフトウェアの肥大化や複雑化は避けられないが、利便性・アクセシビリティ・社会的価値を理解しつつ、コストと効率のバランスを意識した設計判断が不可欠である。

Hackerたちの意見

著者は、アクセスしやすくするためにソフトウェアのレイヤーが多く関与していると言っているけど、私の経験では、ほとんどの場合はアプリ開発者が怠けているだけだと思う。例えば、Claude CodeがReactを使ってターミナルで何を描画するかを決める事例があって、それが遅延を引き起こしているんだ。開発者たちは、60 FPSを達成するのに「たった」16.7ミリ秒しかないと嘆いている。ターミナルでね。ターミナルはそれ以上のことができるはずなのに。Primeagenが示した例[0]では、ターミナルの変更が多いアプリケーションでも、何も比較せずに新しい変更を表示するだけで、かなり速く動くってことがわかるよ！ [0] https://youtu.be/LvW1HTSLPEk

└

そうだね、これの多くは制度やインフラの慣性、抽象化の負債、第二次以上の無知、専門性の狭まりに起因していると思う。今これを作っている人たちは、Reactなどを使いこなせるレベルには達しているけど、彼らの焦点は機械学習にあるべきだよね。ターミナルの処理を低レベルで超高速にできる人たちは、今は引退して島に住んでいるか、亡くなっているか、こういう会社が求める他の専門性を持っていない。ユーザーは、アプリが10倍速くビルドされるなら、ターミナルでの16.7ミリ秒なんて気にしないから、そのトレードオフは明らかだよ。

└

もっとグラフィックスプログラマーがアプリ開発に飛び込んでくれたらいいのに。16.7ミリ秒は彼らにとっては大きな時間だし、60フレーム毎秒なんて目標としては低すぎる。144じゃなきゃダメだね。

└

これ、1980年代の技術みたいだね。逆に、動画の中の人がリモート接続で帯域制限のある環境でアプリを動かしてたら、diffingの方がパフォーマンス良かったかも。俺は職場に1GbpsのGoogleファイバーがあるけど、VPNの帯域が時々数百kbpsに落ちることもあるし、もっとひどい時もある。

記事の高レベルなポイントはよくわからないけど、プログラマーとしてAIエージェントを使って正確で効率的なプログラムを書く方がいいっていう観察には同意するよ。エージェントにその作業をさせるのが理想だけど、エージェントにやらせたいことがプログラムとして表現しやすいわけじゃない。でも、コンピュータが得意なことはわかってるよね。もし正しい結果に賭けなきゃいけないなら、AIモデルに5000の数字を「頭の中で」ソートさせるのと、ソートするプログラムを書いてそれを実行させるの、どっちがいいと思う？これは明らかだと思うけど、最近はプロの人たちがAIモデルを変なところに挿入して、GenAIを取り入れてるって言ってるのをよく見るよ。

面白い記事だったし、LLMの修正や執筆の痕跡が全くないものを読むのは新鮮だった。LLMにアプローチするための複数のモードがあるという有益な洞察が含まれていて、それが使用する際の結果の大きな差を説明するのに役立つ。余談だけど、この記事は「2月2日」って日付がついてるけど、フッターには「2025」って書いてある。これは古い生成されたフッターで、2026年のことを指してるのかな？

実際の制約は、人々が結果を待つことにどれだけの時間をかけるかだよね。結果が本当に良いと期待されるなら、人々は長い時間待つだろう。だから、エンジニアはものが動き始めたらすぐに次の機能に移るんだ。人々は、少しでも速くできる可能性があっても、あまり気にしないから、遅すぎなければそれでいいんだよ。技術的に可能かどうかは関係ない。実際、動きすぎるコンピュータは怪しまれるかもしれないし、結果を出すのに時間がかかるのは一種の作業証明だよ。

└

技術的に可能かどうかは関係ない。実際、動きすぎるコンピュータは怪しまれるかもしれないし、結果を出すのに時間がかかるのは一種の作業証明だ。最近、複雑なリクエストの後にLLMが数秒でテキストを吐き出すと、この先入観にハマってしまうことがあったよ。

└

人々は単に気にしていないと思うけど、それは正しくないと思う。特に一般の人にとってはね。5秒かかることが、50ミリ秒でできるはずなのに、その痛みは微妙で、無視されたり、気づかれなかったりするんだ。100個のことを連続でやっているときに、5秒かかる代わりに50ミリ秒でできることがあるって知らなければ、その痛みについて文句を言うべきだとも思わないよね。

LLMは、効果的に使い方を学べばとてもクールで強力なツールだよ。でも、ほとんどの人はそうじゃなくて、リソースやトークンを最大限に使いながら満足のいかない結果を出す使い方をしていると思う。その原因は、大きなモデルを持っている会社が実際にはトークン販売ビジネスをしていて、自社のモデルを万能の問題解決者や生活改善者としてマーケティングしているからだよ。

1980年代後半に8MBのRAMで何ができたか見てみてよ: https://infinitemac.org/1989/NeXTStep%201.0 上のリンクをクリックすれば、ブラウザでNeXTStepを実行できるよ。数週間前にはFrameMakerも動かせたんだ。1980年代後半のFrameMakerには驚かされたよ。今のMicrosoft Wordは、1980年代後半のFrameMakerには全然敵わない！ 編集: FrameMakerの起動方法はこうだよ: FinderでNextDeveloper > Demos > FrameMaker.appに行って、デモ文書を開いてデモ文書のページを見てみて。驚く準備をしておいて。1989年には64MBのRAMでそれができたの？？この37年間で業界は後退してるよ。Microsoft Wordは、ここ数十年競争がないせいで停滞してる。

└

これが今撮ったFrameMakerのスクリーンショットだよ: https://imgur.com/a/CG8kZk8 1980年代後半に可能だった素晴らしいページレイアウトを見てみて。今のWordはこれができる？

└

当時はRAMとHDDが不足していたから、特にAppleやMicrosoft、Borlandなどのエリート開発者たちは、できる限りパフォーマンスを引き出すために最後の一歩を踏み出していたと思う。今の開発者と比べて、同じアプリケーションでもずっと多くの時間をかけていたんじゃないかな（例えば、Win 2000のネイティブWindowsプログラムとWin 11の再作成されたプログラム）。今のビジネスは単に気にしていない。彼らは夢見ていた封建的な拠点をすでに達成していて、パフォーマンスに関連するものでない限り、あまり時間をかける「ビジネスバリュー」はないからね。今のハードウェアはNeXTStepやIntel i486の時代の100倍も複雑だし、70年代や80年代からのベテランたちはその複雑さに徐々に適応できるけど、新人はただ泳ぐか死ぬしかない。おもちゃのコンピュータやおもちゃのOSでのトレーニングは、今直面している巨大なアーキテクチャや複雑さに比べたら無駄だからね。どうだろう。ハードウェアの進化がもう少し遅ければいいのにと思うけど、結局そうなるんだろうな。最近MITのxv6ラボを終えて、カーネルを少しハックできると思ったから、別のLinuxデバイスドライバのクラスを受けたんだけど、OMG、複雑さが理解を超えてる。MakefileやKBuildのことも全然わからない。だけど、Linux 0.95やLinux 1.0から始めていたら、サブシステムに入り込むのもずっと楽だっただろうし、徐々に適応できたと思う。だから、Linux 0.95に戻って、もっとシンプルなデバイスドライバ（例えばキーボード）に集中して、すべての進化を読むために1年か2年のトレーニングが必要だと思う。普通の人には他に方法がないからね。

└

それに、TeXview.appもあったし、少なくとも受賞歴のあるTeXshop.appにインスパイアされたし、Altsys VirtuosoはMacromedia Freehandになった（Freehand 3の後継として作られた）--- 最近はCenon https://cenon.info/ が使えるけど、あまり良くないし機能も少ない - WriteNow.app --- これもMacアプリだったけど、NeXTの実装が一番好きだった --- WNはおそらくAssemblyで書かれた最後の大規模商業アプリだった（約10万行）まだNeXT Cubeが起動しなくなったのは悲しいな...

└

1989年に64MB？1999年にはそんなに悪くなかったね！

└

まあ、実際にはFrameMakerの最初のリリースは、4MBの（拡張不可でハンダ付けされた）RAMを搭載した16MHzの68020のSun 3/50ワークステーションで作られたんだよ。ほとんどの顧客は同じモデルを使ってて、そこそこ大きな文書を楽に扱えてた。でも、何百ページもある文書にはあまりスペースがないから、FrameMakerを使って製品のユーザーマニュアルを書いてた典型的な顧客は、個別に編集した章のファイルをまとめるために「ブック」ファイルを使わなきゃいけなかったんだ。で、たまに「生成」ボタンを押して、章ごとのページ番号を一致させたり、すべての参照を更新したり、目次や索引を生成したりする必要があったんだよ。どういたしまして。でも、潜在的な問題があって、章1が章2を参照してる場合（「209ページを見て」）でも、章2の編集によって参照されてる内容が210ページになっちゃうことがあるんだ。で、フォントによっては「209」が「210」よりも幅が広いことがあるから、生成処理中に参照が「210ページを見て」になっちゃうことがあるんだよ。でも、細いテキストが含まれる段落が1行減る可能性もあるから、章1が1ページ少なくなって、章2が1ページ早く始まって、また参照されてる内容が209ページに戻る可能性もある。だから、ループに入っちゃうんだ。この問題は非常に珍しいケースだったから、他の誰もそれに気づかなかったし、ましてや検出されたこともなかった。 fancyなエラーメッセージは面倒だったから、ただ「Degenerate」っていう一言のポップアップを出してたんだ。数年後、顧客が電話してきて、ソフトウェアが自分を「degenerate」って呼んでるって怒ってた時はちょっとパニックになったよ。（しかも実際の例じゃなくて、別のバグがそれを引き起こしただけだった。）

└

あんなデカいの、俺の360kフロッピーには入らないよ！

└

MS WordとFrameMakerは同じ市場の競合とは見なされてなかったよ。Aldus Pagemakerの方がFrameMakerに近い競合だったけど、Pagemakerは市場の下位層をターゲットにしてた。MS Word for Windows 1.0のレビューを見てみて。ベンチマークに挙げられてる競合にはAmi Proや、WordPerfect、MS WordのDOS版が含まれてるよ。レビュー：https://computerhistory.org/wp-content/uploads/2019/08/Infow...

└

1989年に彼らのワークステーションに64MBのRAMがあったとは絶対に思えない :)

LLMはまだ非常に計算コストが高い。AIに2 * 3は何か聞いてみて、数秒待つだけで... でも、目の前のコンピュータはこの計算を1秒間に10億回もできるんだ。これは苦い教訓の裏側だね。すべての注意がAIアルゴリズムに向けられ、目の前の特定のものには向かないと、効率がひどくてWirthが復讐することになる。epsilonより大きなスケールでは、可能な限りLLMは答えを生成するのではなく、それを生成するコードを生成するのにより良く活用される。苦い教訓は有効だけど、少し距離を置いたレイヤーでね。

ここにはたくさんの良い考えがあるね。 > AIに2 * 3は何か聞いてみて、数秒待つだけで、数ミリリットルの水とテレビでTikTok動画の5%を見るための電力があれば、教えてくれるよ。これが、LLMをホストして時間を売っている多くの企業が望んでいることかもしれないね。さあ、モンスタートラックを1マイル走らせてファストフードを取りに行こう！ 消費が増えれば増えるほど、そういう企業のポケットにお金が入るからね... > 人々の本能はAIに自分のために仕事をさせることだよね。自分で仕事をする方法をAIから学ぶことじゃない。自分の学びを改善するのがLLMで得られる数少ないメリットの一つだと思う！

単に素晴らしいエッセイだね。データベースの特定のエッジケースを最適化するソフトウェアエンジニアだけでなく、より広い技術的なオーディエンスに向けて書かれている（そして、あなたたちのような素晴らしい才能を持った人たちには敬意を表するけど、時々あなたたちのエッセイは読みづらいことがある）。OPはキャッシングの準備をしておいたほうがいいね、これはシェアされるだろうから。

この話題でオベロンのことを誰も言わないのが意外だな：https://oberon.org/en Raspberry Piでエミュレーターじゃなくて、ちゃんと動くドライバーがあればいいのにって思うよ：http://pascal.hansotten.com/niklaus-wirth/project-oberon/obe...

└

本当にRaspberry Piでエミュレーターじゃなくて、ちゃんと動くドライバーがあればいいのに：まさにその通り。Piシリーズは小さくて安いコンピュータの期待を再定義したよね。でも、巨大で複雑なOSの簡易版を動かしてるだけなんだ。普通の人が読んで理解できるような小さなOSを作るべきだと思う。Project Oberonのコアは約4000行のコードで、コンパイラ、エディタ、ウィンドウ型TUI OS、ソースを保存したり、バイナリを作成・保存したり、実行したりするためのOSが含まれてる。Oberonの後継はA2で、Bluebottle GUIを搭載してる。これにはSMP対応で、TCP/IPネットワークスタックやシンプルなHTTPウェブブラウザもあって、メールもできるんだ。そのカーネルは約8000行のコードだよ。Raspberry Pi用のUltiboベアメタルFreePascalシステムは：https://ultibo.org/ ...オーストラリアの開発者が作ったもので、彼ならネイティブA2ポートもできると思うし、Ultiboのコードやドライバーを再利用できれば、そんなに時間もかからないんじゃないかな。彼がいくら欲しいか、クラウドファンディングできる方法があるか気になるな…