『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
明日の発表のためにスライド書き。 ちょっと遅いだろうと言う気もする。
東京へ移動。 某企業との合同懇親会。楽しかった。
RubyConfの時に受けたインタビューがポッドキャストとして公開。 恥ずかしい。
Lispから見た「スクリプト言語」への苦言(？)。 だいぶ感情的になっておられます。
で、ですね、興味深いんで、ちょっと分析してみたい*1。
まず、どうやらこの方(えーと、KURODAさんですね)をもっとも怒らせているのは どうやら私らしい。というのも、
スクリプト言語ってのがあります。つづりが P や R で始まるあれです。
色々調べてみると、スクリプト言語の連中というのは、 何かといえば Lisp を引合いに出すのが常套になっているようです。
Lisp の不幸の1つに、
Lisp を使わない奴に限って Lisp について語りたがるというのがあるんですが、今回もう1つ加わったのは、
Lisp を知らない奴に限って Lisp を他のもの、なかでも自分の自慰行為の結果と比べたがる
っておっしゃっているが、
という条件に一番合致するのは、私しか思いつかない。
いや、怒らせるつもりはなかったんだけどなあ。しゃれですよ、しゃれ。
まず、第一に私はLispを知らないわけではない。 もちろん、職業的にCommon Lispでプログラムしたことがあるわけでないから、 第一線の方と比較すればまだまだのは当然だが、 Lispについて語る資格がないほど知らないわけではないと思う。
いや、ないのかな。思想や歴史の概要ならともかく、 その歴史を体験したわけでもないし、 Common Lispの仕様のすべてを把握しているわけじゃないし。 今日もCommon LispでSymbolに対して適用可能な操作のリストを見つけようとして 四苦八苦したもんな。
「(Common) Lispについて精通した人でないとLispを語る資格がない」っていうことなのかもしれないが、 そうだとすると、まあ、ずいぶんと敷居の高い言語であるなあとは思う。
私のどの発言がどんな「トンデモ」に感じられたかは、 ここではわからないが、私自身はいつもLispという言語に対して 「リスペクト」しているつもりである。 仮に少々揶揄することはあるにしても、それは親しみを込めた発言のはずだ。
私のLispに関する発言は、基本的には以下に分類される。
最初のものは、つまり、「Lispのこんなところがすばらしい」ということだ。 ほめているわけだから、非難されるいわれはない。 あるいは「お前なんかから言われたくはない」ってのはあるかもしれないけど。
次のところは、要するに「Lispのあるところは(ある種のスクリプト言語には)不要だ」 ということだ。これは 「Lisp の良いとこを取ろうと思ったら最低 ANSI にあるものは全部入れとかないといけない」という発言と対立しているから、KURODAさんとは意見を異にしている。
もちろん、これは「Lispの良いとこ」の定義によるわけだが、 KURODAさんの場合にはその定義は明確である。「最低ANSIにあるものは全部入れとかないといけない」という発言からは「Lispの良さとはCommon Lispであることと同値である」ことが引き出せる。疑問の余地はない。
おそらくKURODAさんにとってはそうなのであろう。そこは否定しない。
しかし、おそらく不幸なことに、すべての人がKURODAさんに賛成するかと言うと そうではなさそうだ。しかも、より不幸なことに、 KURODAさんに賛成する感性を持つ人は、業界を見まわす限り、かなり少数派のようだ。
そのような少数派の人の持つ自意識を端的に表現した引用があった。
(Common) Lisp has been the language from which inferior people picked good ideas when they could not handle the full language. -- Erik Naggum
(Common) Lispは、真の言語を取り扱えない劣った人々がアイディアを取り込んでくる言語である
その通り。 我々、「劣った人々」はLispで実験され実証された優れたアイディアを 長年言語に取り込んできた。Lispは言語機能のテストベッドとして非常に優れている。
しかし、先鋭的なLispな人にとって計算外なことは、 業界の人間の大多数がいわゆる「劣った人間」で、 Common Lispには堪えられない、あるいは必要としていない、 という「事実」だ。
そして、私を含む大多数の「普通の人々」は、 Lispがいくら優れた言語でも、Lisp以外の「劣った言語」のユーザを 「劣った人々」と公言するような「Lisp選民」とのお付き合いには 抵抗がある。
今までLispという言語について語ったことはあったけれども、 LispコミュニティやLispユーザの精神性について言及したことはなかった(と思う)。 しかし、今回のことで「Lispが広まらないのには括弧以外の理由があるのかもね」と 強く感じた次第である。
参考: comp.lang.lisp: how I lost my faith
Erann Gatが、 Googleに移ってLispへの「信仰」を失い、Pythonに移行したという話。 「Lispじゃなきゃ」というのが思いこみであったとの告白。
あと、KURODAさんは「言語仕様を小さくまとめてライブラリで言語をリッチにしていこう」という考えを「残念ながらこれは端的に間違ってます」と簡単に断言しておられるが、 もしかしたら、これも同様に「思いこみ」から来る結論かもしれない。 Common Lispの著者の一人でもあるGuy SteeleのFortressは、 まさにそのアイディアを具現化しようとしてるのだから。
いや、KURODAさんがglsよりも正しい可能性は否定できないけど。
追記
「ある言語のユーザーの中に、自分にとって不快な言動をする人がいる」ということを言語自体や言語のユーザー全体をけなす理由にするのは反感の元」という指摘が。
また、こういう指摘も
言語Xのユーザーは、特に有名なユーザーは、同じ言語Xのユーザーから言語Xを使わないことを理由になじられたりはしません。だから「言語Xを使わないことをなじる言語Xのユーザー」がいないと感じてしまうんでしょうか。
まあ、もっともである。が、少々補足したい。
まず、誤解されないために、私が以下のように思っていることを明記したい
私自身はKURODAさんの選民意識は理解できるし、 さほど不快でもない。論理がおかしいとは思うけど。 おまけにこれでますます「普通の人々」がLispから離れちゃうんじゃないかと危惧するけど。
さて、Ruby厨についてであるが、 そういう人がいるという話は聞いている。 まさに上記の理由により私はあまりお目にかかったことはないけど、 存在は認識している。
しかし、少なくともその多くは選民意識によるものではない。 っていうか、Lispのようなある意味特殊なポジションにいる言語と違って、 大衆に受け入れられやすい言語のひとつである(しかも、類似ポジションの言語が複数ある) Rubyに対して「選民意識」を感じたとしたら、 それは単なる無知から来るものであろう。
*1 なんてことすると、ますます怒らせちゃうかも。
This work is licensed under a Creative Commons License.
だれも私には聞かないと思いますが、私が「Lispどうですか？」と聞かれたら、「いい言語だと思いますよ。もう少し括弧を書かなくて済むならば。」と答えるようにしたいと思います。
最近はRuby選民というか、Rails選民も増えつつあるような気がします。
引用元のページでは、マクロやeval-whenという、ライブラリ<br>として提供することがそもそも困難な機能を例として挙げて<br>いるわけですから、元の文章の文脈では、ライブラリで<br>言語はリッチにならないというのは、間違っていないと<br>思います。<br><br>ちなみに、Fortressのアプローチは、「可能ならば」ある機能を<br>言語仕様としてよりもライブラリとして提供するべきであり、<br>ある機能をライブラリとして提供するために必要な言語仕様<br>があれば積極的に導入するという方針に見えるので、<br>ライブラリで言語はリッチにならないという結論とは必ずしも<br>相反しないのでは無いかと思います。実際、Fortressの言語<br>仕様は全然小さく無いですし、結構大きい言語だと思います。
こうゆう人に限ってRubyにはまったりする。
＞Common Lispの仕様のすべてを把握しているわけじゃないし<br><br>ここを読んで大笑いしました。あとにも先にも、ここでしょ。glsは同じ間違いを繰り返さないと思いますよ。
みずしまさん、<br>元の主張が「言語を拡張しないとリッチにならない_こともある_」というのであれば、その通りですが、そうとは読めませんよね。そのすぐ前に「ライブラリによる拡張という方針は端的に間違っている」と主張しているのですから。
以前、ll Weekendでお会いしたPythonユーザ会の方（お名前は失念）の、「lispって、あれがcommonだって言い張るところが最大の弱点だよな」という発言を思い出しました。
まつもとさん<br>> 元の主張が「言語を拡張しないとリッチにならない_ことも<br>> ある_」というのであれば、その通りですが、そうとは読め<br>> ませんよね。<br><br>はい。そこはその通りだと思います。僕が言いたかったのは<br>そういうことではなく、言語のリッチさというものの定義が<br>KURODAさんとまつもとさんとでそもそも違うのでは無いかと<br>いうことです。<br><br>具体的には、KURODAさんは「ライブラリで言語はリッチに<br>ならない」という主張の根拠として、そもそもライブラリで<br>実現困難な機能(マクロやeval-whenなど)が存在することを<br>示したわけですから、KURODAさんの考えるところのリッチな<br>言語というのは、たぶんライブラリで実現困難な機能を<br>(たくさん?)抱えた言語のことなのだろうと解釈しました。
ライブラリでは実現不可能なリッチさが存在することは否定しません。っていうか、Rubyはむしろそういう点の多い言語です(マクロでリッチにすることを許す代わりに言語機能に組み込んじゃうとか)。<br>しかし、それを根拠に「ライブラリではリッチにならない」という発言は、論理が破綻してると思います。「ライブラリではリッチにならない」が成立するためには、「ライブラリではリッチにならない領域がある」では不十分で、「ライブラリでリッチになる領域はない」とか「ライブラリでリッチになる領域はすぐに充足できるくらい狭い」とかが成立する必要があるのではないでしょうか。<br><br>仮にKURODAさんの「リッチさ」の定義が違うとしても、それは「ライブラリでは実現困難なリッチさ」というかなりトートロジーな定義しか私には読み取れません。そりゃ「ライブラリでは実現困難なリッチさ」は、いくらライブラリを充実させても満たせませんよね。でも、それって論じる意味があるの？<br>そんな誰も主張してないことを一生懸命否定されても。<br><br>一般論とするにはかなり不自然でしょう。
一般論とするにはかなり不自然というのは確かにそうなのですが、あの文章を読んで僕はそういうトートロジーな定義だと解釈した方が妥当では無いか(逆にそう考えないと文章全体としての解釈に困る)と考えたということです。
トートロジーな定義ならミクロな視点での論理的整合はできそうに思えますが、そのような定義はそもそもなんの役にも立たないと言う意味では論旨が破綻しているように思えます。<br>私の読み落としている「なにか」があるのかもしれませんが、それはそれでなんなのか知りたい気がします。
ネタでしょ。
ネタならいいんです。<br>私が「ジョークがわからない奴」ということで終わりですから。
「Lisp を『使わない』奴に限ってLisp の評論をとうとうとやるわけです」と述べるあのエッセイは「[PR]を『使わない』者が[PR]を語る」という自己撞着を含むことでジョークたりえているのではないでしょうか（と深読みはするが真意はわからない）。
＞「lispって、あれがcommonだって言い張るところが最大の弱点だよな」<br><br>MACLISPとINTERLISPのcommonという意味じゃないのですか？
手元のCLtL(日本語第1版)には序文に<br><br> Common Lispは新しいLispの方言であり、MacLispの後継者である。<br> ZetaLispに強く影響を受けている。また、ある程度Schemeや<br> InterLispの影響も受けている。<br><br>とあります。また、<br><br> 反論するよい理由もない限り、Common LispはZetaLisp、<br> MacLisp、InterLispに、およそこの順で互換性を持つようになっ<br> ている。<br><br>そうですよ。最小公倍数(Least COMMON Multiple)を目指したことには変わりないでしょうが。
すいません。「みず」さん引用の文脈のcommonが「普通/一般」を意味すると思って反応したんですが、違ったのかな？
本題と全然関係無いのですが、上の「みず」というハンドル<br>という人は私とは別人なので、念のため。
Common Lisp標準の制定のプロセスを考えれば、そこで標準に「組み込まざるを得なかった」機能の数々は、10年20年と保守されるようなシステムを記述する言語には必要とされる可能性が高い、ということを黒田さんは言ってますよね。<br><br>PerlやRubyは、言語仕様が標準として確立されているわけでもないし、実装＝仕様ということになっている。だから、処理系のバージョンアップの際に、過去のプログラムが動かなくなることがよく起きる。Common Lisp標準が大きすぎるという理由でそのサブセットを作っても、結局処理系のバージョンアップが必要となるのではないですか？というのが黒田さんの主張だと思いますけどね。
私にはそこは読み取れなかったのですが、10年20年動くプログラムにはきちんと規格が定義されている言語が有効というKURODAさんの主張はもっともだなと思います。<br><br>しかし、現状のLispの使われ方を見てると、それは実はそれほど重要な要因ではないのだろうな、とも思います。