103

プログラミング初心者(の編集者)による『実践Vim』レビュー

目次

  • Vimと私
  • 経緯と御礼
  • 強力に親切
  • 何度も言ってくる
  • 師匠になる
  • 読む前と読んでる途中と読んだ後
  • 体裁・翻訳について
  • 終わりに

Vimと私

それまでVimを使っていなかった人がVimを使い始める、というのは、PCに元から入っているメモ帳アプリを使っていた人がワードを使ってみるとか、Evernoteをメインで使っていた人がGoogleドキュメントに切り替えるとか、そういうこととはわけが違う。

それはどちらかと言うと、ローマ字入力で日本語をタイピングしていた人がかな入力に変えるようなものであり(逆でもいいが)、あるいは「エディタを替える」なんて言うとあたかもコクヨのキャンパスノートからモレスキンに替えることと同等であるように思えるが実際には長年横書きで統一して書き継がれてきた日記を今後は縦書きでいく、というような変わり身であって、だから「書かれる物」ではない「書き方」が変わる。
VimであれEmacsであれ、「試してはみたが挫折した」的な話が尽きない理由はその「書き方の変更」にまつわる何かであるように思われる。

さて、Vimについてはこのブログでも何度か書いてきた。
http://d.hatena.ne.jp/note103/20130702/1372766843
http://d.hatena.ne.jp/note103/20130704/1372933394
http://d.hatena.ne.jp/note103/20130821/1377082535

なぜVimを使いたいのか、と聞かれたら、「楽しそうだから」と答えるだろう。
と言っても、それは「Emacsではない理由」ではなく、「普通のエディタでも充分用は足りるのに、なぜ?」と聞かれた場合の回答である。

とくにぼくの場合は、プログラマーでもなければ英語翻訳者でもないわけで、基本ひたすら日本語を打ち込んでいくことが仕事の大半であることを考えれば、このような「変わったエディタ」を選択することにメリットがあるとはあまり思えない。
モチベーションはだから、「なんだか楽しそうだから」ということにほぼ尽きる。

しかしそこで、もう少し深く考えてみると、その「楽しそう」の向こうにはたぶん「変化」がある。
従来の(一般的な)入力方式では得られない何かがそこにはあって、今いる場所からそちらへ環境を変化させたい、という気持ちがあるだろう。
「効率化」というキーワードはVimを語る際によく使われるし、実際それは間違っていないが、仕事が効率化してどんどん捗ることを求めるというよりは、その効率的な作業自体を楽しみたいという欲求がある気がする。

Vimはそもそもプログラミングに向いたエディタだから、プログラマーではないぼくが使うメリットはそんなにない、というようなことを上では書いたが、同時にプログラミングだってやりたいさ、という状況に今年の春先からとくになっているので、それもVimを使っている理由ではある。
ただし上記同様、これはEmacsを使わない理由ではなく、通常のエディタを選択しない理由であり、ついでに言えばぼくが使うVimGVimMacVim)である。

前置きが長いがまだ続けると、ぼくの仕事は編集者で(と言いながらいつもその言い方でいいのか疑問を感じるが)、いま主に作っているのは坂本龍一さんの企画・監修・その他諸々によるCDブック形式の音楽全集である。(以下最新刊)

commmons: schola vol.12 Ryuichi Sakamoto Selections: Music of the 20th century I (仮)

commmons: schola vol.12 Ryuichi Sakamoto Selections: Music of the 20th century I (仮)

全30巻予定で現在12巻までリリースが完了したこの商品を作るためにぼくがやっていることは、座談会をテキストにまとめる作業やその前の文字起こし、あるいは原稿の取りまとめから関係各位とのメールのやり取りまで我ながら多岐にわたるが、その中でコーディングをする場面はひとつもない。

だから、プログラミングというのはあくまで趣味というかちょっとした興味の対象というか、あるいは今後そうしたことにも関わっていくかもしれないというおぼろげな展望のもとに選択されたものであって、本業でそれを扱っている人との差は開くばかりだろうけど、自分なりには毎日少しずつ「かつては知らなかった、しかし今は知ったこと」を増やしている状況だ。

今年の4月末に大きな作業が一区切りし、翌日が5/1だったので「そうか、5月から学習をスタートした、と言えば自分でも覚えやすいな」と思ってその日をプログラミング記念日と定めた(俺の)。
最初はRubyの入門書から始めたが、今月のYAPC::Asiaに行くことにしたので途中からPerlの基礎入門に切り替えた。そんな中、Vimも7月頃から触っている。

それが本レビューを書いている人の大まかな背景です。

経緯と御礼

先々週の8/23(金)の夜に以下のブログを見たところ、
http://www.kaoriya.net/blog/2013/08/23/
以下の本が紹介されていて、

実践Vim 思考のスピードで編集しよう!

