9: 2009-11-17 (火) 12:08:09  |
現: 2024-01-08 (月) 12:58:55 k-tan |
| - | * アプリが小さくなっていくことの意味 | + | TITLE:x |
| | + | * アプリが小さくなっていくことの意味 [#cc93a665] |
| | -(by [[K]], 2008.12.28) | | -(by [[K]], 2008.12.28) |
| - | *** (0) | + | *** (0) [#h65fac35] |
| | -これは当初「川合のぼやき」に書こうかどうか迷った内容のものを書くことにしたわけだけど、ここは僕のホームページではなくOsaskWikiなので他の誰が書いてもいいものだと思う。 | | -これは当初「川合のぼやき」に書こうかどうか迷った内容のものを書くことにしたわけだけど、ここは僕のホームページではなくOsaskWikiなので他の誰が書いてもいいものだと思う。 |
| | -ただこのシリーズの趣旨としては、OSASKの設計に関する話を書いているので、他の人が書く場合もそれには準じてほしい。で、僕以外の人がOSASKの設計に関する話を書くなんてことはまずないと思うかもしれないけど、そんなことはなくて、たとえばこういう考え方のもとでこうしたらどうかという提案はできる。 | | -ただこのシリーズの趣旨としては、OSASKの設計に関する話を書いているので、他の人が書く場合もそれには準じてほしい。で、僕以外の人がOSASKの設計に関する話を書くなんてことはまずないと思うかもしれないけど、そんなことはなくて、たとえばこういう考え方のもとでこうしたらどうかという提案はできる。 |
| | -基本的に一つの話題に1ページ使ってしまうので、ちょっとした提案であれば、OSASK-MLや[[impressions]]を活用してもらうほうがいいと思う。 | | -基本的に一つの話題に1ページ使ってしまうので、ちょっとした提案であれば、OSASK-MLや[[impressions]]を活用してもらうほうがいいと思う。 |
| - | *** (1) | + | *** (1) [#p061a89d] |
| | -たとえば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){72バイト}になった。 | | -さらにabcdw008で実装予定のAPIを使う形に修正されCOLOR(#ff0000){207バイト}になり、ついにASKAで書き直されてCOLOR(#ff0000){72バイト}になった。 |
| | -こうして3,072バイトもあったものが、72バイトになった。機能は全く失われていない。この差し引き3,000バイトは一体何なのか。それを考えてみようと思う。 | | -こうして3,072バイトもあったものが、72バイトになった。機能は全く失われていない。この差し引き3,000バイトは一体何なのか。それを考えてみようと思う。 |
| - | *** (2) | + | *** (2) [#h4dd7ca2] |
| | -僕の考えるところでは、これはムダである。API設計者とコンパイラ開発者とアプリ開発者がしかるべき努力をすれば72バイトでできるプログラムを、三方の怠惰（いわゆる手抜き）によって3,072バイトにしてしまっていたのだ。 | | -僕の考えるところでは、これはムダである。API設計者とコンパイラ開発者とアプリ開発者がしかるべき努力をすれば72バイトでできるプログラムを、三方の怠惰（いわゆる手抜き）によって3,072バイトにしてしまっていたのだ。 |
| | -このままだとなんか毎度のwin32批判に見えて僕の趣旨が誤解されるかもしれない。じゃあこうしよう。3,072バイトから691バイトへの改良をひとまず脇においておいて、691から72バイトへの変化だけに注目しよう。 | | -このままだとなんか毎度のwin32批判に見えて僕の趣旨が誤解されるかもしれない。じゃあこうしよう。3,072バイトから691バイトへの改良をひとまず脇においておいて、691から72バイトへの変化だけに注目しよう。 |
| | -691から207への改善の理由を考えれば、これはAPIの設計を（さらに）まじめにやり、そのAPIを利用するようにアプリを書き改めたからに他ならない。明らかに手抜き度が減少したから改善したのだ。また207から72への改善も、「レジスタの使い回しなどで頭を使わなくてもとりあえず動くプログラムが作れる」C言語から「それらに配慮しなければいけない代わりに小回りのきく」ASKAで書き直したからこそ達成されたのだ。これも手抜き度の減少したからだ。 | | -691から207への改善の理由を考えれば、これはAPIの設計を（さらに）まじめにやり、そのAPIを利用するようにアプリを書き改めたからに他ならない。明らかに手抜き度が減少したから改善したのだ。また207から72への改善も、「レジスタの使い回しなどで頭を使わなくてもとりあえず動くプログラムが作れる」C言語から「それらに配慮しなければいけない代わりに小回りのきく」ASKAで書き直したからこそ達成されたのだ。これも手抜き度の減少したからだ。 |
| | -ここから演繹すれば、つまり僕たちが本来72バイトで十分なものを3,072バイトも消費して使わされていたのは、ありとあらゆる手抜きが集積していたからである。3,072が本来のサイズで72ががんばった結果なのではなく、72こそ本来の姿で3,072は手抜きに手抜きを重ねた結果なのだ。 | | -ここから演繹すれば、つまり僕たちが本来72バイトで十分なものを3,072バイトも消費して使わされていたのは、ありとあらゆる手抜きが集積していたからである。3,072が本来のサイズで72ががんばった結果なのではなく、72こそ本来の姿で3,072は手抜きに手抜きを重ねた結果なのだ。 |
| - | *** (3) | + | *** (3) [#y11b15bf] |
| | -3,072バイトのmakefontにせよ、691バイトのmakefontにせよ、リリースしたのは僕なのだから、僕は非難されるべきだと思う。まあオープンソースで品質未保証だから、文句を言われる筋合いはないのだけれど、しかし72バイトで済むものを691バイトや3,072バイトでリリースしたというのもまた事実だ。これは絶対に褒められたことじゃない。ただabcdw008ができるまで待たなくてもよかったということだけが、せいぜいのいいわけだろう。・・・非難が無理だとしたら、せめて72バイトのmakefontはよくやったと賞賛されるべきだろう。でも、単にやるべきことを（やっと）やっただけだから、やっぱり当然ということで、賞賛って言うのもなんか違うけど。・・・僕は自分の過去のヘボアプリを自分で直しただけだから、ただの「自業自得」？ | | -3,072バイトのmakefontにせよ、691バイトのmakefontにせよ、リリースしたのは僕なのだから、僕は非難されるべきだと思う。まあオープンソースで品質未保証だから、文句を言われる筋合いはないのだけれど、しかし72バイトで済むものを691バイトや3,072バイトでリリースしたというのもまた事実だ。これは絶対に褒められたことじゃない。ただabcdw008ができるまで待たなくてもよかったということだけが、せいぜいのいいわけだろう。・・・非難が無理だとしたら、せめて72バイトのmakefontはよくやったと賞賛されるべきだろう。でも、単にやるべきことを（やっと）やっただけだから、やっぱり当然ということで、賞賛って言うのもなんか違うけど。・・・僕は自分の過去のヘボアプリを自分で直しただけだから、ただの「自業自得」？ |
| - | *** (4) 2008.12.30追記 | + | *** (4) 2008.12.30追記 [#ib469daa] |
| | -プログラムは結局CPUに対する作業手順を並べたものに過ぎない。これが大きいということは、手順が複雑で長いということだ。一方で「ぐいぐい01」アプリとして全く同じ処理を記述すると手順は短く簡潔に書ける。どちらがあるべき姿だろうか。 | | -プログラムは結局CPUに対する作業手順を並べたものに過ぎない。これが大きいということは、手順が複雑で長いということだ。一方で「ぐいぐい01」アプリとして全く同じ処理を記述すると手順は短く簡潔に書ける。どちらがあるべき姿だろうか。 |
| | -これはあるインタビューアから聞いた話だが、有名な問答として、こんなものがあったらしい。 | | -これはあるインタビューアから聞いた話だが、有名な問答として、こんなものがあったらしい。 |
| | --弾 じゃあ、我々がやっていることは何て呼んだらいいんでしょう。 | | --弾 じゃあ、我々がやっていることは何て呼んだらいいんでしょう。 |
| | --Dave コーディング。 | | --Dave コーディング。 |
| - | *** (5) 2009.01.03追記 | + | *** (5) 2009.01.03追記 [#te4b9ae6] |
| | -「ぐいぐい01」では、ただ正常終了するだけのアプリというものを書くことができる。それはヘッダだけの3バイト（シグネチャ2バイト＋フラグ類1バイト）になる。これはメモリ上ではRETだけの1バイトのプログラムになる。・・・同じことをDOSでやると、RETだけを普通に書くことになるので、1バイトで書ける（誤動作防止のためのシグネチャも何もない）。だからこの勝負ではDOSの勝ちだ。 | | -「ぐいぐい01」では、ただ正常終了するだけのアプリというものを書くことができる。それはヘッダだけの3バイト（シグネチャ2バイト＋フラグ類1バイト）になる。これはメモリ上ではRETだけの1バイトのプログラムになる。・・・同じことをDOSでやると、RETだけを普通に書くことになるので、1バイトで書ける（誤動作防止のためのシグネチャも何もない）。だからこの勝負ではDOSの勝ちだ。 |
| | -しかし何もしないで正常終了するなんて、はっきり言って意味がない。そんなもので勝ってもしょうがない。ささやかでもいいので何か意味あることをしなければいけない。そうすると次に一番短いプログラムは、適当なエラーコードを返して異常終了することだろう。DOSならこれは5バイトでできる。それに対して「ぐいぐい01」はどうかというと、エラーコードを指定せずに単に異常終了なら4バイト、きちんとエラーコードも指定するなら5バイトになる。だからこれは引き分けだ。 | | -しかし何もしないで正常終了するなんて、はっきり言って意味がない。そんなもので勝ってもしょうがない。ささやかでもいいので何か意味あることをしなければいけない。そうすると次に一番短いプログラムは、適当なエラーコードを返して異常終了することだろう。DOSならこれは5バイトでできる。それに対して「ぐいぐい01」はどうかというと、エラーコードを指定せずに単に異常終了なら4バイト、きちんとエラーコードも指定するなら5バイトになる。だからこれは引き分けだ。 |
| | -約一年間で4.1万円というと社会的な仕事としてはお話にならないだろうけど、でもこの成果に4万円の価値があるといわれるとなるほど確かにそんな気が（僕には）する。 | | -約一年間で4.1万円というと社会的な仕事としてはお話にならないだろうけど、でもこの成果に4万円の価値があるといわれるとなるほど確かにそんな気が（僕には）する。 |
| | | | |
| - | * こめんと欄 | + | * こめんと欄 [#babdced3] |
| | #comment | | #comment |
