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

• 差分^[1] を表示
• 現在との差分^[2] を表示
• design010^[3] へ行く。

* アプリが小さくなっていくことの意味
-(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はよくやったと賞賛されるべきだろう。でも、単にやるべきことを（やっと）やっただけだから、やっぱり当然ということで、賞賛って言うのもなんか違うけど。・・・僕は自分の過去のヘボアプリを自分で直しただけだから、ただの「自業自得」？
*** (4) 2008.12.30追記
-プログラムは結局CPUに対する作業手順を並べたものに過ぎない。これが大きいということは、手順が複雑で長いということだ。一方で「ぐいぐい01」アプリとして全く同じ処理を記述すると手順は短く簡潔に書ける。どちらがあるべき姿だろうか。
-これはあるインタビューアから聞いた話だが、有名な問答として、こんなものがあったらしい。
--質問「現在ソフトウェアエンジニアリングはどこまで進んだと思いますか？」
--回答「エンジニアリングとは不要な要素を排しその上で残った要素がどのような役割を持っているかを研究することであるから、現状でソフトウェアエンジニアリングなど始まってもいない」
-この回答者は現状ではまったく「不要な要素を排し」ていないと言いたいのだと僕は感じたのだが、しかしこの回答者が言うところの不要な要素というのが、僕がここで書いているムダに長くなったコードを指しているかどうかは分からない。もっと別のことを想定して言っていたのかもしれない。
-それでもとにかく僕がコードのムダを指摘したのは間違いのないことだし、それはきっとエンジニアリングに少しは役立つだろう。その効果は3,072を基準としても（繰り返し言うがこれでも世間の平均よりは十分に小さい）、その差は3,000バイトだ。どんな天才でも72バイトから更に3,000バイト減らすことはもちろんできないから、一番多くムダを刈り取ったのは間違いなく僕ということになる。

* こめんと欄
#comment

• design010 のバックアップ一覧^[6]
• design010 のバックアップソース(No. All)
  • 1: 2008-12-28 (日) 11:48:08^[7]
  • 2: 2008-12-28 (日) 12:30:02^[8]
  • 3: 2008-12-28 (日) 12:30:02^[9]
  • 4: 2008-12-28 (日) 12:30:02^[10]
  • 5: 2008-12-30 (火) 10:50:25
  • 6: 2008-12-30 (火) 14:28:25^[11]
  • 7: 2009-01-03 (土) 13:25:56^[12]
  • 8: 2009-01-03 (土) 15:48:15^[13]
  • 9: 2009-11-17 (火) 12:08:09^[14]
  • 現: 2024-01-08 (月) 12:58:55^[15] k-tan^[16]