実践Vim 思考のスピードで編集しよう!

これの献本先&レビュワーを募集します、とのことだったので応募した。

翌24日には当選者が発表され、
http://www.kaoriya.net/blog/2013/08/24/
約20名の応募者の中から最後に自分がすべり込んでいるのを見たときには「何してしまったんだ、俺」と壮大なプレッシャーに包まれた。が、これもまた望んだ「変化」には違いない。
当選者発表の翌日午前には本が到着し、その日は作業が立て込んでいたから夜になってから読み始めた。

本を送ってくださった @kaoriyaさんことKoRoNさんこと村岡さんといえば、たぶんまだぼく自身よくわかっていないぐらいVim界では著名な方で、大変光栄なことでした。
中途半端な場所ですが、あらためて御礼を申し上げます。ありがとうございます。

強力に親切

『実践Vim』という書名、およびとくにキャッチーというわけでもない(悪い意味でもない)表紙の雰囲気からして、基本的には専門書、まあ、ある程度Vimの扱いに慣れたぐらいのレベルの人に向けた「応用編」みたいな内容かな、と想像していたが、実際には入門者、初心者にこそド・ストライクな内容だと思った。

Tips集という体裁をとっているし、序盤で著者本人も「頭から順に通読されることを想定しているわけではない(=バラバラに読んでOK)」と言っているが、読み始めから読後に至るまでこれは「通して読みやすい」という印象を持った。

書かれている一つひとつのトピックが、並列的&バラバラに存在しているというよりは、それ以前に説明されたことを踏まえて紹介されているから、「順番に読んでいけば振り落とされない」という安心感(安定感)がある。実際、いろいろと混み入ってくる後半〜終盤の一部を除いて、説明の不備(不親切さ)が理由でわからない、という場面はほとんどなかった。

入門書にありがちな不備というのは、書き手の方で「受け手がどこを理解しづらいか」を想定しきれていない(=読者が何をわからないのかがわからない)、という状況から発生している場合が多いように思う。
受け手が理解していない点がわからないから、本来であれば省略すべきでないところを省略してしまったり、必要なはずの説明が載っていなかったり、ということが生じやすい。その記述の前に一度も説明のなかった用語がいきなり出てきて、そこで学習が一旦ストップしてしまう、なんて状況はそうやって発生するのだと思う。
本書においては、そういう部分がゼロとまでは言わないが、そう言っても構わないぐらいにほとんどなかった。それが本書の大きな美点のひとつだと思う。

書中の至るところで出てくる「表」があって、キーストロークとそれによってバッファ等に生じた変化、およびそれぞれの時点でのカーソルの位置などが明示されているのだけど、これが非常にわかりやすくて、それを見ながらであれば簡単に自分のマシンでも同じことを実行(再現)できた。
マシンから離れて読んでいる時でもその操作によって何が起きるのかということを想像できたし、人が直感的に言葉や図を介さずにやっている行為をこのように誰もが再現しやすい形で記述できてしまうというのは、類書ではよくある記法なのかもしれないが、初めて見た立場からするとかなり驚いた。

上に書いた「親切さ」「安心感」ともつながるが、読んでいるときに「あれ? これは初めて出てきたコマンドだな」とか「これってどんな意味だ?」と、疑問が意識にのぼってくるたびにすぐ、それに関する説明が出てくる。まるで目の前で、こちらが首を傾げたのを確認しているかのように欲しいところで解説が入るのでそれも驚いた。

頭から順番に読んでいく利点というのは、途中から読んだ場合に不明な語句やコマンドが出てきたら「ここには説明がないけど、前の方で説明があったのかもしれないな」と思えてしまう、そういう状況が発生しえないところにある。
これは蔵書の山から目当ての本を探しているときに、「もしかするとすでにあの本は捨ててしまって、この中にないかもしれない」と思いながら探す、あの避けるべきストレスフルな状況に似ている。このとき、「まだ見つかっていないが、少なくともこの山の中にあることは確実だ」とわかって探すことと、頭から順番に読み進めていくことは同等である。

何度も言ってくる

一方、本書のもう一つの美点として、「何度も同じことを説明する」ということがある。
場合によってはその姿勢は、表現がしつこいとか、編集や構成(校正)がなっていないとかいう、悪点のようにも捉えられかねないが、本書においてはそうではなく、ことに初心者、および部分的につまみ読みしている人にはとても助かる要素だと思う。

本書では様々な「技」が紹介されるわけだけど、大きく数えても120にわたるTipsが収められており、その中でさらに、余談的なものも含めていくつものヴァリエーションが出てくるので常識的に考えて一度にすべてを覚えられるわけがない。

