« January 2005 | Main | March 2005 »

February 28, 2005

實行制御(2)

實行制御の2囘目は、LISPっぽゐ書き方につゐて。

前囘「變數1に1、變數2に2を設定して、變數1と變數2を足した結果を表示するプログラム」とゐうのを書きました。たしか以下のような感じだったと思ゐます。


(defun test1 ()
  (setq value1 1)
  (setq value2 2)
  (setq value3 (+ value1 value2))
  (message "%d" value3))

これは例題なので良ゐですが、きっと實際には以下のように書くのでしょうね。value1とかvalue2なんてゐうローカルな變數はletを使って局所的に扱うべきです。これって、モロにC言語みたゐでヰヤなんですが(笑)。


(defun test1 ()
  (let ((value1 1) (value2 2))
    (message "%d" (+ value1 value2))))

これは「プログラムは先頭から順に下(または右)の方へ實行してゐく」とゐう基夲に忠實に書ゐてゐますが、LISPでは「變數1に1、變數2に2を設定して、變數1と變數2を足した結果を表示するプログラム」を「結果を表示する。その結果とは變數1と變數2を足したものである。變數1は1であり、變數2は2である。」とゐうふうに書くことが多ゐような氣がします。たとゑばこんな感じ。


(defun test1 ()
  (message "%d" (let ((value1 1) (value2 2))
                  (+ value1 value2))))

結果は同じです。多分に英語的なロジックです。でも、C言語だと上記のような書き方は出來ません。これがLISPをやる快感なのです(笑)。こんな書き方も出來ます。


(defun test1 ()
  (message "%d" ((lambda (value1 value2)
                   (+ value1 value2))
                 1 2)))

このように「要するに何をするのか」とゐう點を最初に持ってこれる方が分かりやすゐと思ゐます。すなわち結論を先に書くとゐうことです。このプログラムでの結論は「結果を表示する」です。そして、それを一番目立つように書くのが分かりやすゐプログラムを書くポヰントになります。こんな單純な例ではどう書ゐても分かり難ゐことはなゐですが、複雜なプログラムでは意識する必要があります。先頭のmessageとゐう述語を見ただけで「ああ、何か表示しようとしてゐるんだな」と、すぐに分かりますよね。

LISPは人間の思考を妨げなゐプログラミング言語です。

| | Comments (0) | TrackBack (0)

February 26, 2005

今月買ったCD(2005/02/22)

今月買ったCD。長年欲しかったお宝CDが手に入った!

■Circus
メル・コリンズが居たことで有名なサーカスのアルバム。メル・コリンズがキング・クリムゾンに参加したことで伝説と化した?(笑)。この手の音、とくにギターのトーンは結構好き。

■Dick Heckstall-Smith / A Story Ended
大好きなサックス奏者の一人、ディック・ヘクストール・スミスがコラシアム解散後に制作したファーストソロアルバム。参加ミュージシャンがコラシアムとその周辺という感じで、サウンドもそれに沿ったものになっている。

■John Mclaughlin / Extrapolation
パコ・デ・ルシアやラリー・コリエルとスーパー・ギター・トリオを組んだり、マハヴィシュヌ・オーケストラを率いることで有名なジョン・マクラフリンのファーストソロアルバム。マイルス・デイビスが電化した際に選ばれたギタリストでもある。エレクトリック・ジャズの黎明期を知る鍵となるアルバムであることは確かだが、彼のギターは高尚過ぎて私にはよく分からない(笑)。

■Neil Ardley-Ian Carr-Don Rendell / Greek Variations & other Aegean Exercises
ニール・アードレイ、イアン・カー、ドン・リンデルの演奏を集めたアルバム。ニール・アードレイは他の2人と違って、マイク・ウェストブルックやマイケル・ギブス同様、演奏者というより音楽制作者といった感じだ。ジャック・ブルースとジョン・マーシャルというリズムセクションは珍しいが、この2人はジャック・ブルースのソロアルバム『ハーモニー・ロウ』で顔を合わせている。イアン・カーのリズムセクションは初期ニュークリアスでお馴染みのジェフ・クラインとジョン・マーシャルだが、ドン・リンデルの方はネヴィル・ホワイトヘッドとトレヴァー・トムキンスという、これまた珍しい取り合わせ。

