Lispのマクロに対するPythonistaの意見

ura_nsui @ura_nsui

つーか。マジでマクロ・マクロうるせぇなって感じ。マクロって基本的に手抜きの道具でしょ？無ければ無いで、汗かくか、代替のライブラリ作ればいいだけじゃん。そら代替手段の実装はマクロに比べれば不格好になるかもしれないけど、本質はそこじゃない。「できるか」「できないか」。

pukuyan @pukuyan

@ura_nsui ラムダ・ラムダ言ってすみません。。

ura_nsui @ura_nsui

ラムダとマクロとは違う。lambdaなんて単なる関数オブジェクトって理解で全然OKじゃん。マクロは根本的に異質なんだ。黒魔術。使い時を誤ると暗黒面へ一直線。♻ @pukuyan: @ura_nsui ラムダ・ラムダ言ってすみません。。

ura_nsui @ura_nsui

マクロまんせーな人たちって、そこんとこの自覚があるんだろか？超疑問。

ura_nsui @ura_nsui

ルールを自分で作れるということは、そのルールが受け入れられる環境をも自分で作る必要が有るということと表裏一体。ある言語を選択することで発生する強制的なルールなら選択した者自身の問題だが、それ以外のルールが次々に発生するとなるとどうだろう？

ura_nsui @ura_nsui

例えばPythonであれだけたくさんのWebフレームワークが作られるのは何故かという部分と根は同じだと思うんだよね。フレームワークってのはお作法とかルールの世界。同じことがLispでマクロを使うと「言語」のレベルで起こる。この「言語のレベル」っのは想像以上に深刻だと思うんだよね。

ura_nsui @ura_nsui

ライブラリとかフレームワークというレベルでのルールは、言語というレベルのルールが同じ、もしくは同等という前提で成り立ってる。その言語レベルの前提がいつでも動かせるっていう状況ってのが一般的に「好ましくない」と捉えられるのは、そんなに違和感無いと思うんだけど。

ura_nsui @ura_nsui

個人的には、そういうアプローチがもうすこし一般化してもいいとは思ってはいる。「使いまわし」という本当に実施するか分からない未来の話をタテにして、今そこにある問題を美しく解決する方法を捨てるのが良策なのかどうかは状況依存になっちまうのが歯がゆいところでもある。

ura_nsui @ura_nsui

S式とそれを基盤としたマクロが提供する自由度ってのは、PerlがPythonよりも自由に書けるとかじゃなくて、もう1レベル上の自由度なわけだよね。でLispはこの自由をプログラマを信頼して開放しているわけだ。こりゃ「危険」だよ〜。享受できるメリットもデカいが、ヤバさもハンパない。

ura_nsui @ura_nsui

で、Lispの力の源泉はS式とマクロにあることは否定しないけど、こりゃやっぱヤバいもんだよ。マクロをベースにしてなにかをモデル化していくという行為に対して慎重にならざるを得ないわな。特に「仕事でLIspを使おうとしている」からね。趣味でやるぶんには「思う存分どうぞ」だけど。

ura_nsui @ura_nsui

そういう文脈下で「マクロは黒魔術」と言ってる。Common Lispにはリッチなデータ型いっぱいあるし、データ構造とそれに乗っけたデータをプログラムから弄るという、ふつーのアプローチで、よくある問題のほとんどは解決できる。多少面倒になることもあるかもしれないけど、

ura_nsui @ura_nsui

魔法をふんだんに使ってスマートに解決するよりも、このふつーのアプローチの方が、多くの場合、人に優しいはずなんだ。

ura_nsui @ura_nsui

Lispは極めてPersonalなツールなんだ。使う人がどんどん自分向けに便利にしていける。が故に初期状態では基本部分のみが提供されてる。最初から色がついてたら自分向けにカスタマイズしずらいでしょ。

ura_nsui @ura_nsui

でも、俺様カスタマイズされた道具が、他の職人さんにとって必ずしもベストな道具とは限らないし、道具そのものをカスタマイズするということを知らない人にとっては、なんか中途半端で使えない道具にしか見えない。これがLispが一般に理解されない本質だとおもうわけ。

ura_nsui @ura_nsui

もしくはガレージキットと着色済みプラモデルの間にある文化の差って感じかもね。

pukuyan @pukuyan

そうなってくるとプログラミング以前の問題というか、、女子力あげたい。@ura_nsui: でLispはこの自由をプログラマを信頼して開放しているわけだ。