kiyoka.2006_10_11 RSSPLAIN

Related pages: !kiyoka.blog.list !kiyoka.blog.2006_10
55555555555555555555555555555555555555555
5

[デザインポリシー] 富豪的プログラミング

5

最近はコンピューターのCPUとメモリ容量が大きくなったせいで昔とは違うプログラミングスタイルが主流になりつつあります。

5

それは、富豪的プログラミングと呼ばれるスタイルです。

5

経済的に富豪で無くても、コンピュータープログラミングの世界に限って言えば、誰もが富豪になれます。ケチケチせずに富豪になってしまいましょう。

5

 

5
 富豪的プログラミングEXT
5
 プログラマというものは、つい昔の癖で効率的なプログラムを工夫したり資源
5
 を節約したりしようとしがちですが、ユーザインタフェースのプログラムを開
5
 発するときにはこれが裏目に出ることもあります。
5
 というのも、ユーザインタフェースのプログラムでは機械の効率よりも使い勝
5
 手が優先されるべきですし、プロトタイプの作成とその評価/改良のサイクル
5
 を数多く繰り返す必要があるのですが、計算機資源を節約しようとするとこれ
5
 らの条件が後回しになりがちだからです。
5
 これを解決するのが富豪的プログラミングです。以下のような富豪的プログラ
5
 ミングを行なえばこのような問題は起こりません。
5
 
5
 1. メモリや実行効率を気にしないでお気楽にプログラムを作る
5
 効率を重視したプログラムは作るのが大変ですし、ちゃんと動かすにはデバッ
5
 グも大変です。富豪的プログラミングでは一番単純で短いアルゴリズムを使い
5
 ます。
5
 
5
 2. 条件が変わる度にすべての計算や表示を行なう
5
 再表示が必要な場所だけ書き直ししたり、出力のバッファリングをしたりする
5
 貧乏性な工夫はバグのもとになるので行なわず、条件が変わる度に計算を再実
5
 行したり全体を書き直したりします。
5
 
5
 富豪的プログラミングでは現在の状態を記憶しておく必要が少なくなるのでプ
5
 ログラムが短く、バグを含みにくくなります。また、ユーザが何か操作を行な
5
 う度にシステムがすぐに反応するので、直感的操作が可能になります。
5

 

5

Sumibi.orgEXTもかなり富豪的な計算をしています。本来ならば、難しいコーディングをすればリダクションできる計算も、シンプルになるという理由だけで二度以上計算している部分もあります。

5

そうすることで、数式をプログラムに展開せずにそのまま記述できています。

5

これで、小難しいバグを何個かは回避できているんではないかと思っています。

5

そして、その浮いた時間をもっとクリエイティブな部分に投資します。

5

これぞ富豪的プログラミングの醍醐味です。

5

 

5

COMMENTじょりちょこ

富豪的プログラミングをするとなると、「遅延評価」っていいですよね。僕自身はSchemerではなく、Rubyistなのですが、遅延評価は好んで使ってます。

5

COMMENTkiyoka

じょりちょこさん、コメントありがとうございます。

SumibiのエンジンはGaucheで書いているのですが、Gaucheにも「遅延評価」の屋台骨である「簡約」機能があったとしたら、今の数式中の重複した計算がまとめられて1回の計算になる可能性があります。(例えば、今の式をHaskellで書けば富豪的なコーディングをしても高速になるということですね。)

やっぱり、富豪的になることはいいことですよね。CPUが高速になる意外にもコンパイラの最適化技術も進化していっています。

ところで、Rubyでも遅延評価できるんですか。知りませんでした。

5

COMMENTじょりちょこ

自動的に遅延評価するための構文があるわけじゃないんですけどね。SmalltalkでいうところのLazy Initializationパターンをよく使います、という話ですね。(期待させてしまったらすみません。。。)

Schemeのdelayも、Haskellの遅延評価ほど、強力ではないですものね。

富豪的プログラミングでは、そもそもLazy Initializationのようなテクニックすら否定して「何度でも計算する」ということですけど、クロージャが使える言語であれば、計算結果をキャッシュする汎用的な仕組みを作ることは難しくないですよね。

5

COMMENTkiyoka

Lazy Initializationですか。

なるほど、これにもパターン名がついているんですね。知りませんでした。

> クロージャが使える言語であれば、計算結果をキャッシュする汎用的な仕組みを作ることは難しくないですよね。 

アスペクト思考というやつでしょうか。そういう仕組みをオブジェクト指向のフレームワーク側だけを変更することで組み込めるので、MOP最強論の話につながるのですよね。

5

...comment disabled...