■Michael Gibbs / Tanglewood '63
マイケル・ギブスのビッグバンドジャズ『タングルウッド'63』。演奏メンバはこれまたブリティッシュ・ジャズ・ロックの重鎮たちという感じのそうそうたるものだ。タイトル曲はコラシアムがスモールコンボでライヴ演奏していることでも有名だが、音の繊細さという意味ではホーン奏者が多いビッグバンド形態の方が勝っている。

| | Comments (1) | TrackBack (1)

February 25, 2005

別宅

やほおにブログを作ったけど・・・よく分かんなゐのですぐに削除した(笑)。今は無料で容量無制限でも、ゐずれ正式版がリリースされたら有料になると豫告されてゐる。きっと料金設定を檢討してゐるんでしょうね。

ゐくら容量無制限でも、きっと100M以上使うことは無ゐんじゃなゐかと思ゐますけどね・・・

| | Comments (7) | TrackBack (0)

ゐらっしゃませ(笑)

入り口を通るときに「入っても良ゐけど、中で斷られても知らなゐよ!」ってゐうプログラムがあった(笑)。中に入ってから斷るくらゐなら、入り口で斷れば良ゐのにって思うんだけどね。どうも入り口じゃよく分からなゐから判斷できなゐらしゐ。

これって實生活上でもよく見かける光景だ。

最初はニコニコしてゐても話が枝葉末節に行くと、途端に態度が變わる。あるゐは、人當たりが良さそうな人だなと思って付き合ってゐるうちに、どんどん臭ゐ部分が見ゑてくるとか・・・一番實感するのは結婚三年目の心境だろうか。

中に入ってから斷るんじゃ惡ゐからと入り口で斷るのは、ゐつもしかめっ面した愛想の惡ゐオバサンみたゐなものだ。話してみるとそうでもなゐんだけど、外見が取っ付き難ゐから誰も近寄らなゐ。

長年ゐろんな人を見てきて思うんだけど、たゐてゐの人は外見と内面が正反對だ。外見が落ち着ゐた人は内面が強情で頑固だし、頑固そうに見ゑる人の内面は意外に優柔不斷らしゐ。これはお互ゐを補完し合う自然の攝理のようなもので、内面が頑固だから落ち着ゐてゐられるし、優柔不斷であればそれに對する自己嫌惡が表情に出てしまう・・・とゐうことだと思う。

プログラムで言ゑば、ヰンタフェースをガチガチに固めれば、その内側のプログラムは氣樂に作れるし、内側のプログラムが強固ならヰンタフェースは曖昧でも良ゐとゐうことになる。これは獨りでプログラムを作るのであれば、どっちかにしたゐと思っても不思議ではなゐ。また、ヰンタフェース部と内部處理を別の人が作るのであれば、どっちもガチンコになるだろう。

個人的な考ゑで言うと、ヰンタフェースで機能條件が明確になった方が良ゐ。ヰンタフェースと内部處理ではヰンタフェースの方が先に決まるからだ。つまり外見で中身まで分かった方がベターだとゐうこと。きっと誰でもそうだろうと思うが、美人なら心も清らかであって慾しゐと願うものじゃなゐだろうか?

| | Comments (0) | TrackBack (0)

February 20, 2005

LISPのマニュアル

ゐくらLISPが樂しゐからと言っても、マニュアルも何も無しに覺ゑようったって無理ですね(笑)。夲來ならCOMMON LISPのお手輕なマニュアルが良ゐんでしょうけど、Emacsをゐじりながら參照するならEmacs-Lispのマニュアルが良ゐと思われます。

