2: 2008-12-28 (日) 12:30:02  |
3: 2008-12-28 (日) 12:30:02 |
| | -たとえばmakefontというアプリを例にとろうと思う。これはテキストファイルで書かれたフォントのデータをただバイナリに変換するだけの、大して芸のないプログラムだ（でもてっとりばやく8x16のフォントデータを作るには結構役立つ）。このプログラムは最初tolsetを使ってwin32用に書かれた。これをtolsetでmakeすると（そして当然UPXすると）COLOR(#ff0000){3,072バイト}だった。これでも普通の人が作る場合に比べればダントツに小さい（かなり多くの人はhello程度でも5KBくらい平気で使う）。 | | -たとえばmakefontというアプリを例にとろうと思う。これはテキストファイルで書かれたフォントのデータをただバイナリに変換するだけの、大して芸のないプログラムだ（でもてっとりばやく8x16のフォントデータを作るには結構役立つ）。このプログラムは最初tolsetを使ってwin32用に書かれた。これをtolsetでmakeすると（そして当然UPXすると）COLOR(#ff0000){3,072バイト}だった。これでも普通の人が作る場合に比べればダントツに小さい（かなり多くの人はhello程度でも5KBくらい平気で使う）。 |
| | -このプログラムはやがて「ぐいぐい01」のAPIを使うようにソースを書き改められて、abcdw005～abcdw006向けのバイナリが、COLOR(#ff0000){691バイト}でリリースされた。 | | -このプログラムはやがて「ぐいぐい01」のAPIを使うようにソースを書き改められて、abcdw005～abcdw006向けのバイナリが、COLOR(#ff0000){691バイト}でリリースされた。 |
| - | -さらにabcdw008で実装予定のAPIを使う形に修正されCOLOR(#ff0000){207バイト}になり、ついにASKAで書き直されてCOLOR(#ff0000){75バイト}になった。 | + | -さらにabcdw008で実装予定のAPIを使う形に修正されCOLOR(#ff0000){207バイト}になり、ついにASKAで書き直されてCOLOR(#ff0000){72バイト}になった。 |
| - | -こうして3,072バイトもあったものが、75バイトになった。機能は全く失われていない。この差し引き2,997バイトは一体何なのか。それを考えてみようと思う。 | + | -こうして3,072バイトもあったものが、72バイトになった。機能は全く失われていない。この差し引き3,000バイトは一体何なのか。それを考えてみようと思う。 |
| | *** (2) | | *** (2) |
| - | -僕の考えるところでは、これはムダである。API設計者とコンパイラ開発者とアプリ開発者がしかるべき努力をすれば75バイトでできるプログラムを、三方の怠惰（いわゆる手抜き）によって3,072バイトにしてしまっていたのだ。 | + | -僕の考えるところでは、これはムダである。API設計者とコンパイラ開発者とアプリ開発者がしかるべき努力をすれば72バイトでできるプログラムを、三方の怠惰（いわゆる手抜き）によって3,072バイトにしてしまっていたのだ。 |
| - | -このままだとなんか毎度のwin32批判に見えて僕の趣旨が誤解されるかもしれない。じゃあこうしよう。3,072バイトから691バイトへの改良をひとまず脇においておいて、691から75バイトへの変化だけに注目しよう。 | + | -このままだとなんか毎度のwin32批判に見えて僕の趣旨が誤解されるかもしれない。じゃあこうしよう。3,072バイトから691バイトへの改良をひとまず脇においておいて、691から72バイトへの変化だけに注目しよう。 |
| - | -691から207への改善の理由を考えれば、これはAPIの設計を（さらに）まじめにやり、そのAPIを利用するようにアプリを書き改めたからに他ならない。明らかに手抜き度が減少したから改善したのだ。また207から75への改善も、「レジスタの使い回しなどで頭を使わなくてもとりあえず動くプログラムが作れる」C言語から「それらに配慮しなければいけない代わりに小回りのきく」ASKAで書き直したからこそ達成されたのだ。これも手抜き度の減少したからだ。 | + | -691から207への改善の理由を考えれば、これはAPIの設計を（さらに）まじめにやり、そのAPIを利用するようにアプリを書き改めたからに他ならない。明らかに手抜き度が減少したから改善したのだ。また207から72への改善も、「レジスタの使い回しなどで頭を使わなくてもとりあえず動くプログラムが作れる」C言語から「それらに配慮しなければいけない代わりに小回りのきく」ASKAで書き直したからこそ達成されたのだ。これも手抜き度の減少したからだ。 |
| - | -ここから演繹すれば、つまり僕たちが本来75バイトで十分なものを3,072バイトも消費して使わされていたのは、ありとあらゆる手抜きが集積していたからである。3,072が本来のサイズで75ががんばった結果なのではなく、75こそ本来の姿で3,072は手抜きに手抜きを重ねた結果なのだ。通分すれば2/3になるのに、その通分の労をケチって、巨大な分子と分母のままで「はい、もう完成」としてしまったのだ。 | + | -ここから演繹すれば、つまり僕たちが本来72バイトで十分なものを3,072バイトも消費して使わされていたのは、ありとあらゆる手抜きが集積していたからである。3,072が本来のサイズで72ががんばった結果なのではなく、72こそ本来の姿で3,072は手抜きに手抜きを重ねた結果なのだ。 |
| | *** (3) | | *** (3) |
| - | -僕は非難されるべきだと思う。まあオープンソースで品質未保証だから、文句を言われる筋合いはないのだけれど、しかし75バイトで済むものを691バイトや3,072バイトでリリースしたというのもまた事実だ。これは絶対に褒められたことじゃない。ただabcdw008ができるまで待たなくてもよかったということだけが、せいぜいのいいわけだろう。・・・非難が無理だとしたら、せめて75バイトのmakefontはよくやったと賞賛されるべきだろう。でも、単にやるべきことを（やっと）やっただけだから、やっぱり当然ということで、賞賛って言うのもなんか違うけど。・・・僕は自分の過去のヘボアプリを自分で直しただけだから、ただの「自業自得」？ | + | -3,072バイトのmakefontにせよ、691バイトのmakefontにせよ、リリースしたのは僕なのだから、僕は非難されるべきだと思う。まあオープンソースで品質未保証だから、文句を言われる筋合いはないのだけれど、しかし72バイトで済むものを691バイトや3,072バイトでリリースしたというのもまた事実だ。これは絶対に褒められたことじゃない。ただabcdw008ができるまで待たなくてもよかったということだけが、せいぜいのいいわけだろう。・・・非難が無理だとしたら、せめて72バイトのmakefontはよくやったと賞賛されるべきだろう。でも、単にやるべきことを（やっと）やっただけだから、やっぱり当然ということで、賞賛って言うのもなんか違うけど。・・・僕は自分の過去のヘボアプリを自分で直しただけだから、ただの「自業自得」？ |
| | * こめんと欄 | | * こめんと欄 |
| | #comment | | #comment |
