新しい言語を学ぶって、そんなにたいそうなこと?

小飼さんのblogより。

私の言語遅延学習法 – 三つのルール+1

これ自体は小飼さんの流儀の話なので、特につっこみどこはない。「私とはちょっと違うな」と思うけど、人格が違うんだから違って当然。ただ、コメントがちょっと面白かったんでつっこんでみる。

私は「自分が今まで書いたことのない言語」に対する抵抗はあまりない。perlやPHP、Erlangみたいに「見た目があまり好きでない」とかってものも、それを書かなきゃいけないという局面に立たされたら、渋々でも覚えてしまう。で、わりとすぐに「いっぱしの口」を叩ける程度には書けるようになってしまう。つまり覚えることはあまり苦ではないし、すぐ習熟してしまう。もちろんバリバリのハッカー達程でないけれど、その言語の王道的な使い方の範囲では、ちゃんと使えるようになる。

学校出たての頃はこんな「芸」はなかなか出来なくて、FORTRAN(66)やBASICは使えても、Pascalで既に落ちこぼれだった。ところが、COBOLを覚えLispを覚えるようになったあたりで、わりとどんな言語も苦ではないようになった。

以前非常勤講師をやっている時に、学生と一緒にどれくらいの言語を使った経験があるかというので数えてみたら、40くらいあったように思う。まぁほとんどは定義言語であってプログラム言語じゃないから、「40」ってのはかなりインフレな数字なんだけど、「文法を知っている」という意味では嘘ではない。

まぁそんな経験があるから、「自分が今まで書いたことのない言語」に対する「恐怖感」はない。知らない言語を使わなければならないことになっても、「覚えりゃいいさ」というくらいのことしか思わない。だから逆に「○○言語で書けます」なんてのはスキルのうちに数えない。プログラマの募集に応募して来る人が「○○言語で書けます」とか胸を張って答えてくれると、ちょっと苦笑いしてしまう。

なぜそう思うのか、なぜそう出来るのかと言えば、

知らない言語は勉強すりゃいい

と思っているからでしかない。まぁどんな言語も独習で長くて1週間。教えてくれる人がいるとか、いつも使える処理系があるとか、コードサンプルにいっぱい触れられるとかの条件が整って来ると、どんどん短くなる。これは「私の特殊能力」ではなくて、多分誰でも出来ることだ。やったことない人は不安に思うかも知れないが、やればどうってことはない。なぜなら、実用的言語なんてのは、

そんなに難しいものじゃない

からだ。だって、簡単に使えなかったら実用にならないじゃん。研究室で実験的に作られた言語とかだと、途方もなく難しいということはあるいはあるかも知れないが、ISOやECMAになっているとか、普通に本屋で入門書が売っているような言語は、実はそんなに難しいものじゃない。

確かに今まで使ったことのないタイプの言語、たとえば手続き型の言語しか使ったことのない人にいきなり関数型言語を使えと言えば、抵抗もあるだろうし時間もかかるかも知れない。でも、何でもいいからちゃんと使える言語が1つあれば、あとは差分だけだ。遠くかけ離れたパラダイムの言語でも、何も知らないよりはずっといい。「2つ目の言語」は何であれ心配する程は難しいものじゃない。だから1つちゃんと使える「あなた」にとって、まるっきり知らない新しく学ぶ言語は、既に何割か攻略済みなのだ。「2つ目」じゃなくて既にもっとたくさんの言語を知っていたら、「差分」はもっと小さくなる。つまり攻略済みの部分は増えるからそれだけ習熟は早くなる。

もちろん言語には得手不得手がありそれぞれの思想がある。そういったものを身につけないと「使える」とは言えない。そのために私がどうしたかと言えば、まず

大量の入門書を買って来る

ようにした。1冊ではダメで、異なる著者の本を何冊も買って来る。この時に本として良い評価を得ているかどうかってのは、あまり気にしない。何冊も買って来れば、相互補完してくれる。ある本では軽く扱われていることは、別の本では詳しく説明してあるかも知れない。ある本でわからなったことは、別の本ではわかりやすく書いてあるかも知れない。そういった効果を期待して、何冊も買うのだ。

