娘が「おばあちゃんに会いたい」と言うので昼食を両親と一緒に。 敬老の日なので、なのかな。
もっとも、母親にうっかり「おばあちゃん」なんて声をかけようものなら、
あんたのおばあちゃんじゃない
と怒られてしまうのだけど。まあ、今時の60代はあんまり年寄りに見えないよね。
私がまだほんの小さかった頃に祖母と写った写真があるのだが、 この写真の中の祖母はほんとうに「おばあちゃん」って感じだった。 が、今計算すると当時の祖母は今の母よりも若いことになる。 うーむ、白黒写真や和服のせいではないと思うのだが。
で、昼食はバイキング。焼肉、寿司、スパゲティ、ラーメン、うどん、etc. 今日は体重のことはあまり考えないでおこう。
昼食後は子供を連れて公園に。ひとしきり遊んだら、すっかり疲れてしまった。
原稿..(以下略、笑)
よそで議論するのもなんなので、こちらにもって来よう。
まず、shelarcyさんの意見:
またマクロを間違いなく使えるようになるのと、オブジェクト指向を身につけるとどちらが難しいでしょうか？ もしマクロを使いこなす難しさがほぼ同等あるいはオブジェクト指向より容易であるなら、今のところはマクロを普通の人が使う言語に組み込んでも構わないのではないでしょうか？
私に限って言えば、オブジェクト指向を身につけるのが難しいと思ったことはないが、 マクロを間違いなく使うのはいまだにできないので、 答えは明らかだろう。(笑)
もっとも、これはフェアな比較ではないと思う。 パラダイムと言語の一機能を同格にするべきではないからだ。
繰り返しになるが、私はLispのマクロをどうこうしようというわけではなく、 新しい言語を設計するとして、その言語にマクロを追加することについて ユーザビリティの観点からのトレードオフを明らかにしたいだけだ。
Lispマクロの利点については理解しているつもりだ。
しかし一方で、
という点がある。
だとすると、プログラムを書くフォーマットとして「S式＋マクロ」と「より普通の構文」の いずれかを選べと言われたら、私はマクロをあきらめて普通の構文を選ぶ。
と、ここでshelarcyさんはこう来る。
あと、もう少しツールの存在に目を向けても良いのではないでしょうか？ 例えば、初心者には絶対にマクロを使わせたくないというのであれば、設定をいじらなければマクロを使えないようにしたり、ライブラリをインストールする形でしか使えないようにするといったような障壁を置いたり、ある種のマクロをフィルタする仕組みを持っている処理系(きちんとした形でマクロを使えるようになるまでテスト以外でマクロが有効にならない……っていうのは流石に実現が難しいでしょうけど)、S式についても XML のエディタのようにソースはS式だけど表現上は別の記法でそのまま編集できるのモードとS式で表示・編集できるソースモードを切り替えて使うことのできるエディタなどを想定して、そういうものがあれば受け入れられるかどうかという議論がなされないと実質的なユーザビリティから乖離してしまう恐れがあります。もっとも、本当はテストした方がいいのですが。
おっしゃることはもっともだ。 私は言語屋なので言語そのものに強くこだわってしまう傾向があるのを見透かされている。 IDEとか嫌いだし。
ただ、過去の言語の歴史の中で「ソースはS式だけど表現上は別の記法で」というアプローチは それこそ星の数ほど行われてきたのだが、生き残ったものはほとんどないという事実は、 私に「言語はその記法が重要である」という原則を教えてくれているように思う。
マクロという問題に限定すると、やっぱりS式を隠してはマクロのパワーを損ねると思うので、 ここであげられたようなツールではマクロとユーザビリティの両立は難しいのではないだろうか。
で、マクロが役に立つケースのかなりの割合は、高階関数で実現できる。 Rubyでは限定された高階関数が呼びやすい文法(ブロック)を導入することで、 ある程度支援しているつもりだ。
だから、
Ruby はイテレータなどで工夫しているなと思うのですが、繰り返し以外の用途でイテレータを使っている例などを見ると、マクロっぽい使い方をしているように思えるのですが、...
というotaさんのツッコミは鋭い。
それからshiroさんは、
このプログラム片の外側で、near, far, lerpといったマクロやグローバルな束縛が定義されたとしても、このプログラムの意味は変わりません。
(中略)
しかし、予約語の場合、例えばnear, farという識別子が予約語に追加されたとたん、上のようなプログラムは破綻します
と予約語の増加とマクロを比較しての優位性を述べておられる。
このマクロの良い性質についてあまり意識していなかったので、教えていただいたのはありがたいのだが、 予約語が安易に増えるような言語はそもそもユーザビリティの観点からは最低だと思うので、 比較の対象にはならないのではないかと。
ただ、その前に述べておられる
プログラムの読みやすさ、書きやすさを決めるひとつの重要な属性は、あるプログラム片を目にしたときに、その意味に影響を与える範囲が限定され得るということ、したがってその範囲さえ見ていれば、プログラム全てに目を通さなくてもそのプログラム片の持つ意味が完全に理解できること、だと思います。
という意見には完全に同意する。今後もこの原則は心にとめて行きたい。
〆切について愚痴ばかり書いていたので、心配されていた方も、もしかしたらいらっしゃるかもしれませんが、 一応ちゃんと終わりそうです。
まだ、あとふたつほど残ってますが、これもなんとかなるでしょう(希望的観測)。