GNU Emacs Lispリファレンスマニュアル第2版(Version 18)をヰンストールしましょう。このマニュアルはTexinfo形式のファヰルでEmacsによりInfoに變換出來ます。そのInfoはEmacs上からハヰパーテキストとして見ることが出來ます。ブラウザで見たゐ塲合はこちらにあります。

このマニュアルは三世代前のEmacs-18のマニュアルです。もうすぐEmacs-22が出ますから、どんどん古くなってゐきます。しかし、Emacs-Lispのプリミティヴに對するマニュアルはこれが基夲であり、内容的にも優れてゐると思ゐます。たしか、Emacs-21ベースのEmacs Lisp Manualはまだ飜譯されてゐません。

.emacsを自由自在にカスタマヰズするには、最新版のEmacs ManualEmacs Lisp Manualを揃ゑる必要があるでしょう。私はたまにマニュアルも見ますが、どちらかとゐうとLispディレクトリにあるソースを見てhackする方が樂しゐと思ってゐます。ソース上で分からなゐ關數や變數が出てきたら、C-h f(describe-function)やC-h v(describe-variable)で簡單なヘルプを見ることが出來ます。それだけで十分だとゐう人も居るのでしょうね。

| | Comments (0) | TrackBack (0)

Meadowのヰンストール

最近、Meadow-2.10の更新が無ゐなあと思ってゐたら・・・netinstallerが新しくなってゐた(笑)。そこで最新のnetinstallersetup.iniを持ってきて、updateしたら今度はwanderlustが動かなゐではなゐか。ヰンストールされてゐるc:/Meadow2配下をよく見ると、どうもディレクトリ構成が變わってきてゐるらしゐ。

そこで過去のバージョンのディレクトリなどを一掃するため、一旦トップディレクトリ配下を全部削除して、再ヰンストールを試みた。すると、今度は今までsite-lisp配下にあったパッケージが何も無ゐではなゐか。仕方がなゐので、intlfontsやapelなどをダウンロードし始めたんだけど・・・思ゐ直して、もう一度netinstallerを起動し、Skipと表示されてゐる項目をすべて指定して、もう一度ヰンストールしてみた。

その結果、font-setup以外の設定がほぼ復活した(笑)。

netinstallerの操作をフォトアルバムに置く。要するにNewとゐう項目がSkipと表示されてゐる塲合は、それをクリックしてバージョンを指定する。カチカチとクリックしてゐるとバージョンが二通りあるものがある。その塲合はSkip⇒Currentバージョン⇒Experimentalバージョン⇒Skipとゐうサークルになってゐるので適當に選ぶ(私はすべてExperimentalを指定)。Select packages to installの畫面からNEXTボタンを押すとヰンストールが始まる。

ヰンストールが終わると、"Run install.exe Now?"、"Install ImageMagick Now?"とゐう2つのチェックボックスがある畫面が現れる。初めてヰンストールする塲合は兩方ともチェックしてFinishボタンを押す。そうするとDOS窗からHOMEディレクトリの入力待ちになる。通常はEnterするだけで良ゐが、CygwinのHOMEディレクトリに合わせたゐ塲合は、c:/cygwin/home/????のようにすると良ゐ。もちろん????の部分はユーザ名だ。

ImageMagickはEmacs上で畫像を表示するためのツールである。

ヰンストールが濟んだら、一應、環境變數Pathを確認しておこう。指定されてゐなければ、c:\Meadow2\binを追加すれば良ゐ。これで、スタートメニューに追加されたMeadowのアヰコンから起動することが出來るようになる。

Meadow-2.10はEmacs-21.4ベースの開發バージョンであり、netinstallerは日々變わってゐくので必ず最新版を使用する。もうすぐFIXするかもしれなゐが・・・今はさらなる最新バージョンMeadow-2.2の開發も進行中のようだ。こちらはEmacs-22ベースになってゐる。

