2005年11月アーカイブ
仕事は相当忙しくなってます。
デフォルトで週休1日になってるし!
お金もらえるんだからいいでしょ、
ってありえないから。フザケルナ。
時間が買えるならいくらでも金稼ぐ…てアレ?
今月も実家以外どこもいってね。
寒いからってのもあるんだけど、
そろそろどこか行きたいなぁ。
仕事落ちついてくれないかなぁ。無理だろなぁ…
普段の生活にゆとりがないと休みの日も引き籠ってウダーとなるのです。
本。
今月は全て前半で消化しました。
後半は全く本を読みませんでした…
そして今も読む気力/時間なし状態。
ま今年も100冊はあきらめモード。
- 喬林知 / 今日からマのつく自由業!
- 羽生善治 / 決断力
- 竹内薫 / ループ量子重力入門
- 沢木耕太郎 / 深夜特急(6)
- 笹氣健治 / 仕事がイヤ!を楽にするための本
- 山田真哉 / 女子大生会計士の事件簿 (1)
- randy / いまどきのプログラム言語の作り方
マのつく。女子向けラノベです。
帯に350万部突破!って書いてあったので、
ほぉ面白いのかなぁ、と手に取ってみた。
結果、あまり面白くなかった。
ま感性の違いなので致し方ないかな。
ちなみにプログラマではないです。
羽生さん。
ま正論書き並べてるな、それなりに参考になるなと。
短編集みたいな文章だけど、それぞれの章を一気に
読んでみると内容の冗長性が微妙に気になる。
リファクタリングしる。
ループ量子重力。
超ひも理論が量子論の後継者なら
ループ量子重力論は相対論の後継者みたいらしい。
空間/時間の量子化を行うというのに惹かれて読んでみた。
さっぱりわけわからん。
これは入門書じゃありません。
著者が好きなこと書いてるだけ。
はっきり言って理解してもらおうという気が感じられない。
あるいは説明が下手過ぎか勘違いしてるか。
ループ量子重力論自体は面白そうな雰囲気はびしびし感じるので、
もうちょっとまともな入門書or読み物が登場することを期待する。
深夜特急。
ロンドン着。旅の終り。
予想通りあっけなく終わった。
私は外国に行ったことがないのですが、
この本から外国に旅することの面白さがたくさん伝わってきた。
海外行きたい、そのうち。
仕事がイヤ!を楽にするための本。
イヤです。<そんなハッキリと…
仕事が嫌だと感じるときは、
原因を周りのせいにしている状態「支配モード」と、
自分の能力などに落ち込む状態「自虐モード」の2つであると。
ま行ったり来ったりしますわな。
なんで俺が! て言うのはしょっちゅう内言として発してるなぁ。
で、嫌にしないためには、
自分のせいにも他人のせいにしもしない「安定モード」になるべしと。
この4つの心理モードマトリックス中の安定モードというのはWin-Winの関係と似てるね。
前のエントリにも書いたけどプラス方向を絶対視する姿勢がどうもねぇ…
このシリーズの前作がけっこう良かったので買ってみたのですが、
やはり文章が読み易く分量が少なめなのは良い。
ただちょっと前作と比べると内容が薄くなった気がする。
山田真哉 / 女子大生会計士の事件簿 (1)
会計ネタでミステリっぽいラノベみたいな。
ま狙い目としては上手いとは思う。
しかしやはりこういうネタ(会計)は私はダメだ。
何が面白いんだかさっぱりわからない。わかりたくもない。
つことで続編は読まない。
randy / いまどきのプログラム言語の作り方
処理系を一からインクリメンタルに開発。
この本については別エントリ切ったのでそちらを参照。
映画。
レンタルだけど今月はけっこう見たぞ。
- 北の零年
- DEEP BLUE
- いま、会いにゆきます
- ラーゼフォン 多元変奏曲
- 僕の彼女を紹介します
北の零年。ふと、さとみんが見たくなり…
邦画では珍しくスケールがでかい。
山あり谷ありの見所満載な映画です。
ちと欲張り過ぎな気がしなくもないけど。
DEEP BLUE。海、海、青い海。癒され~
海にもっと近づきたい。
途中何度が意識が跳んでしまった。
いまあい。これ最強。殿堂入り決定。
映画館で見なくて良かった~、と本気で思ったw
やばいよこれは号泣系つぼはまり過ぎ。ぽっぽやを越えた。
つか最初の30分くらいの時点で既にやばかった。
ネタはタイムリープに似ている。
タイムリープは肉体時間と精神時間が同期しない、
という話なので肉体がなければ精神はありえなかった。
しかしこれは死後つまり器が存在しない時点に
リープしているので、科学的説明は困難。
まそんなことはどうでも良いかもw
ラーゼフォン。
エヴァのパクリっちゃぁパクリなんだけど、私は好きですねぇ。
オリジナリティを持った世界観はしっかりできてると思います。
この映画版はよくわからん、つかTV版の記憶が曖昧だからかな。
あのミサトさんみたいな人って黄色のワンピースの子と
TV版で同一人物だったけ? 全然そんなこと感じ取れた記憶がないのだが…
僕の彼女を紹介します。猟奇的な彼女の監督だそうです。
でもでも、これは後半がダメ過ぎる。
前半のドタバタラブコメな流れは良いんですよ。
警官制服のチョン・ジヒョン様も完璧です。
ただあの男役の方が風になりたいとか言いだしたあたりから、
もうボロボロ、ぐだぐだ、なんじゃこりゃ状態。
意図がわからない。何が言いたいんだか…
あの前半のノリで通して欲しかったなぁ。
悲劇なら悲劇で落とすも良し、
一つのシーンをしっかりゆっくり描いてくれれば良いのに。
音楽。
レンタルだけど今月はけっこう聴いたぞ。
- WANDS / complete of WANDS
- LINKIN PARK / METEORA
- 倉木麻衣 / Wish You The Best
- 喜多郎 / THE BEST OF GRAMMY AWARDS
- KoRn / Follow The Leader
- HALCALI / 音樂ノススメ
WANDS。
時の扉と白く染まれが聴きたかったのだけど、
白く染まれが入っているCDが置いてなかった…残念。
Linkin。メロディックなので好きです。
たまにはこういうのも良いです。
HALCALI。
前リミックス版を試聴した時はもっとよく思えたのだけど、
こいつはあまりいくなかった。残念。
倉木。
いい音楽いっぱい。
冷たい海が一番好きかな。
マンガ。
- みなみけ(2)
- ベルセルク(23)
- ベルセルク(24)
- ベルセルク(25)
- ベルセルク(26)
みなみけ。あいかわらずもえで。
ベルセルク。仲間が増えて明るくなってきた。
魔法使いイイ! このままファンタジック路線で!
さてさて12月、今年も終わり。
いろいろ今後のこともじっくり考えたいのですけど、時間がない!
くそぅ… とりあえず今をこなすしかないのです。
風邪ひきてぇとか事故りてぇとかしょっちゅう思いますけど、
健康なことは素晴しいのは言うまでもなく、
感謝して、生きたいね!
では。
mieのユニークかもしれない特徴として、
オブジェクトとクロージャが同じである、という点があります。
オブジェクトとクロージャは等価だ、という話は聞いたことがあるかもしれません。
Schemeのオブジェクトシステムなんかはクロージャでオブジェクトを作っているんでしたっけ。
逆にクロージャをオブジェクトで表現することもできます。
これはRubyのProcオブジェクトとかで、処理をオブジェクトとして受け渡しできるようになります。
でもでも、等価だと言いつつ違うじゃんか、と思いませんか。
等価なんだったらオブジェクト、クロージャ、というのは呼び方の違いだけで、
言語的には全く同じものであっても良いのではないかと思うのです。
mieのオブジェクトには波括弧と角括弧の2つの書き方がありますが、
同じものであるということを強調するため、今回は波括弧だけを用いることにします。
オブジェクトの要素部にはデータが入り、挙動部には処理が入ります。
{ 要素部 | 挙動部 }
例えば、
{ x | x * x }
と書けばxというデータを要素部として持ち、
xを2乗するという処理を挙動部に持つオブジェクトになります。
このオブジェクトはxを2乗する関数であると言えます。
このままではxは具体的な値を指していないので、
実際に使う時にはメタ結合によって値を束縛します。
{ x | x * x } <+ {2|};
2つのオブジェクトを結合すると、新しくオブジェクトが生成されます。
そのオブジェクトは次のようになります。
{ x = 2 | x * x }
未束縛状態の変数xに、整数2が束縛されます。
ここで生成されたオブジェクトは実行可能になりました。
実行してみます。
{ x = 2 | x * x } !;
--> 4
とここまでは前回の復習です。
さて、2乗する関数の例はどうみても関数であって、あれをオブジェクトとしては見れないかもしれません。
それではオブジェクトっぽい例を出してみます。
mieの行コメントは--で始めます。(Haskellと同じ)
具体的なオブジェクトを直接書く場合。
-- 太郎君の身長は150cm、体重は50kgです。
taro = { height = 150, weight = 50 |};
クラスのような抽象的なオブジェクトpersonを用意する場合。
-- 人間には身長と体重があります。
person = { height, weight |};
-- 太郎君は人間で、身長は150cm、体重は50kgです。
taro = person <+ {height = 150, weight = 50|};
personのheightとweightは未束縛であるため、
オーバーライドする要素は順番に書く分には名前を省略することができます。
taro = person <+ {150, 50|};
次のようにメタ結合を2回に分けて記述することもできます。
この場合も要素名は省略可能です。
-- 太郎君は人間で、身長は150cmで、体重は50kgです。
taro = person <+ {height = 150|} <+ {weight = 50|};
taro = person <+ {150|} <+ {50|};
ここまではデータ構造だけを定義してきました。
次に処理を記述します。
BMI指数を計算する関数を作り、太郎君のBMI指数を求めてみましょう。
ちなみにBMI指数とは肥満度を計る一つの尺度です。
-- BMI指数は、身長と体重を引数に取り、体重を身長の2乗で割った値を計算する関数です。
bmi = {height, weight| weight / (height / 100) ** 2};
-- BMI指数を、太郎君の身長と、太郎君の体重から計算します。
bmi {taro.height, taro.weight|};
--> 22.2
上の例は関数(bmi)とデータ(taro)がはっきりと分かれています。
しかし定義を見ると2つは同じように表現されています。
taro = { height = 150, weight = 50 |};
bmi = {height, weight| weight / (height / 100) ** 2};
これがオブジェクトとクロージャは同じであるということです。
さて、せっかくオブジェクト指向な言語を使っているのですから、
関数bmiはオブジェクトのメソッドにしたくなりますよね。
personオブジェクトのメソッドにしてみます。
heightとweightはpersonの要素を使うので、bmiメソッドの引数としては不要になります。
よってbmiメソッドは要素部が空なオブジェクト、つまり処理しか持たないオブジェクトになります。
-- 人間には身長、体重、BMI指数があります。
-- BMI指数は体重を身長の2乗で割った値です。
person = {
height, weight,
bmi = {| weight / (height / 100) ** 2}
|};
一般的な言語ではheight,weightをフィールドと呼び、bmiをメソッドと呼びますが、
mieにおいてフィールド、メソッドの区別は、
どう利用するかというプログラマ視点の役割でしかなく、
その実体は言語的には同じです。
bmiメソッドを追加したpersonを継承し、taroを再定義してみます。
-- 太郎君は人間で、身長は150cm、体重は50kgです。
taro = person <+ {height = 150, weight = 50|};
-- 太郎君のBMI指数を計算します。
taro.bmi[];
--> 22.2
ところで、personオブジェクトには挙動部がありません。
なんとなく勿体ないから、ここにbmiメソッドの処理を記述してみましょう。
人間の価値とはBMI指数で決まるのだよ! と思うなら、
次のようなオブジェクト設計にしても良いということです。
# よいこのみんなはまねしないでね☆
person = {
height, weight
| weigth / (height ** 2)};
-- 身長160cm、体重90kgの人間を計算します。
person [160, 90];
--> 35.2
今作ったpersonオブジェクトですが、先程作ったbmi関数と同じになってしまいましたね。
並べて比べてみましょう。
person = {height, weight | weigth / (height ** 2)};
bmi = {height, weight | weight / (height ** 2)};
この結果からもオブジェクトとクロージャが同じだということがわかると思います。
mieはこういうやわらかーい言語です。
やわらかいのが嫌だったら、自分でかくあるべき!という掟を
いろいろ作って固く仕上げれば良いのです。
でも最初からかたいものは、やわらかくすることができません。
オブジェクトとクロージャ、データと処理が同じだというのは、
なーんだ関数の引数と構造体のメンバを一緒にしただけじゃんかー。
そうです、そうですがそもそも関数と構造体が同じなのです。
だからこそフィールドとメソッドの区別がいらないわけです。
viva 統一性!
參った。やる気が起きない。
昨日今日とぐうたらに尽してしまった。
久々の休みだというのに。
でも久々だからこそなのだ。
一日後二日後の自分の姿が見えて鬱になる。
どうにも動けなくなってしまう。
溜息ついてはお茶を飲み、頭を垂れる。
数分後、涎垂らしてはっとなる。はぁ。
やる気なさすぎなのでテレビでもつけてみる。
どれも興味なし。つまらないので切る。その間30秒。
まず本を読む気に全くなれないというのは重症だと思う。
手に取ることすら考えられない。なんなんだ一体。
意味不明な抑圧された感情が喉の奥で蠢いている。
世間はポジティブ万歳ネガティブ逝ってよしと言うけれども、
僕はこの風潮に対して非常に胡散臭いものを感じる。
無理にネガティブを捨て去ってみても逆に空虚になるだけな気がする。
僕はネガティブなものを受け止めて生きていきたい。
そもそもなんでポジティブなのか。
その方が人間関係がスムーズになるからとか
そういう答えしかできないようなら消えてくれ。
摩擦はない方が良いのか。
楽に生きたいのか。むしろお前らが逃げてるんじゃないのか。
ネガティブに魅せられた人々に負け組のレッテルを貼って隔離して蔑視して喜んでるやつら。
逃げてるのは、向き合うことを怖れた、見たくないものに蓋をした、
ポジティブシンキング万歳なお前らの方だってばさ。
せいぜい馴れ合ってWin-Winの関係でも築いていなさいってこった。
鬱屈としている。
憂鬱で屈折したネガティブまっしぐらな状態。
ぼうっとただ時が過ぎるのを見つめて、
考えているようで考えていない。
何も建設的な結論など出ないし、出そうという気は皆無。
結論なんていらない。
答えは簡単だとか言ってるんじゃないよ。
あんたが簡単な答えしか言ってないだけだろう。
答えなどないと言い切れば答えはないのだ。
答えがあるかどうかなど興味がないと言えば、
答えを出すことは無意味なのだ。
だから曖昧な取りとめのない時間がただ過ぎてゆくだけ。
消え去ってゆくだけ。
何が楽しくて嫌なものを想像して大事な時間を失うのか。
全くネガティブである。
想像までしなくてもうざいカビが頭にこびりついたまま離れようとしないのだ。
どうしようもない。どうしたくもない。
だから流れるだけ。解決はない。結論もない。
何もやる気が起きないので、文章を書いている。
書く気が起きたじゃないかと言われればまぁそうなんだが、
睡眠状態は平均的にニュートラルだし、
気が付けば朝かというのも非常に気分が悪いので、
ネガティブなまま頭を活動させたままにしておこうと思ったまでである。
それにしてもどうしたことか。
解決はいらぬとは言ったもののこの状態がずっと続くとなると話は別である。
明日になれば綺麗になっていれば良いと思う。
精神状態としてネガティブなことは悪いものではないと言った。
でもinput/outputの効率が下がることは間違いない。
仕事を行う上で、ネガティブが続くのはよろしくない。
ネガティブフィートバックループに陥いって抜け出せなくなる恐れもある。
それと今を処理している下層の精神よりも高位の意思が、
あれをやるべし、これをやるべし、とせきたててくるのもよろしくない。
やらなきゃならない、もしくはやりたい、
と思っているにもかかわらずそれが実現できないのは、
自己信頼残高からの引き落としになる。
これが続くと自分に自信がなくなる。
やりたい、という気持ちをも阻害する。
でも、目標達成は重要だとは思うけど、
無理することはないか、なんて甘えたことを考えている。
阻害要因が明確に存在しているのだから仕方がない。
もっともそれを予測できなかった自分にも非はある。
でも無理矢理実現させてみてもねぇ…
というかただでさえ疲労困憊なのにその上頑張りたくない、
というのが正直なところである。
自由な時間がわずかしかないのであれば、それは休息最優先で使う。
弱いかもしれないけど、いいんじゃないかな。ということにしておこう。
しかしよく乱れる。
一週間というリズムは大切なのだと思う。
ああもう嫌だなぁ。仕事行きたくねぇなぁw
まぁ休みの終わりが一番鬱で、
仕事が始まってしまえば普通にこなせるものなんだけど。
今回は休みの初めから何故か鬱だったもんで、
休んだ気がしないというか…
つかいろいろ面倒臭い。もう少し良きに計らっていただきたいとか思う。
ああ、愚痴はだめだ愚痴は言わんぞ。よしよし。
どう考えても自分に責任がないとは思っても、
自分が関わっている部分が他人に迷惑をかけると
精神的ダメージを受けてしまうんですけど、
つかなんだかんだ言ってまだまだ繊細な少年の心を持ち合わせているようだぞ僕は。
いいともわるいとも言えんが、適度にネガティブでありたいかな。
なんか何されてもピンピンしている精神タフガイも味気ないよなぁとか思う今日この頃。
土日はボッシュートで萎々…
久しぶりに本の紹介です。
いまどきのプログラム言語の作り方。
これは良い本です。
処理系を作ったことがないけど、
どんなものか興味がある、作ってみたいという人に最適。
さらに、コンパイラの教科書は読んでみたものの
有限オートマトンとかLALRとか理論ばかりで
コードに落とせないとか、そもそも理論がわけわかとか、
yaccとかキモイツール使いたくないし、
ブラックボックスになってるのも嫌だしとか、
そいういう人にもおすすめ。
つまりは私にとってとても参考になる本でした。
mieで1+1を計算するプログラムは次のようになります。
1.+ <+[1]!;
--> 2
きんもーっ☆
…いや、まぁ普通にも書けます。
1 + 1;
--> 2
でなんで 1.+ <+[1]! が 1 + 1 となるのかというところを解説します。
mieでオブジェクトを定義するには次のようにします。
pt = [x = 10, y = 25];
これでx,y成分を持つ座標オブジェクトptが定義されました。
「名前 = 値」と書いて名前に値を束縛します。
上の式は、xという名前に整数10、yという名前に整数25を束縛したオブジェクトを
ptという名前に束縛する、という意味になります。
xやyに当たるオブジェクトの中身のことを要素と呼びます。
オブジェクトの要素を参照することを抽出と呼びます。
抽出を行なうにはオブジェクトの後にシンボルを記述します。
シンボルのリテラルは「.」で始まります。
よってptオブジェクトの要素xを抽出するには次のように書きます。
pt .x;
--> 10
空白文字は省略できるので、C言語などのメンバ参照と同じ見た目になります。
pt.y;
--> 25
mieではSmalltalkやRuby同様に整数はオブジェクトです。
加減乗除などのメソッドは整数オブジェクトの要素として定義されています。
先程のpt.xの例と同じように、1オブジェクトの要素+メソッドを抽出することができます。
1.+;
--> <builtin:Mie::IntegerObj::Add>
次にオブジェクトの拡張生成について。
ptオブジェクトを2次元から3次元に拡張したい場合、
次のように新たにz成分を追加したオブジェクトを生成できます。
pt <+ [z = 0];
--> [x = 10, y = 25, z = 0]
「<+」はメタ結合と呼び、2つのオブジェクトを重ね合わせたオブジェクトを生成します。
引数を2乗する関数squareを定義してみます。
square = {x|x * x};
引数xを受け取り、xにxを掛けた値を返す、ということです。
ここで{}は基本的には[]と同じで、オブジェクトリテラルです。
主に関数的に利用する場合に使います。
mieでは関数とオブジェクトは全く同等なデータ構造です。
定義されたsquareに対して整数3を要素に持つオブジェクトをメタ結合します。
すると引数(要素)xに3が束縛された状態になります。
square <+ [3];
--> {x = 3| x * x}
この時点ではまだ束縛されただけでx*xは計算されていません。
x*xを計算させるためには評価をする必要があります。
評価は対象となる式の後に「!」と記述します。
3を引数に束縛して、評価すると9が返ってきます。
square <+ [3]!;
--> 9
適用(メタ結合)してから評価する、という2段階で関数実行が行われることになります。
適用+評価はより簡潔に書けます。これはシンタックスシュガーです。
単に空白文字で区切ってオブジェクトを並べると、メタ結合した後に評価が行われます。
square [3];
--> 9
お好みで空白文字を取り除くことも可能です。
square[3];
--> 9
適用と評価が分離しているため、適用後のオブジェクトを一旦変数に保持しておき、
後で評価を行うということも可能です。明示的な遅延評価ですね。
これが役に立つのかどうかはわかりません。
tmp = square <+ [3];
tmp!;
--> 9
さらにもう一つのシンタックスシュガーを紹介します。
名前が演算子文字で始まる要素の場合、
object <element> arg;
と書くと以下のように解釈されます。
object.<element> [arg]
つまり、
1 + 1;
は次のようになります。
1.+ [1]
さらにこれに対して適用+評価のシンタックスシュガーを展開すると
1.+ <+[1]!
となるわけです。
これで、オブジェクト1の要素+メソッドに、要素にオブジェクト1を持つオブジェクトをメタ結合して
評価すると、オブジェクト2が得られました。ふぅー。
ちなみに、squareの例ですが関数リテラルで直接書くと次のようになります。
{x|x * x}[3];
--> 9
これもシンタックシュガーを使わずに書くと次のようになります。
{x|x.* <+[x]!}<+[3]!;
--> 9
なんとなく書けるうちに書いておいて少しでも知ってもらえたらなと。
需要があるようなら定期的に書いていきたいと思います。
わからないところとか気になるところとかコメント頂けると幸いです。
