我流言語習得術、あえて名付けるのなら、読書駆動習得術
ちょっと前にコーディングの進め方について書きましたが、今回はわたしなりのプログラミング言語の習得方法についてです。
ちなみにこのやり方、はじめて言語を学ぶ方にはまったくおすすめできません。3つめ以降くらいでないと、まったく参考にならないんじゃないかと思われます。あと、かなり迂遠なやり方なので、とりあえずコード書きたいという方には不向きです。
と、注意書きをしたうえで本題に入りましょう。
まず、本を買ってきます。できるだけ厚い本を選びます。その言語をデザインした方が書いた本だとなおよいです。「分厚くて言語仕様を網羅した本を1冊だけ」というのが原則です。
その本を1ページ目から行儀よく読みます。ページを飛ばしたり、おもしろそうなところから読むということはせず、「分からない」と考え込んでしまったり、前に戻ったりもしないで、「ふ～ん。こういうのがあるんだね」くらいの軽さでさら～っと読み進めます。
この場合、重要なのは、「○○（例：C++）の書き方の方がエレガントじゃないかな」とか考えないことです。今までの嫁（＝習得言語）はすべて里帰りさせるぐらいの気持ち（←本当に里帰りさせないように！）で、「今、アタックしている子が世界で一番の美人！」くらいの気持ちで読みます。「この本の著者は世界で一番の賢者！」くらいの気持ちもあると、なおよいです。疑惑は吸収速度を鈍らせます。疑うのは後でやればいいので、この時点では無条件で信じてみましょう。
本を最後まで読むと、言語仕様を理解できるできないにかかわらず、その言語の思想というか目指しているものがなんとなく見えてきます。言語デザイナー自身が書いた本は特にそこらへんがはっきり出ます。
全体像がおぼろげにつかめたところで、今度は「この文法はおもしろいな」とか「こういう仕様ははじめて見た」といった部分について記述しているところを読み直します。言語仕様の中でも特徴的と思える部分をピックアップして読み返していると、最初に一巡した時のイメージが補強されて、「この思想を記述するために、こういうやり方をとったのかなあ」ということがわかってきたりします。
そうやって、ひととおり納得できたような気がしてきたら、また1ページ目から順序よく読んでいきます。今度は丁寧に、わからないところは何度も繰り返して、全体をもう一度、読み直します。
ある程度、自分の中でのイメージが固まってきたところで、ようやくググってネットの情報をあさります。ここにいたるまで、わたしはいっさいWebを利用しません。あくまでも買ってきた1冊の本の中をグルグルします。
一般的に、言語を習得するには、たくさんの人のコードを読むといい、とされていて、わたしもそれには同意しますが、初期段階では最初に選んだ1冊に載ってい るコードだけを読むようにしています。わたしが不器用なだけなんでしょうが、慣れてない言語でいろいろな種類のコードを並行して読むと、頭の中がいろいろと混乱す るので。
Webの情報を読んでいると、「あっ、あれはこういう形で応用できるのね」とか「あれ？ こんなことできるの？」とかいろいろでてきますが、ちょっとでも疑問が湧いてきたらそのたびに最初の1冊に戻って、関係する部分を読み直し、「これはわたしの解釈が間違ってた」と思うのなら自分の考えを軌道修正し、サイトの情報が納得できないようなら、別のサイトを探してみます。
そうやって、本で得た情報を補強もしくは補正し、「この言語でコードを書きたい！」というわくわくが盛り上がってきたら、ようやく開発環境を整えて、コードを書き始めます。
ここからは以前、書いたコーディング術にしたがって、コードを書いて動かして修正してをガンガン繰り返し、失敗例を積み上げていきますが、迷って動けなくなった時は本に戻ります。本に戻っても進展がなかったらネットを頼ります。本が絶対的に正しいとは思っていませんが（絶対的に正しいものなんてないと思う）、スタート地点を1つに決めておくと、迷子になりにくくなるような気がします。
というわけで、本を読むことをベースにするので「読書駆動」と名付けてみました。
現在のところ、わたしが仕事で使ってきた言語は1ダース以上です。よっぽど特殊な言語でないかぎり、そこそこ動くものをつくる程度でよいのなら、3日もあればマスターできます。
そういう、さっさと文法を頭にたたきこんで、コードを打ちまくっていれば覚える、というのもありですけど、その言語のデザイナーが何を理想としているのか、何を美しいと感じているのか、何を不要だと思っているのか……そんなことを考えながら、じわじわとアプローチしていくやり方も楽しいものです。
まあ、仕事のために急いで言語を覚えなきゃいけないことが多いので、こういうのんびりしたこと、あんまりできないんですけどね、実は（←いろいろとだいなしだ）。
ちなみにこの習得術、最大の弱点は、最初の1冊を選び間違うと悲惨なことになる、ということです（苦笑）。
コメント
インドリ
自分とは違う方法なので大変興味深かったです。
ひでみ
こんばんわです。ひでみです。
暁 紫電さん。
おっ、同志、発見！（笑）
私は Smalltalk を疑惑だらけで挫折しました。
がるさん。
「守破離」という言葉があるのは知ってたんですけど、意味がわからなかったので、ググりました。
最初のうちは師匠の教えをただ守れ、というあたりは確かに近い感じがしますね。
インドリさん。
プログラマたちと、どういうやり方で言語を覚えているのか、という話をしたことがないので、自分がマジョリティなのかマイノリティなのかがわかりませんっ。
インドリ
ひでみさんの方法は、どちらかというとマジョリティだと思います。
私の方は恐らくマイノリティだと思います。
ちなみに私の方法は、並行多読リレーショナル分散型です。
バイブルと言語仕様書を中心に、気になる分野の情報を集めて脳内でネットワークを構築します。
例えば、並列処理について知りたかったら、プログラミング言語を問わず並列処理についての情報を片っぱしから集めて大枠から纏めていきます。
気になったら止まらない性質なので、知識欲を満たすためにこんな方式となっています。
なにはともあれ、この手の方法は個人的最適解だと思います。
プログラマは全員「世界に一つだけの花」です。
仲澤＠失業者
自分がLattice-Cをはじめたときの話。
ホッチキスどめのぺらぺらと、製本された2冊のドキュメントがついて
きたと思います。メディアは5インチFD。ぺらぺらには起動ディスク
の作り方が説明されていたと記憶してます(たぶん)。HDDは無いのが
普通だったからですね。当たり前ですが解説本などはありません。
リンカーも付いてなかったのでMS-DOSかMASMのFDからコピって
使ってましたね。当然デバッガも無し。makeもLibも無かったような・・・。
んで、この2冊はコンパイラ等のオプションの説明と、ライブラリ関数
の解説書だったと思います。まぁ簡単に言うと仕様書ですね。
ちなみに解説本が出たのは購入からだいぶたってからだったような
気のせいがしますが、どれも中途半端な内容で、結局当該の仕様書が
一番頼りになったと記憶してます。
この経験から、今でも「問答無用仕様書読め」って言ってます(笑)。
ひでみ
こんばんわです。ひでみです。
仲澤＠失業者さん。
そういえば、新人の頃はいつも「ドキュメント読め」ですべて片づけられていました（苦笑）。
メーカーが出してるドキュメントは、日本語が変だったり、英語版しかなかったりで、苦労させられたことを思い出します。
当時はそれしかなかったので、黙々と読んでましたけど、今みたいな状況だったらよっぽど困らない限りは読まないでしょうね。
だって、むずかしいもの（←軟弱者！）。
仲澤＠失業者
まぁ自分もAndroidの入門本を買ったクチなので、海に向かって
「だってぇ面倒じゃぁ～ん」と叫びたいきぶんです。
しかし、簡単に解決方法を手にする事を繰り返していると、困難なない課題に
直面したとき、その困難さに負けてしまうかもしれないよね、
と反省するわけです。
「問答無用仕様書読め」の言外の意味は、困難さに慣れておきなさい。
ってぇことなんですね。
その意味では「くぐるなっ」ってことと同じかもしれません(笑)。
まぁ、基本的には、解説本の読み手はなかなか書き手側にはなれないものだ
と、じじぃは講釈をたれたいわけですね(vv;)。
tasuku
読書駆動ですか...。
正に、選択失敗すると迷宮入りになりますね。
私の場合は、（とっても昔ですが）
Smalltalkで迷宮入りに追い込まれ、その後C++で成功。
という経験があります。
C++は、最初の頃はCのプリプロセッサだったんで、
Object指向という概念的な振舞を、Cで どのように実現しているかが
分かり、やっと腑に落ちた。
という次第で、中々に懐かしい話です。
ひでみ
こんばんわです。ひでみです。
tasukuさん。
私も Smalltalk は迷宮入りになったくちです（苦笑）。
C++ は Stroustrup の本を10周くらいして、無理やり文法、たたきこんで、その後、コードを大量に読み込んで、なんとかマスターした感じです。
Java は何冊も本を読んだんですが、いまだに腑に落ちません。何冊も読んだのがいけなかったのかもなあ、と今になって反省していたりします。
インドリ
ひでみさんこんにちは。
＞Java は何冊も本を読んだんですが、いまだに腑に落ちません。
JavaはアンチC++と考えると分かりやすいと思います。
（実際に昔はJava陣営によるC++バッシングが酷かった）
強力だけども危ないC++よりも、強力ではないけども安全な言語を目指しています。
また、Java仮想マシンが非力な媒体でも動くように設計されている点にも注目する必要があります。
総合するとJavaは、「誰でも何処でも動く事を目指した言語」だと言えると思います。
これらの事は、Java言語仕様、Java仮想マシン仕様、Javaの歴史を調べて考えました。
プログラミング言語は、仕様に加えて歴史の勉強もすると理解が深まると私は考えています。
あと、実際にコンパイラを作ってみると言語設計者の気持ちが見えてきます。
Jitta
> 今までの嫁（＝習得言語）はすべて里帰りさせるぐらいの気持ち（←本当に里帰りさせないように！）で、「今、アタックしている子が世界で一番の美人！」くらいの気持ちで読みます。
女性からこの様な言葉を聞くとは！（笑）
趣味で言語の幅を広げるならともかく、仕事で使わなければならない！というときには、そこまで時間が取れない、取らせてもらえないことが多いですね。というか、掲示板やフォーラムでされている質問は、そういう人たちからのものが多いです。私の周りでも、「おまえ C# 知ってるからこのプロジェクト入れ」と言われたり、本来のプロジェクトが忙しくなって抜けることになると「おまえやれ」と、他の人がアサインされたり（デスマの様相(--;）。お客様は「みんなわかっている」という前提で話をしてくるし、「いったことはやってくれる」と思っているし（営業はそう思わせるし）、あ～、本筋とは関係ないところが邪魔になってる・・・
ひでみ
こんばんわです。ひでみです。
Jittaさん。
> 女性からこの様な言葉を聞くとは！（笑）
はっ、しまった。女子力が底辺どころか海溝に沈んでることがバレてしまった（爆）。
仕事の現場で未知の言語を使わなければならないことは結構あって、そのたんびに付け焼刃でなんとなくなコードを書いちゃうわけなんですけど、あとで本を読んでみていろいろなことが理解できると、自分がとんでもなくヘボいコード書いてたことに気づいて愕然とします。
そうやってヘコむことがわかってるのに、自分がどれくらいダメだったのかを確認するため、わざわざ本を買って読んでしまうあたりが、我ながら自虐的です（苦笑）。