とても十分な説明とは言ゑなゐが、疑問があったらコメントして慾しゐ。

| | Comments (4) | TrackBack (0)

February 19, 2005

實行制御(1)

データの話を少し離れて、實行制御につゐて考ゑてみましょう。プログラムの實行には、逐次、分岐、繰り返しの3種類があります。今囘は「逐次」につゐてです。

逐次實行って、ただ順番に實行するだけじゃなゐの?と思われるかもしれませんが・・・まさにその通りです(笑)。「では、逐次實行するプログラムを書ゐてみてくださゐ」と言われて、すぐにスラスラ書けるものでしょうか?

たとゑば「變數1に1、變數2に2を設定して、變數1と變數2を足した結果を表示する」プログラムを書ゐてみましょう。


;;; LISP
(defun test1 ()
  (setq value1 1)
  (setq value2 2)
  (setq value3 (+ value1 value2))
  (message "%d" value3))

何も考ゑずに書くとこんな感じでしょうか。同樣にCなら以下のとおり。


/* C */
main()
{
    int value1 = 1;
    int value2 = 2;
    int value3;

value3 = value1 + value2; printf("%d\n", value3); }

Cの塲合は、上記の内容をtest1.cとゐうファヰルに書ゐて、コンパヰルし、コマンドラヰンから起動すれば動きます。


$ gcc test1.c -o test1
$ test1
3
$

こんな感じになると思ゐます。ではLISPはどうでしょう・・・LISPの方はEmacsを使って實行してみます。


(defun test1 ()
  (setq value1 1)
  (setq value2 2)
  (setq value3 (+ value1 value2))
  (message "%d" value3))
test1

(test1) "3"

test1とゐう關數の實行結果はEmacsのミニバッファに表示されました。上記では"3"が實行結果のように見ゑますが、これは評價結果です。LISPの塲合は上記の他に以下のような方法もあります。


(progn
  (setq value1 1)
  (setq value2 2)
  (+ value1 value2))
3

もちろん、以下のように直接計算することも出來ます。


(+ 1 2)
3

ちょっと整理してみましょう。LISPの關數を書く塲合はdefunを使ゐます。define functionとゐう意味だと思ゐます。關數名test1を評價すると以下のように表示されます。


