2008年02月09日 00:05 [Edit]
私の言語遅延学習法 - 三つのルール+1
つっこみが遅くなりました。
新しくプログラミング言語を覚えたいときに行うべき10の練習問題 | IDEA*IDEA404の人とかが突っ込んでくれそうな気がするので気軽にいってみます。
いい機会なので、私の言語学習法をこの際披露することにしましょう。
私の場合、一番の特徴は、「必要を感じるまで学ばない」「本当の問題に出会った時に、それを全力で解く」「学ぶ時には『原典』に当たる」ということでしょうか。私はこれを「遅延学習」と呼んでおります。実はこのことはコンピューター言語に限った事ではないのですが、コンピューター言語の場合、このことが特に顕著です。これらの特徴について一つずつ解説してみましょう。
必要を感じるまで学ばない
私の場合、長らく「プログラマー」としてより「ネットワークエンジニア」としての仕事が長かったため、ある言語を学ぶきっかけは、「システム直して」というものが多かったのです。そこでは実にさまざまな言語で環境が構築してあって、それを解析するのにその言語の知識が必要となりました。
そうなってから学ぶと、なにしろ「いつまでに直せ」という締め切りがありますから、いやでも学びます。スカウターの数値が跳ね上がるのです。
本当の問題に出会った時に、それを全力で解く
言語を学ぶ際の状況が上のような理由なので、問題は今そこに実際にあるわけです。そしてこれが重要なのですが、その問題はかつて「解かれて」いるのです。それを「解き直す」のが私の仕事なのですが、このかつて「解かれている」というのが非常に重要なのです。
なぜかというと、ある言語にとってその問題が解けるか否かというのは、決してトリビアルな設問ではないのです。例えば「ローカルファイルを読んで書く」という、多くの言語にとって単純な仕事でも、JavaScript (のブラウザーにおける実装)ではそのことそのものがわざと「できない」ようになっていたりします。それよりもさらにトリビアルそうな文字列操作さえ、APLでは「問題のスコープを超えていた」りします。
そういう事由があるので、全ての言語向けの「練習問題」を作るというのはなかなか難しいのです。
しかし実地の問題であれば、前任者はどんな理由であれ、その言語でその問題を解こうとしたことはわかります。その言語で解けるという公算があったから、その言語を使用したのです。これは実に大きなヒントなのです。
学ぶ時には「原典」に当たる
たとえば、PerlであればCGI本とかではなく、ラクダ本に当たる、というのがこれの意味するところです。もちろんCならK&R。なぜ原典でなければならないか。
それは、原典には、その言語の設計者の意図が書かれているからです。それで、その言語は何が得意で何が不得意なのかもわかる。結果的に易しく「こうやれば出来る」が書いた本よりも、「こういう人向けに作りました」がわかる原典の方が優しいのです。
ただし、以上がきちんと機能するためには、一つ重要な前提条件があります。
基礎をしっかり抑えておく
あるコンピューター言語を学ぶ、というのは、ある意味この応用編に過ぎないという見方も出来ます。私が scheme → C/Assembly Language という、Computer Science の古典的カリキュラムを支持する理由がそれなのです。世界は Church と Turing の間にある。この両極端を最初にしっかり学んでおけば、たいていのコンピューター言語はこの間のどこかに収まっているのですから怖くないのです。
その意味で、最近のちょっとした悩みは、Assemblerを教える方法。かつてはAssemblerを学ぶというのは、CPUを学ぶと同義でしたが、最近は Intel IA-32 にしろ PowerPC にしろ、CPUとAssemblyの距離感がずいぶんと増しています。MIPSは素直だったな(遠い目)。
それではVMを作るのがいいかというと、VMもまたCPUから「遠い」。最近のCPUはほとんどRegister Machineなのに、VMはほとんどStack Machine。しかし、CPUを学ばないとTuringの世界をきっちり学んだことにはならない。かといってCASLってどうよとも思いますし。
Perl/Python/Ruby/PHPのような「現場言語」から入ると、どうしても「その言語が得意とする領域」ばかりを猟色し、その結果「栄養が偏る」ことになりがちです。急がば回れともいいます。本気でコンピューターと付き合うのであれば、基礎も固めておきましょう。
Dan the Polyglot
この記事へのトラックバックURL
「CもJavaも書いたことがあります。だからC++もちょっとは書けます」
とか言うエンジニアはエンジニアとして信用しないです。
現場では「ほぅ!それはたのもしい」とか言ってしまうんだけどorz
その点で「どう書く?org」はなかなかいいなと思います。
とりあえず 1ヶ月間わざと不便な言語で解いてみて
> ある言語にとってその問題が解けるか否かというのは、決してト
> リビアルな設問(些細な問題)ではない
ということが実感できました。
眼前の問題に対して、自分の持てる言語の中から最適なものを選ぶ
ということもまた大切なのですね。
期間はほんの少しでしたが、楽しかったものです。
今でもやってるはずです。
実践度？から言えば、既存アプリの逆asmでのハックなんかで得た知識が、普段開発する際にも役立ってます。
こういう改造はプログラマーでなくても面白いですしね。
ただ、asmを必要になることって、どうしようもないバグをデバッガでCPUの挙動を追うとか、コンパイラのバグ見つけるとか、うーん。最近はあまりないような。
別として、基礎だからやっとけって話ですよね……。
文系で若くて体力あって素直で文句言わない人が良い。
仕事なんてできたってできなくたって、時間請負だから関係ない。
FreeなDOSでリアルモードでbootしてnasmなんかを使えば実機で 8086 Assembly Language Programming が楽しめちゃいますよ！
必要を感じるまで学ばない＝その言語に関する経験はゼロという人を、
クリティカルな現場に入れるというのは問題だと思うのです。
