3: 2004-09-06 (月) 14:49:01  |
4: 2009-11-17 (火) 12:06:24 |
| | | | |
| | *** 2.人間本位な考えを捨ててみる | | *** 2.人間本位な考えを捨ててみる |
| - | -今までいろいろなプログラミング手法が提唱されてきましたが、それは常に正しいことでも正義でもなんでもなく、基本的にはプログラマが楽をするためのものでしかないということを認識しなければいけません。少々強引なことを言えば、プログラムは人間が読むために書くのではなく、機械が読むために書いているのです。だからまずは機械にとっての都合を優先してやりましょう、みたいな発想です。 | + | -今までいろいろなプログラミング手法が提唱されてきましたが、それは常に正しいことでも正義でもなんでもなく、その多くは基本的にはプログラマが楽をするためのものでしかないということを認識しなければいけません。しかし少々強引なことを言えば、本来プログラムは人間が読むために書くのではなく、機械が読むために書いているのです。だからまずは機械にとっての都合を優先してみてはどうでしょうか。この視点で今まで見えなかったものが見えてきます。 |
| - | -たとえば汎用的なライブラリは非常に便利ですし、オブジェクト指向はすばらしいです。しかし汎用的なライブラリは使わない機能を多く持つ場合がありますし、オブジェクト指向においても使わないインターフェースを大量に持ったものを知らずに使っている場合があります。 | + | -たとえば汎用的なライブラリは非常に便利ですし、オブジェクト指向はすばらしいです。しかし汎用的なライブラリは使わない機能を多く持つ傾向がありますし、オブジェクト指向においても使わないインターフェースを大量に持ったものを知らずに使っている場合があります。 |
| - | -もっと機械本位に考えてみます。サイズが小さく処理が少なくて済み、さらに必要な機能をだけを的確に提供するようなライブラリ構成やクラス構造がよいのです。またソースの読みやすさなんて機械にとってはどうでもいいことです。人間にも読みやすくて機械にもうれしいようなソースの書き方が存在します。たまにこれが両立できない場合もありますが、そのときに優先するべきは機械の都合であって、人間の都合ではないのです。 | + | -これをもっと機械本位に考えてみます。サイズが小さく処理が少なくて済み、さらに必要な機能をだけを的確に提供するようなライブラリ構成やクラス構造がよいのです。またソースの読みやすさなんて機械にとってはどうでもいいことです。実は人間にも読みやすくて機械にもうれしいようなソースの書き方が存在します。たまにこれが両立できない場合もありますが、そのときに優先するべきは機械の都合であって、人間の都合ではないのです。 |
| | -JavaをやめてCに切り替えてみる、なんてことだけでも機械の都合に近づいているのでこの観点ではいいわけです。 | | -JavaをやめてCに切り替えてみる、なんてことだけでも機械の都合に近づいているのでこの観点ではいいわけです。 |
| | -移植性も当然人間の都合です。機械は移植性が高くなってもうれしくありません。もちろん、移植性を高める過程でよいコードに到達することはあります。それは機械にもとても嬉しいです。 | | -移植性も当然人間の都合です。機械は移植性が高くなってもうれしくありません。もちろん、移植性を高める過程でよいコードに到達することはあります。それは機械にもとても嬉しいです。 |
| | *** 3.時代に依存しないプログラミング | | *** 3.時代に依存しないプログラミング |
| | -今はCPUが速いからとか、今はメモリがたくさんあるから、みたいな理由でベストの解は変化しません。メモリをたくさん使うけどCPUの負荷は小さいとか、CPU時間を多く使うけどメモリの負荷は小さい、みたいなのはありえます。どっちがベストなのかは状況によりますが、どちらも重要な解でしょう。どちらか一方で済むとは思えません（だからtek1だけでいいとかtek5だけで十分であるという発想は僕にはありえない）。 | | -今はCPUが速いからとか、今はメモリがたくさんあるから、みたいな理由でベストの解は変化しません。メモリをたくさん使うけどCPUの負荷は小さいとか、CPU時間を多く使うけどメモリの負荷は小さい、みたいなのはありえます。どっちがベストなのかは状況によりますが、どちらも重要な解でしょう。どちらか一方で済むとは思えません（だからtek1だけでいいとかtek5だけで十分であるという発想は僕にはありえない）。 |
| - | -もしあなたがプログラムの改良を「今は～」的な理由や「これからは○○だから」的な理由でやめたのなら、それはそういうものであって、OSASKがいうところのベストではありません。たぶん時代が変わるとまた書き直すことになるんでしょう。 | + | -もしあなたがプログラムの改良を「今は～」的な理由や「これからは○○だから」的な理由でやめたのなら、それはそういうくだらないものであって、OSASKがいうところのベストではありません。たぶん時代が変わるとまた書き直すことになるんでしょう。 |
| | --今はCPUが速いからこれでも大丈夫、とかいってリリースされたライブラリは、結局そのアルゴリズムを酷使しなければいけないアプリからはボトルネックでしかなく、そのためにそのコードが書き直されることになります。ベストなコードが一個あればいいのに、中途半端なコードが大量生産される結果になります。メモリについても同じです。今はメモリが安いから大丈夫とか言っていると、そのルーチンをたくさん使おうとするときにメモリ不足のせいで書き直しをしなければいけなくなります。 | | --今はCPUが速いからこれでも大丈夫、とかいってリリースされたライブラリは、結局そのアルゴリズムを酷使しなければいけないアプリからはボトルネックでしかなく、そのためにそのコードが書き直されることになります。ベストなコードが一個あればいいのに、中途半端なコードが大量生産される結果になります。メモリについても同じです。今はメモリが安いから大丈夫とか言っていると、そのルーチンをたくさん使おうとするときにメモリ不足のせいで書き直しをしなければいけなくなります。 |
| - | --また逆に、仮にそのルーチンが酷使されないほど重要でないとしたら、そんなものがたくさんCPU時間を浪費したり、メモリを浪費したりしても許せるものでしょうか。主役でもないのに主役以上にリソースを食って主役の計算に支障が出ているかもしれません。 | + | --また逆に、仮にそのルーチンの利用頻度が低くて重要でないとしたら、そんなものがたくさんCPU時間を浪費したり、メモリを浪費したりしても許せるものでしょうか。主役でもないのに主役以上にリソースを食って主役の計算に支障が出ているかもしれません。 |
| | -ということで、時代に依存したプログラムは結局その場限りのものであって、多くの人に使われてはいきません（まあそれでも無理にそういうものが普及した結果がWindowsやLinuxの肥大化なのかもしれません）。時代を言い訳にしなければいけないような中途半端なものを作るくらいなら、その数倍の時間をかけてでもベストなものを一つ作るほうがずっとマシです。 | | -ということで、時代に依存したプログラムは結局その場限りのものであって、多くの人に使われてはいきません（まあそれでも無理にそういうものが普及した結果がWindowsやLinuxの肥大化なのかもしれません）。時代を言い訳にしなければいけないような中途半端なものを作るくらいなら、その数倍の時間をかけてでもベストなものを一つ作るほうがずっとマシです。 |
| | | | |
| | -必要な機能はどんどんつけるべきです。しかし利用頻度が低い上に他の機能の組み合わせで表現できるなどという場合は、そんな機能はいらないということです。いらない機能がどんなたくさんあっても、それはソフトウェアの価値にはなりません。使いにくくてサイズが無駄に増えるだけで、かえって害にもなります。 | | -必要な機能はどんどんつけるべきです。しかし利用頻度が低い上に他の機能の組み合わせで表現できるなどという場合は、そんな機能はいらないということです。いらない機能がどんなたくさんあっても、それはソフトウェアの価値にはなりません。使いにくくてサイズが無駄に増えるだけで、かえって害にもなります。 |
| | -こんな機能は機械にはつらいから本当はあったほうがいいんだけど省こう、という姿勢は行きすぎです（その論法を強烈に押し進めていいなら、0バイトの何もしないプログラムが最高の価値だということになりかねません）。その機能が人間にとって有用ならたとえプログラムのサイズや速度の低下を招いてもつけるべきです。デザインでがんばって限界に達したらそれでいいのです（これ以上機械本意にしたら目標の便利さに到達しない、など）。ただ処理があまりにも重いのなら、設定やオプションなどによって必要なときだけ機能するようにするとか、その機能がないサブセット版も用意しておくとかの、そんな工夫はあったほうがいいかもしれません。 | | -こんな機能は機械にはつらいから本当はあったほうがいいんだけど省こう、という姿勢は行きすぎです（その論法を強烈に押し進めていいなら、0バイトの何もしないプログラムが最高の価値だということになりかねません）。その機能が人間にとって有用ならたとえプログラムのサイズや速度の低下を招いてもつけるべきです。デザインでがんばって限界に達したらそれでいいのです（これ以上機械本意にしたら目標の便利さに到達しない、など）。ただ処理があまりにも重いのなら、設定やオプションなどによって必要なときだけ機能するようにするとか、その機能がないサブセット版も用意しておくとかの、そんな工夫はあったほうがいいかもしれません。 |
| - | -本質的にどうしても速くできない処理は存在します。そういうものは、今のCPUをもってしても高速にはできないようなものであっても、そのようにプログラミングするしかないのです。それはプログラマのせいではありませんし、ベストなのです。これは浪費ではないので全く問題ありません。速くできるのに速くしないのはおかしいですし、小さくできるのに小さくしないのはおかしいですが、もうこれ以上速くできないものや小さくできないものは、たとえどんなに遅くて大きくても、素晴らしいプログラムです。 | + | -本質的にどうしても速くできない処理は存在します。そういうものは、今のCPUをもってしても高速にはできないようなものであっても、そのようにプログラミングするしかないのです。それはプログラマのせいではありませんし、実用レベルではなくてもプログラムとしてはベストなのです。これは浪費ではないので全く問題ありません。速くできるのに速くしないのはおかしいですし、小さくできるのに小さくしないのはおかしいですが、もうこれ以上速くできないものや小さくできないものは、たとえどんなに遅くて大きくても、素晴らしいプログラムです。 |
| | | | |
| | *** 5.コンパイラの最適化との関係（追記） | | *** 5.コンパイラの最適化との関係（追記） |