これは小飼さんの主張とまるっきり違うことだと思うのだが、私は

「原典」なんてのはどうでもいい

と思っている。作者がどう思っていようと、言語の性格なんてのは「どんな場面」で「どう使われた」かというので決定されてしまう。そして、一度作者の手を離れた言語は、そういった「使われ方」に合わせて改良されて行く。他のたいていのプログラムと同じように、言語も「自分の意思」を持ってしまう。だから、「原典」なんてのはごく初期には意味を持つが、普及してからは「お守り」の意味しかないと思っている。良い言語作者が良い文書作者であるとは限らないのだ。「CにはK&R」とかよく言われるけど、私はあれはさっぱりだった。同じカーニハンの本でも「ソフトウェア作法 (Software Tools)」の方はためになったんだけど。

言語を学ぶことで一番大事なのは、その言語の「フィーリング」を身につけることだと思う。「らしく書ける」とか「らしい考え方」とかという「らしさ」を身につける。このためには、入門書を読破したら(別に覚えてなくていい)、次は

実際のコードを見ること

だ。これも、出来れば違う人が書いたいろんなコードに触れるといい。コードをいっぱい見れば、個々のプログラマのクセの部分とその言語の本質の部分とが、区別がつくようになる。良いコードに触れるのも大事だが、悪いコードにも触れておくといいだろう。インデントのつけ方もいろいろだし、名前のつけ方もいろいろだから、そういったものもいっぱい触れておくといい。

いわゆる文法解説の本だと、その文法がどんな場面でどう使われるかという解説に乏しい。世間で使われているかどうかと、文法解説のページ数とも一致しない。だから、「実際のところどうなの?」ということを知るためには、実際のコードを見るのが一番だ。

で、いっぱい読んだら、実際にコードを書いてみる。スクラッチでコードを書くのは簡単じゃないから、まずは既存コードに手を入れてみるのがいいと思う。それでまずは「使える感」を持つわけだ。

Hello World? そんなもん書けても何かの役に立つわけじゃないから気にしなくていい。私の場合、Hello Worldを書いた言語の数は、使える言語の数よりずっと少ない。まぁ書こうと思わなかっただけって話もあるけど。C++のHello Worldはconioとか使うのをよく見掛けるけれど、あんなのは「どうだ、こんなにCとは違うんだ」ということを誇示して初学者をビビらせているだけだ。Cとほとんど同じ書き方でもHello Worldは書けるし、他にもいろんなバリエーションが作れたりする。でも、そんなこといっぱい知ってても、あんまり役には立たんと思う。

というようなことをしていれば、たいていの言語は攻略出来る。プログラム言語なんてのはしょせん人間の作ったものだから、「底」なんてたかが知れてる。そもそも「底」に届かない範囲くらいでプログラムを書いている方が、読む人に優しいし実装の微妙な違いの影響を受けずに済む。「奥の深さ」なんてのは有害だと心得ておくべきだ。長くその言語を使っていて「コボラライゼーション」しちゃうのはいかがなものかと思うけど、実はそのプログラム言語の本質の部分はその辺にあったりする。だから、初めてのうちは積極的にその辺を身につける方がいい。

というようなことをして、新しい言語が使えるようになったら、「新しい言語恐れるに足らず」と思えるようになって行くと思う。と同時に「○○言語のスキル」というものが実はどうってことないことだということもわかると思う。世の中の変化に追従して行くためには、「何かが出来る」というスキルよりも、「何かを出来るようになる」というスキルの方がずっと価値がある。だから、件のblogのコメントにあるような

その言語に関する経験はゼロという人を、
クリティカルな現場に入れるというのは問題だと思う

なんてのは、一般論としては理解出来るのだが、それは人によるだろう。いやむしろ、経験のある言語でしか安心して働かせられないような奴は、コの業界にはいらんと思う。知らない言語なんてのは、勉強すりゃいいだけだ。