もちろん、頭で覚えることはそもそもの目的ではないかもしれないが、それでもある程度は覚えていないと、それが前提となっている新しい話を理解することはできないから、もしそこで繰り返しの(しつこい)説明がなければ、それが「それ以前のどこで紹介された技だったか」をいちいち自力で戻って調べなければならず、大変な時間と根気を費やすことになる。
本書ではそういう場面のたびに「これについてはTIPS*(*ページ)で説明した」なんて文言が出てくるので、記憶があやしいと思ったらその指示された先をすぐに読み返せばいい。

ついでに言うと、任意の何ページに戻るときの紙の本のスピードといったら、いわゆる電子書籍でやるそれの何倍も速い。数秒単位で対象の箇所に辿り着けるし、数ページを一度に読み比べることもたやすい。同じことをKindleiPhoneiPad)、あるいはPCでやろうとしたら相当煩雑なことになるだろう。
と言っても、本書も電子デバイスには対応しているようで(→達人出版会)、そこではURL要素が効果的に使われているそうだから、単純に紙の本の方がいい、というだけの話でもないのだけど、少なくともぼくにとって紙版の本書は非常に直感的なツールであり、それを実現しているのはそのような記述を徹底している著者および日本語版制作者の力によると感じた。

師匠になる

もうひとつ良いと思うのは、単純に著者の話が面白いということだ。
とくにギャグが頻発しているとか、皮肉や風刺が散りばめられているとか、あるいは高いテンションでブッ飛ばしているとかではないのだけど、基本的に全編を通して柔らかいというか、視野の広さとか、自由さみたいなものを感じる。
メインは上記のような「技」の数々であるはずだとは思うけど、むしろそれを解説する地の文というか、著者の「声」が聞きやすいので抵抗なく読み進められるところがある。

それに加えて、というかその要素のひとつとしてというか、こちらがわからない言葉を使わないし、わからないことがあっても上記のようにその直後に解説が入るので、途中で挫折をする理由がない。

話が専門化・高度化して理解できなくなる、という部分はいくつかあったが、それは理解するための素地や根気が追いつかなかったからで、わかるための手間や時間を惜しまなければ(つまりそこが中級者以上に適した部分にもなるのかもしれないが)役立てることはできるだろう。

こういった入門書系の本というのは、内容に間違いがあってはいけないし、対象を広く想定せざるを得ない部分もあってか、「丁寧でいい感じだけど、やや味気ない」ものも少なくはなくて、言い方を変えると、著者の「顔」が見えづらいと感じられることがままある。
あくまで教科書として考えればそれでよいとも言えるだろうが、人生の貴重な時間を費やして付き合う以上、面白いに越したことはないというか、著者の個性に引かれながら読み進めていけるならばその方がいいと思うし、その点でも魅力的な内容だと思う。

また、著者の人間性と内容が結びついているならば尚のこと、断片的にではなく、頭から読んでいく面白さも生まれうるだろうし、著者もまた人間であればこそ、間違いも必ずどこかでおかしているはずで、しかしそういったものも含めた総体として付き合っていける内容ではないかと思う。

少し前にLINEの @941さんが「プログラミング初心者に本当に必要なのは情報ではなく師匠という存在だと思う」というブログ記事を書いていたけど、
http://tech.kushii.net/archives/31292522.html

それともちょっと繋がって考えられることであるような気はする。本の内容を、情報の集積としてというより一人の著者におけるひとつの側面として捉え、その人を(本を通して)勝手に師匠にする、ということもできるかもしれない。

読む前と読んでる途中と読んだ後

読む前、というかもっと前のVimを触り始めた頃に、「ああ、これ駄目かもなー。これは俺は使わないかも」と思った一番の理由は、いちいちEscキーを押さないとカーソル移動ができないという設計思想の不可解さにあった。
今ぼくは挿入モードでもEmacs的に動くようvimrcを設定しているけど、それはそもそものVim(Vi)の思想からすれば邪道だろう。そして邪道であるということは、必ずしも心楽しいことではない。

挿入モードでどのように動くべきか、それはなぜなのか、という疑問に対して、本書では明確な回答はなかったように思う。それは少し残念なことだ。これはVimの根源に関わる疑問であり、どのような回答であれそれを聞きたかったという気はする(もちろん著者はVim自体の作者ではないから、本当に適した回答者であるのかはわからないにせよ)。
ただ、「画家はつねに筆を動かしているわけではない」という、ノーマルモードの意義を説明するための喩えは腑に落ちた。これはぼくなりに言い換えれば、「ノーマルモードとはウィンドウショッピングであり、実際に商品を購入・会計するのが挿入モード」ということになる(Vimmerにすらわかりづらいかもしれないが)。

本書でいいなと思ったのは、元々Vimに含まれていない機能、つまりプラグインの説明がかなり少なかったことだ。すでにある機能を使いきることが前提的に指向されていて、それによって内容の一貫性も保たれやすくなっただろうし、初心者が読み進めるにあたっても集中して(あちこちに気持ちがブレることなく)Vimの本質に向かっていきやすい構造になっていると思う。

