Twitter で「言語のしくみ」読みたいなって呟いたら Matz 本人から「献本しましょうか」とメンション頂いて即答でお願いしました。ありがとうございます。
まつもとゆきひろ 言語のしくみひさびさ紙の本を通勤電車の中で立ちながら読んだので手がだるくなりました。なんだか懐かしい感じがしました。
さてこの本ですが、一言で言うとこんな本です。
Ruby のパパこと Matz が雑誌の連載に追われながら試行錯誤して作ったプログラミング言語「Streem」を解説する本
聞こえが悪かったらすみません。言いたいのはこの「試行錯誤」がとても良いエッセンスになっている点なのです。実際にはその連載記事をまとめた物に対して、この当時はこの様に考えていたが後になってみると実は良く無かったといった振り返り「タイムマシンコラム」で構成されています。
この連載が1つの本に纏められた事でプログラミング言語設計者の葛藤が非常に良く表されているな、そう思ったのです。本書の中では Matz が「以降 Streem をこういう設計にしたい」と考え実装していくのですが、いくら Matz とは言えど設計に迷いは生じます。連載の為に期間も守らないといけません。どっちが良いか迷って実装してしまった後、次月号で別の実装に直してしまうといった内容も出てきます。一エンジニアとしてすごく共感できました。はじめから出来上がった Streem に対して解説して行く内容になっていたら、もしかするとこんなに面白くなっていなかったかもしれません。
内容は Streem を設計(デザイン)し実装していく過程を細かく書いてあり、プログラミング言語を作る過程に必要な知識や歴史、なぜあの言語はそういうデザインになっているか、なぜ Ruby はこうなっているのか、そういった Matz でしか知り得ない内容も盛りだくさんです。プログラミング言語に興味のある方は買いではないでしょうか。
ところで皆さん、プログラミング言語って作った事あるでしょうか。プログラミング言語の実装は、一般的なライブラリやツール類と比べると設計や実装内容が幾らか異なります。正直、技術スキルも要します。ある程度動く様な形に持っていくには何度も心が折れそうにもなります。インターネットのブログ記事で「○○言語を作った」といった内容を読んで
なんとなく理解はできる。僕もやればきっと出来る。でも時間がない。
そう考えている人もいるかもしれません。僕も大昔はそう思っていたかもしれません。ただ幾らかプログラミング言語を作ったり、色んなプログラミング言語にコントリビュートしてきた経験のある僕からひとこと言わせて貰えるならば、こう言いたのです。
プログラミング言語はある程度の自信がないと作れないが、作れるとそれはより大きな、そしてより確かな自信へと変わる
ちょっとカッコ良すぎる事を書いてしまいましたが、実際にそうなのです。人生の中でプログラミング言語を作るなんて事は何十回もやれる経験では無いです。だからこそ自分が手掛けたプログラミング言語が一様に動く様になった際には、なんとも言えない愛着が湧いてくるのです。そして至らない設計を見つけた際にはとにかく憎たらしくもなります。自分で作ったプログラミング言語と葛藤する事になります。「なんでこんな設計にしちゃったんだよ」と自分を戒める事も多々起きます。でもそれを乗り越えた時の満足感は、実装してみた事がある人しか分からない自信へと変わるのです。
Matz も本書で書かれていましたが、プログラミング言語をデザインしている時はよく手が止まります。僕のケースであれば、よくブツブツと喋っているそうです。プログラミング言語を作るにはコンピュータを触っていない時間の方が大事だと僕は思います。あーでもないこーでもないと頭を捻って編み出した最適化がうまくキマった時には誰かに言いたいけど誰にもいえない変な喜びが起きます。プログラミング言語を作った事がある人ならば分かって貰えると思います。一見一人でブツブツ言ってニヤニヤしてとても変態っぽいのですが、そんな僕から見ても Matz の言語オタク度は手の届かない領域だと分かる一冊でした。読みながら「ほんとに言語好きなんだなw」と言いたくなりました。プログラミング言語に係った事がある人ならば、とにかく読みながら「うんうん、分かる分かる」と言いたくなる本です。その中でも特に「わかるー」と言いたくなったのが以下の一言です。
開発者・設計者が使いたい言語そして機能でないとユーザは使ってくれない
手前味噌の話ですが、Vim script には lambda が無くとても不便でした。リストを並べ替える sort に比較関数を渡す為だけに名前付き関数を定義しないといけませんでした。とにかく欲しくて何度か vim-dev に駆け寄りました。メンションは貰えるのですが、結局だれも作り出そうとしないまま月日が流れて諦めかけていたのですが
誰もやってくれないなら自分でやるしかない。だって世界中でこの機能が一番欲しいのは僕なんだ。
と心に決め、思うがままに実装しました。最終的には形はずいぶんと変わってしまいましたが、vim8 に lambda が入った際にはなんとも言えない満足感が得られました。
lambda 関数作ろうぜ！ · Issue #632 - vim-jp/issues - GitHub
キャプチャされる関数の引数名がキャプチャする関数の引数名とバッティングすることは通常どの言語でもあり得ますし、一般的にそういう場合は一時変数で別名に預けるか、JavaScript の様に即時関数を作っ...
https://github.com/vim-jp/issues/issues/632
やって良かった、そう思います。
さて話を戻します。冒頭にも書きましたが、本書には「なぜ Ruby はこうなっているのか」が何度も登場します。特に僕が面白いなと思ったのは「Ruby のブロックの設計と、作者が意図していなかった使われ方」の話です。Matz の考えたブロックはイテレーションを実現する為の物でしたが、実際にはイベントハンドラであったり、コールバックであったり、select の様な条件記述であったり、スレッドや fork のインスタンスであったり、時には設定ファイルの DSL だったりもします。これらはユーザが考えた使い方です。作者が意図していなかった設計が違う方向で広がっていったという話はとても面白かったです。僕も libuv の mruby binding である mruby-uv でイベントハンドラやコールバックとして使わせて貰っています。
GitHub - mattn/mruby-uv: interface to libuv for mruby(experimental)
README.md mruby-uv interface to libuv for mruby(experimental) License MIT libuv Current mruby-uv use...
https://github.com/mattn/mruby-uv
もう1点、面白かった内容として上げたいのが「言語設計者のマーケティング論」です。どうやったら人気が出るのかを Ruby の作者である Matz が思いを喋っているのは、とても興味深い物でした。せっかく苦労して作った物なので、誰かの目に止まって欲しいですよね。
ところで本書には僕の名前が何度か登場します。Matz が Streem のリポジトリを公開し、まだコードも無いのに Hacker News で取り上げられ、話題性が落ち着いてきたそんな頃、僕はある pull-request を送りました。
WIP: tiny VM by mattn - Pull Request #101 - matz/streem - GitHub
You signed in with another tab or window. Reload to refresh your session. You signed out in another ...
https://github.com/matz/streem/pull/101
これまで BNF のシンタックスチェッカーでしか無かった Streem に処理系のコードを足しました。当時は Matz にもいろんなカンファレンスでスライドのネタとして扱って頂き見ていてとても楽しかったのを覚えています。ただし本書でも書かれていますが、僕がやったのは継続的なコントリビュートでは無いのです。OSS を運営する上で本当に必要なのは、継続的に手を動かしてくれるコントリビュータ達です。一人の手で出来上がったプロダクトには、作者の考えしか入り込まないので「本当に皆が欲しいと思っている機能」は出て来ない事があります。こういった OSS とコントリビュートに関する話が Ruby の生みの親の言葉として読める点も、本書の楽しみ方の一つだと思います。
この本があれば、「プログラミング言語が作れるかも」そんな気持ちになると思います。ぜひ自分の言語を作ってみて欲しいと思います。そして迷って躓いて悩んで乗り越えた時に得られる満足感を、ぜひ体験してみて欲しいと思います。