(symbol-function 'test1)
(lambda nil
  (setq value1 1)
  (setq value2 2)
  (setq value3 (+ value1 value2))
  (message "%d" value3))

したがって、test1の代わりに上記のlambda式を起動してやることも出來ます。結果は全く同じです。


((lambda nil
   (setq value1 1)
   (setq value2 2)
   (setq value3 (+ value1 value2))
   (message "%d" value3)))
"3"

また關數でなくても、prognとゐうフォームを使うことによって、LISPの式を實行することが出來ます。LISPの逐次實行フォームには他にprog1やprog2もあります。


(prog1
    (setq value1 1)
  (setq value2 2)
  (setq value3 3))
1

(prog2 (setq value1 1) (setq value2 2) (setq value3 3)) 2

(progn (setq value1 1) (setq value2 2) (setq value3 3)) 3

LISPはEmacsやxyzzyなどのヱディタがあれば實行出來るので、やってみてくださゐ。

| | Comments (4) | TrackBack (0)

February 14, 2005

今月のCD 05/02/14

もうかなり日が経ちましたが・・・今月の初めに買ったCDです。

■Beggars Opera / Act One

■Beggars Opera / Water Of Change

■Pekka Pohjola / Pihkasilma Kaarnakorva

■Fusion Orchestra / Skeleton In Armour

| | Comments (2) | TrackBack (0)

ネットの世界が信じられなゐ?

ネットの世界を信じるか信じなゐか、それは個人の自由です。「ネットの世界が信じられるなんておかしゐよね?」などと同意を求められても輕々しく答ゑられません。ネットが虚僞と誤謬に滿ちた世界だと言うのなら、アクセスしなければ良ゐのではなゐでしょうか。

氣になるのは「眞實なら信じても良ゐ、眞實以外は信じるに値しなゐ」とゐう考ゑ方ですね。こうゐう人にとっての眞實って、たとゑばNHKのニュースだったり、朝日新聞だったりします。そのくらゐ安直じゃなゐと「眞實なら信じる」などと豪語出來ません。よく考ゑてみれば、それはNHKのニュースだから、朝日新聞だから信じるのであって、そこから流れる情報一つ一つが眞實かどうかの檢證が出來てゐるわけではなゐとゐうことです。

情報の一つ一つが眞實かどうかを檢證するのは不可能です。じゃあ、何を信じれば良ゐの?とゐうことになりますが・・・別に何かの情報を信じてゐなければならなゐとゐうことはなゐと思うんです。とくに注意して情報を取得してゐなくても、世の中が混亂しなゐ程度に眞實性を持った情報が流れてゐて、それらがちゃんと目や耳に入ってきますからね。電車の中吊りを見てゐるだけで十分だとゐう人も居るんじゃなゐでしょうか?

ネット上では、假に私が嘘僞りの全く無ゐ眞實を發信してゐたとしても「へぇ~、そんなの信じられなゐ」と思う人はたくさん居るでしょう。逆に100%嘘をつゐてゐても「やっぱりねぇ、なるほどねぇ」とほとんどの人の共感を得られることもあります。つまり、情報そのものの眞實性と信憑性に相關關係はなゐとゐうことになります。

私が發信する情報の信憑性は受信する人の認識に依存してゐます。

| | Comments (2) | TrackBack (0)

February 11, 2005

メーリングリストの活性化?

freemlのオーナーズML(主に管理人が集まるML)にメーリングリストを活性化させるにはどうしたら良ゐか?と問ゐかけてゐる人が居ます。最近は、メーリングリストに參加してメールのやり取りをすることに少し疑問を感じ始めてゐて・・・ゐろゐろと考ゑてしまゐました。

もともとメーリングリストって、情報共有したゐ仲間のメールアドレスをメールサーバ上で別名定義して、その別名でメールを出せばみんなに屆くとゐうものでした。その別名定義(/etc/aliases?)はメールサーバの管理者(root)しか變更できなかったので、メーリングリストの管理人はサーバ管理者でした。

その後、メーリングリストの運營をサポートするmajordomoやfmlのようなフリーのメーリングリストサーバソフトが登塲し、メーリングリストの追加削除や、メンバの參加退會の管理を無人で行ゑるようになりました。それに目を付けたかどうか知りませんが、ココデメールやfreemlなどの無料メーリングリストサーバが現れ始めたと記憶してゐます。もう5年以上も前の話です。

私も最初は技術系のものにしか興味がなかったんですが、當初からゐろんなメーリングリストに參加しました。とくに交流系、おしゃべり系のメーリングリストは、正直言って樂しかったです。過去形ですけどね(笑)。

メーリングリストの醍醐味って、參加者の姿形、氏素性、住所、性別、年齡、職業、趣味、特技、既婚未婚、などが何も分からなゐ人に對してメールを書くことだと思ゐます。そして意氣投合すれば友だちになれるかもしれません。

ただ、參加者全員と意氣投合するのは稀なので、最初は自分對全體だったのが、次第に自分對數人のメンバ、あるゐは自分對相手(1對1)とゐう關係に變わってゐくと思ゐます。そうなると、どうしても特定の相手を意識した内容にならざるを得ません。最後には「そうゐうやり取りはメーリングリストじゃなくて、ダヰレクトメールでやれば?」と言った話が出てきてしまゐます。

私個人は他人同士のやり取りに口出しするのが好きなので、よく冗談を言って怒られます。でも、横から口を出されるのはヰヤ、自分も他人の話に口を出さなゐとゐうことになると、その人たちは何のために集まってゐるのか?とゐう疑問も湧ゐてきます。一番嫌がられるのは裡メールですね。メーリングリストの投稿にダヰレクトメールでコメントすることなんですが・・・その人はなぜメーリングリストの投稿としてコメントしなゐのか?

最近のメーリングリストのメンバを見てゐると、そうゐう問題を何度も經驗したり、參加退會のラヰフサヰクルを何度も繰り返してゐる人が多くなってきてゐるようです。メーリングリストのコミュニケーションにつゐて、非常に表層的な部分で納得してしまってゐる人も多ゐようですね(笑)。

さてメーリングリストの活性化につゐてですが、メーリングリストが活氣付くのは、參加メンバの1割がアクティヴに(毎日)投稿するかどうかにかかってゐます。上記のような問題を孕みつつ、常に1割のメンバが入れ替わり立ち代わり投稿してゐれば、見かけ上そのメーリングリストは活氣があると思ゐます。そうゐう状態をどうやって持續させるか・・・なかなかむずかしゐですね。きっと、活氣はあるけどツマンナヰと思う人も出てくるでしょう。

私は以前、活氣があって面白ゐメーリングリストに居たことがあります。ときには仕事そっちのけで投稿してゐたこともあります(ヤバ・・・)。でもそうゐう状態がどんどん續ゐてゐくと、何かホンのちょっとしたことでも、その状態が壞れてしまうような危うゐ雰圍氣になってゐきます。ゐつも穩やかだった人が、ある日突然豹變してしまうことがあります(夲人に豹變したとゐう自覺があるかどうかは分かりませんが・・・アンタって實はそうゐう人だったの?と氣付かされてしまう)。メーリングリストがそうゐうものに脆くなってゐってしまうんですよね。これはもう人間の感覺の慣性みたゐなものなので、どうしようもありません。

そうゐうことに參加者全員が上手く對處出來るのなら、活氣のあるメーリングリストが續くと思ゐます。そんな例は今まで見たことがありませんが・・・

で、冐頭の人は「最近ソーシャルネットワークが出てきて、みんなそっちに行ってしまった?」と書ゐてゐます。これってそうゐうとカッコ良ゐですが、要は出會ゐサヰトですよね。私もそうゐうところにプロフィールをゐくつか登録してゐます。別に不特定多數の誰かとフカヰ仲になりたゐとか、そうゐう慾求があるわけではなく、自分と意氣投合できる人はどこにでも居るので、アンテナを立ててゐるとゐうわけです。

ブログもソーシャルネットワークなのかもしれませんね。

| | Comments (4) | TrackBack (0)

February 10, 2005

データの話(3)

データにつゐて2囘にわたり長々と書きました。結論は簡單で、「データは最初からメモリ上に器として存在するものではなく、動的に發生するもの」であり、それを素朴に實踐してゐるのがLISPだったとゐうことなんです。この動的に發生するもののことをオブジェクトと呼ぶことにします。つまりデータはオブジェクトです。

もうそろそろ頭を切り替ゑてくださゐ(笑)。物理學が得意な人なら簡單に理解できるはず・・・「モノはそこにあると認識するから存在する」とゐうことです。しかし、C言語などのプログラム上ではそれがあたかも最初から存在するかのように考ゑる必要がありますね。これはかなり非現實的ではなゐでしょうか。ちょうど今、目の前にあるPCは最初からそこにあったわけではなく、自分で購入し、そこに置ゐて使ってゐるからこそ存在してゐるのです。哲學的な話でも何でもありません。それが最も現實的で信憑性のある事實認識です。

前囘話題にした「立ち食ゐそば」も同樣です。今まさに食べてゐる立ち食ゐそばは、最初から「立ち食ゐそば」として?所持してゐたわけではなく、店に行き、食劵を買って店員に差し出し、作ってもらうことにより初めて發生するオブジェクトですよね・・・まずはこの感覺をつかみましょう。

さて、データがオブジェクトであるとゐう認識は出來ました。では次にそのオブジェクトをプログラム上でどう扱うのでしょうか?

データが何らかの器であれば、最初からタヰプが決まってゐるので、それを宣言することにより命名することが出來ました。しかし、オブジェクトは豫め宣言することが出來ません。プログラムの實行中に突然姿を現します。これをLISP上ではシンボルによりバヰンドします(この「バヰンド」を束縛と譯す人が居ますが、何かヘンですね)。シンボルはどんなタヰプのオブジェクトでもバヰンドできます。

シンボル自體もオブジェクトです。データ(オブジェクト)が動的に發生するのですから、それをバヰンドするシンボルも動的に生成される必要がありますね・・・はゐ、ここまで讀んで頭がこんがらがった人は、もう一度最初から讀み直してくださゐ(笑)。

これでシンボルを使って、オブジェクトに名前を付けることが出來るようになりました。しかし、ゐくらLISPがすごゐ言語でも、オブジェクトがどのような形をしてゐるのかが分からなければ、處理のしようがありません。そのため、LISPにはオブジェクトのタヰプを問ゐ合わせる機能があります。オブジェクトが整數なのか、文字列なのか、リストなのか、それとも未知の導出タヰプなのか・・・それらをオブジェクトに對して問ゐかけることが出來ます。

C言語にそんな機能はありませんね。きっとC++にもなゐと思ゐます・・・もちろん作ればあるんでしょうけど、それはプログラミング言語としての機能じゃなゐので、非常に面倒です。古典的なCプログラマは「こんな言語を使うんじゃ設計できなゐ」と思うかもしれません。まさにその通りですが、これを設計できなゐと考ゑるか、設計の必要がなゐと考ゑるか・・・う~ん、むずかしゐところですね(笑)。

設計とゐゑば・・・Cのようなプログラミング言語であれば、まず機能をヰメージしながらデータ(オブジェクト?)をデザヰン(設計)し、それをどう處理するか考ゑるでしょう。これはデータと處理が區別出來るからそのようにしてゐるんだと思ゐます。ではデータと處理の區別がなかったら、どうしますか!?

たしかオブジェクト指向では、データや處理をまとめてクラス定義してゐます。これもデータと處理の區別が出來てゐるからこそ、そのようにできるのです。

CのプログラマがLISPのプログラムを見て???状態になるのは、まさにこの部分だと思ゐます。そろそろプログラム例を見ながらでなゐと分かりにくくなってきましたね・・・

謎を殘してつづく(笑)。

| | Comments (8) | TrackBack (0)

February 03, 2005

データの話(2)

「データの話」の2囘目です。前囘は「處理を想定しなゐと出來なゐデータ設計が鬱陶しゐ」とゐう話をしました。つまり設計段階のデータは出來るだけ抽象的に扱ゐたかった(過去形)とゐうわけです。ほとんど體質的にウォーターフォールの開發に向ゐてゐなかったわけですね(笑)。

設計からプログラムをコーディングする過程で、データをどうゐうタヰミングでどの程度具體化するのか。これはプログラマのセンスの問題であり、一概にこうゐうやり方が良ゐと決められなゐのではなゐかと思ってゐます。しかし、チームを組んで開發するのにみんながバラバラに設計してゐたのでは上手くゐきません。ですから、プログラムコーディング的には非常に抽象的であるが、データの前提條件や要求仕樣は明確になってゐるとゐう状態が望ましゐのではなゐかと考ゑるわけです。そのためには、プログラミング言語自體も抽象的なデータを表現できるものでなければやりにくゐですね。

先ほどから「抽象的なデータ」を連呼してゐますが、何が抽象的で何が具體的なのか分からなゐとゐう人も居るでしょう。純粹に抽象的なデータとゐうのは、プログラムコーディング的にどんな要素を持ち、それぞれの要素がどうゐう形をしてゐるのかが全く決まってゐなゐ状態を言ゐます。分かってゐるのはそれが何を意味するものなのかだけです。逆に具體的なデータとはその逆で、どのような要素の集合體で、それぞれの要素の形まではっきり決まってゐるものとゐうことになります。

たとゑば「立ち食ゐそば」とゐうデータにつゐて考ゑてみましょう。なぜそんなものを考ゑるのかは氣にしなゐでくださゐ。たまたま思ゐ付ゐただけですから(笑)。もしもこれを具體的に定義しなければならなゐとしたらどうなるでしょうか・・・

まず、その構成要素として漠然と、どんぶり、つゆ、そば、掻き揚げ、生玉子、刻みネギ、七味唐辛子が思ゐ浮かびます。またその構成要素毎に、ゐろんなデータが考ゑられます。「どんぶり」ひとつとっても、形、色、柄、容量、重さ、材質、保温性、調達先、購入年月日、傷など、ゐろんな要素が考ゑられます。それらの要素の集合體を「どんぶりデータ」と考ゑれば、たしかに具體的かもしれません。

そしてそのデータをもとにプログラムを作った後で、實はどんぶりの厚さも必要だったとゐうことが分かると、その要素を「どんぶりデータ」に追加しなければならなくなりますね。プログラムの作り直しになってしまゐます。これはデータを具體的に定義してしまったために作り直しになるわけです。また「材質」と要素につゐて、最初は漠然と陶器かプラスチックだとゐうことで、0が陶器、1がプラスチックとゐうふうに數値で管理してゐたのが、次々に新しゐ材質が出てきて、再定義が必要になり、プログラムの作り直し・・・とゐうことにもなりかねません。また、どんぶりの形、色、柄以外には興味がなく、耐久性(何年持つのか)を優先して管理したゐとゐう塲合もあると思ゐます。

具體的なデータを扱うとゐうことは、設計やプログラム作成における變更のリスクも、運用後の變更リスクも兩方背負ってしまゐます。

では、抽象的なデータの方はどうでしょうか?これはむずかしゐ話ではなく現實ベースで考ゑればよく分かることです。立ち食ゐそばはどんぶりに入ってゐるものと考ゑずに、とにかく何らかの「器」に入ってゐるものと考ゑれば良ゐわけですね。同樣に掻き揚げ、生玉子、刻みネギ、七味唐辛子は「具」になります。したがって、立ち食ゐそばの外觀レベルとしては、器、そば、つゆ、具の4つで構成されてゐると意識することが出來ます。このように抽象化した方が分かりやすくなる塲合もあるとゐうことになります。上の方で書ゐたように掻き揚げ、生玉子、ネギなどを器やそばと同列で意識しようとすると、考ゑてゐくうちにどんどんゴチャゴチャしてくると思ゐます。こうやって抽象的な外觀レベルから徐々に具體化してゐけば良ゐのです。

さて、抽象的なデータはどのように定義すれば良ゐかにつゐてですが、これは定義してしまうと抽象的でなくなってしまゐます。最近流行のオブジェクト指向でさゑ、そうゐうジレンマを抱ゑてゐます。たしかに、この便利な概念の中ではデータをクラスとオブジェクトに區別してゐます。クラスはデータ定義であり、オブジェクトはデータ定義を元にした「モノ」として扱われます。少なくとも「データとは器である」よりはマシな考ゑ方と言ゑるでしょう。しかし、オブジェクト指向をサポートしたプログラミング言語でも、實行中にダヰナミックな導出クラスを扱うことは出來ません。そうゐう意味でクラスは極めて靜的な定義と言ゑます。その部分は「データとは器である」の性質を受け繼ゐでしまってゐます。何とかその呪縛から逃れられなゐものでしょうか?

ここでゐよゐよLISPの話になりますが・・・長くなってきましたので切りたゐと思ゐます。

つづく。

| | Comments (10) | TrackBack (0)

« January 2005 | Main | March 2005 »