カンタンなんがええのにワケわからへんもんをつくる

We Who Value Simplicity Have Built Incomprehensible Machines

8086のAAA命令っちゅうやつは、まあ昔はよかったんや。1970年代は、二進化十進数、つまり一バイトで二桁を表す必要がある時代やった。BCDって何がそんなにええんや？　おっきな数字が、マルチバイトの掛け算とか割り算とかせえへんでもカンタンに表示できるんや。加算した後はASCII化（ASCII Adjust After Addition）やからAAAっちゅうわけで、x86ハードウェアに三十年以上前から居座っとる。そこらにあるi7プロセッサーは全部、AAAをマイクロコードでエミュレートしとる。

Cライブラリ関数のmemcpyっちゅうやつも、まあ昔はよかったんや。memmoveはそこそこ早くて、もうちょいと器用なやっちゃ。コピー元とコピー先がオーバーラップする場合でもちゃんとええ感じにやってくれる。でもな、そのために数命令ほど余計に必要ってのは、そりゃ気にするがな、もういっこ、最適化されたメモリーコピールーチン、つまりmemcopyがほしいがな。そやろ。そないなわけで、ワシら似たような関数が二個もあつこうてるわけや。まあ、未だにオーバーラップ対応の必要がないmemcpyが重宝される場合もあるわけやけど。

libpngっちゅうやつも、まあ昔はよかったんや。つまりあれやがな、カンタンでプラットフォーム非依存な方法でPNGファイルの読み書きしまっせちゅうやつやな。まあ、実際、動くし、プラットフォーム非依存なわけやけど、でもな、このワシがあんだけドキュメント読んで、いまだに画像一枚読み込む方法が分からへんのは、まあ、あのライブラリぐらいなもんやで、ホンマ。ワシ、いつも「カンタン　libpng　サンプル」でググって見っけた二十行ぐらいの関数をコピペしとるんや。

UNIXのlsっちゅうやつは、まあ昔はよかったんや。いかにもUNIX風のやり方っちゅうやつやな。ひとつのことだけめっちゃようできるちっぽけなツールや。つまり、ファイル名の一覧を表示するっちゅうことや。せやけど、どのファイル名をどんなフォーマットで表示するかってことで、35個以上ものコマンドラインスイッチがあるんやで。あんまり恥ずかしなったのか、BSD版のmanページのいっちゃんはじめには、「下位互換性を維持するため、オプション間の関連性は非常に複雑である」って書いてあるんやと。

どれひとつとっても、今のコンピューターをワケわからへんもんにはしてへん。これだけの理由で、SDKに200ページもの概要を説明するドキュメントがついてきて、APIを説明する数千ページのドキュメントのどのへんを読めばええか説明する理由にはなってへん。

けどな、こういうむつかしいことが積み重なり、そもそも最初からいらへん一つの機能がふたつの機能で分かれたり、誰かのすでに書いたコードをぶっ壊すかもしれへんからと直さずいたから、積もりに積もってまともやなくなるんや。ワシらが満足している裏で、システムが理解できひんようになっとる。

ワシらのせいや。ワシらカンタンなんがええといってるやつらのせいや。そんなに意味あれへんしょーもない些細な設計を行なっている最中に、ワシら止められたはずやないか、「まちなはれ、やめなはれ」と。まあ、ぐうたらで、変更した方が楽な場合でもや、何千ものユーザーが出てきて、いまさら後にひけんようになる前に、問題を修正できたはずやないか。なんでワシら、せえへんかったんや。

お前らこれきにいったんなら、演算力は無限になっとるってのも気にいるとおもうで。

本の虫: 演算力は無限になっとる