ページへ戻る

− Links

 印刷 

design010 のバックアップソース(No.4) :: OSASK計画

osaskwiki:design010 のバックアップソース(No.4)

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

« Prev[4]  Next »[5]