PS.

そう言えば言語を学習するために、「その言語を実装してみる」とか「言語処理系のコードを読む」とかって手もある。Lispなんてそうやって理解した部分があるし、Pascalの変な仕様も実装してみて納得したもの。

PS.2

2ちゃんを読んで気がついたのだが、これネタにマジレスだった悪寒…
ヽ(`Д´)ノ

新しい言語を学ぶって、そんなにたいそうなこと?” への7件のコメント

  1. 最近は「原典」がWeb上にあったりして紙でない言語環境も多いですしね.原典と矛盾する動きをする実装もあるしね.

    Cだと”C: A Reference Manual”というのは,案外昔世話になりました.

    Perlは真似てばかりです.Programming Perlもありますが,Perl Cookbookも面白かったりするし.

  2. うん、大半は共感できるけど

    >そもそも「底」に届かない範囲くらいでプログラム
    >を書いている方が、読む人に優しいし実装の微妙な
    >違いの影響を受けずに済む

    ここだけひっかかるのは、なんでだろう?w

  3. > 紙でない言語環境

    そもそも、今時だと紙で出るより先にwebなのが普通なわけで。ところが、そういったのってまとまってないから「書籍」という感じでもないし、たいていは説明は足りないし、そもそも「入門」じゃないし。

    > なんでだろう

    一部のプログラマにある「使い尽したい」という欲求に反するからじゃないかしらん。

    C99にしてもgccにしても、便利そうな目新しい機能があるし使いたいんだけど、それを使ってしまうと古い処理系で動かないという罠。そうやって互換性を意識してばかりいると、だんだんコボラライゼーションされてしまうという罠。さーどっちを取る? ww

  4. ほぼ同意。
    この前、急遽C#で書かれたプログラムのヘルプに入ったんですが、
    一週間後には要求された部分がおおむね機能する所までいきましたしね。
    一日で本一冊読み込んで、あとは繋ぎこむ先のソース少々とWEB上の
    資料があれば十分。
    まあ、C#のアーキテクトはAndersなんで、元turbo使いには思想的に
    馴染みやすかったというのもありますが。

  5. 私はどちらかというと原典派です。というのは、「How」だけでなく「Why」が書かれているものを読みたいからです。原典がいつもそうとは限らないですが、その言語なりシステムなりに何らかの形で関わった人が書いているものの方が、なぜそのような設計にしたかに触れられていることが多いと経験的には思います。

    Whyを知らずに末端の仕様だけを見ようとすると覚えることが多すぎてついて行けません。膨大な末端の仕様から設計者の意図を推測することはできますが、最初から意図が書かれている書籍があればそれに越したことはないだろうと思います。

  6. 確かに「Why」は知りたいです。私はよく「〜の気持ちになる」と呼ぶんですが。

    でも、「作者のWhy」と「言語のWhy」って必ずしも一致してないと思うんですよ。出来た当初は一致してるはずだけど、しばらくするとそうでもなくなっちゃう。逆に作者の気持ちを知りたかったら、わざとVer 1.0あたりのものを使ってみたり。

    > 覚えることが多すぎ

    一番大事なのは「フィーリング」だと思うので、「覚える」ってのを意識したことはあまりないなぁ。片言でも読み書きしているうちに、そういったフィーリングはだんだん身について来るものだと思ってるんですが。逆にフィーリングが身につくはずの頃にまだ一生懸命何かを覚えるような言語は、ダメな言語じゃないかしらん。

    ということで「原典の価値」ってのは、私にとってはかなり相対的で、作者の「手の跡」が生々しく残っている処理系だと意味あるけど、既にそれなりに評価を受けて使われている言語は原典はどうでもいいなーと思っています。

    そもそも「名著」と呼べる「原典」はあまりなく…

  7. アプリケーションを書く作法、そしてその言語としての(文法だけでは表現できない)作法、なんていうところに、プログラミングの本質の中の一要素があるように思います。

コメントは受け付けていません。