本節の見出しに「読んだ後」とは書いたが、あくまで一回通して読んだというだけのことで、本当に本書を「使う」ことになるのはこれからだろう。
初めて来たディズニーランドをようやく一周して、全貌はまったくわかっていないが、何となく「どこにどんな雰囲気のアトラクションがあるかはわかった」という感じだ。
これからは状況に応じて、どのエリアに行きたいかを思い描きながら何度も再読するだろう。

体裁・翻訳について

ぼくは本を買ったらすぐにカバー(書店のじゃなくて本自体の)を外して読むが、それ以外の傾向として鉛筆でどんどん印をつけていくということがある。大体はチェックマークとか、丸印をつけていくだけだから、誰かが見てもそれが何を意味するかはわからないだろうし、ぼく自身も後から何かをわかるためにつけているのではなく、ただ山登りをするときの杖のように粛々と鉛筆をもって印をつけていく。

それとあわせて、技術書を読む際によくやるのが勝手校正である。著者の言い回しなどで、これはナイだろう〜と思うような部分が、先入観もあるかもしれないが技術書には比較的多いような気がしてならない。単なる誤植の場合もあるし、言い回しがブログっぽいというか稚拙というか、主語の有無や係り結びが曖昧だったりして、「べつに、とりあえず伝わればいいじゃん」みたいな傲慢さを感じることも少なくない。
そういう感じ方のほうが傲慢なんじゃないか、とも思わなくもないが、文章というのは思いを詰める変数みたいなもので、自分だけで使うならばどんな名付けでもよいかもしれないが、不特定多数の、ましてや自分が死んでも残るかもしれない道具として世界に送り出すならば、やはり論理的に精査してし過ぎることはないと思う。

論理を重んじるはずのプログラマーによる本がどうしてそうなりやすいのか、ということはかねがね疑問であり、それが解消されたわけでもないが、本書における鉛筆での校正箇所はとても少なかった。
日本語も良かったし、まあ時々「ここは『〜なんだ。』より『〜である。』の方がいいよなあ」と思うような部分もなくはなかったが(そういう部分においては訳者が著者のキャラを作りきれてない感じがした)、充分に楽しめるレベルになっていたし、少なくとも作りの粗さに集中が乱されるということはなかった。

終わりに

Vimを覚えようと思ったのは、普通のエディタを使っていてもこれ以上は上げられないであろう生産性の一部を、これによって多少なり上げられるのではないかと思ったから、と説明することもできる。
さして変化の生じない作業を延々と、残りの人生においてこのまま続けるよりは、違ったアプローチを通して良い方向に変化したい、というような。

Vimには、「無駄な繰り返しをやめる」という思想が通底している。しかしそれを身につけるには、「無駄な繰り返しをやめる」という思想を幾度となく頭と体に叩きこまなければいけない。矢印キーを連打したり、数十行におよぶリストに同じ作業を延々と施したり(箇条書きの行頭にナカグロを加え続けるとか)している自分をつねに俯瞰し、「おい、それ一括で処理できるぞ」と気付いては、「より適切な方法を今すぐ考えろ」と自らに発破をかけ続け、そのための方法を記憶と感覚とで組み合わせ続け、実行し続けなければいけない。
「繰り返しを避けることを繰り返す」というのはなんだか矛盾した命題のようではあるが、実際には一本の道を進み続けていることでもあると思う。

ちなみに、ここまでに一度もEmacsとの比較を行っていないけど(話題には出したが)、それは本書にそうした比較がまったく出てこないから、ということもあるかもしれない。本書はEmacsをまったく否定していないし、話題に出てこないのだから肯定もしていない。
本書で語られるのは一貫して、どのように作業を効率化すべきか、どう考えてどう対処すべきか、ということだから、もしも多少なり同じようなことを考えてEmacsを使っている人がいるなら、これを読んで自分の作業に生かしたり、あるいは主張の向く先に賛同したりできることもあるかもしれない。

ぼくはまだまだ入門段階だが、プログラミングの練習問題なんかで何度もつまづいたり諦めたり苛立ちを感じたりしながら、その中で得た知見とか感覚とかいうものがそれ以外の場所でなぜか(いつの間にか)土台や支えのようになっていると感じたことが何度もある。
この辺の感覚についてはいずれまた機会があれば書きたいが、ともあれすでにEmacsを使っている人ならVimを始めるときにゼロからのスタートということはないだろうし、逆もまた然りだと思う。

ドットコマンドやテキストオブジェクト、Exコマンドや検索・置換のやり方など、具体的なTipsについても思ったことはいろいろあったが、充分以上に長くなったのでひとまずここまでにしたい。


(2013/9/2時点の同書。対して冒頭の画像は8/25の到着直後の同書)