無知:たのもう!たのもう!

    親父:うるさい奴が来たぞ。おい、そこのバカ、口を縫いとじてやるからこっちへ来い。

    無知:そうです、バカなんです。

    親父:なんだ、泣き始めたぞ。見かけない顔だな。

    無知:彼女のできなかった非モテ先輩からお話を聞いて、教えを請いに参りました。




    親父:なんだか随分古い話だな。じゃあ友達の作り方でも訊きに来たのか? あんなものは炭水化物と同じだ、切れると結構つらいが、無いなら無いで何とかなる。

    無知:いやローカーボンダイエットの話ではなく、どうやったら教養が身につくかを教えてください。

    親父:なるほど。察するにお前さんは物知らずだな?

    無知:そこまではっきり言う!……でも、おっしゃるとおりです。

    親父:ものを知らない奴は「知識がある」ってことがどういうことかも知らないから、自分と真逆のイメージをこしらえるしかない。何も知らない自分←正反対→何でも知っている=教養がある、って感じだな。言わば《無知の陰画としての博識》だ。松岡正剛なんかをありがたがるタイプだ。

    無知:げげっ、どうしてそれを?

    親父:しかし、そういう目標設定だと、一度にすべての方向へ進む訳にはいかんから、仕方なくノンジャンルに行こう、みたいな話にしかならん。

    無知:はい、それで百科事典を読んでみたのですが「あゝ玉杯に花うけて」のところまで来て挫折しました。

    親父:とんだ赤毛組合だな。実を言うと検索に便利なアルファベット順や五十音順は、記憶するには不向きだという研究がある。関連のある項目を芋づる式に読む方がましだ。

    無知:そうでしたか。

    親父:しかし元々「知らないことは嫌だ」というネガティブな動機付けから始まった企てだから、何かを学んでいても、すぐにまだ学んでいない別の〈知らないこと〉が気になってくる。しかも知らないことは各方面に山のようにあるから、結局どれにも身が入らず、ぐるぐる回っているうちに、ほとんどどっちにも進んでいないことに気付いて、過ぎた歳月をうらむことになるだろう。達者でな。

    無知:ま、待って! どうしたらいいでしょうか?

    親父:こういう場合、正解は大抵つまらない上に受け入れがたいぞ。気にせず、強く生きろ。

    無知:いや、かえって気になります。

    親父:では言うが、あきらめろ。すべてを知ることは誰の手にも余る。知的分業を承認しないと、自分が知らない知識を探すなんてできるはずがない。また、一篇の論文を生み出すのに必要な熱量がどれほどのものか体感しないと、何でも知ることができるんじゃないかという甘美な夢はなかなか覚めない。

    無知:では専門バカになれと?

    親父:なれるもんならなってみろ。念のために言っとくがネットで阿呆なことを垂れ流してる◯◯学者や脳タレントがいるが、ああいうのは専門バカじゃなくただのバカだからな。

    無知:では八方ふさがりですか。何年もビジネス書と日経新聞を読んであとには何も残らない知的敗残兵のまま一生を送らねばならないのですか。

    親父:新聞にだって新刊書の書評ぐらい載るぞ。そういえば功成った連中の成功話に共通点が少ない理由は、ハトにランダムにエサを与えると生じる迷信行動で説明できるって話を知ってるか?

    無知:知りませんし聞きたくもありません。

    親父:まあ何に負けるか分からんが、知的劣等感から嫌がらせに走る奴は居ても、死んだ奴はいない。というか人間どのみち死ぬしな。

    無知:無言電話と玄関先に生ゴミを撒くのと、どちらがいいですか?

    親父:やれやれ。それくらいやる気があるなら「最速の素人」にでもなれ。

    無知:おおっ! 村人Bでも戦えますか?

    親父:あらかじめすべてを知ることは不可能だが、必要になった時に必要な知識や情報をなるべく速やかにかき集めるための準備ならできなくはない。

    無知:具体的には?

    親父:まあ、このブログはそういうことが書いてあるところなんだけどな。

    無知:そこを最短で、お願いします。

    親父:知ってる奴に聞け。それができないならググれ。

    無知:超がっかり。

    親父:文字数当たりのパフォーマンスを最大化すると、そういうアドバイスになる。

    無知:もう少し汗をかいてください。

    親父:かくのはお前だ。仕方がない、知りたいテーマについて聞ける奴がいない場合に、お前でもできそうなことを教えてやる。全く未知のテーマについて最速で数十から数百の文献を扱って自分なりのまとめができる程度だが。前提はとりあえずネットを見ることはできるってことでいいな。

    無知:前ふりが長過ぎましたが、それで手を打ちます。

    親父:まったく何様だ。とりあえず事典と書籍と論文を検索して3つの表を作っていけ。

    無知:どんな表ですか?

    親父:(1)文献×目次マトリクスと(2)文献×文献マトリクスと(3)文献×概念マトリクスの3つだ。どれから作ってもいいが、まあ最初は(1)から順番にやるといいだろう。

    無知:文献×目次マトリクスというのはどんなものですか?

    親父:見つけた文献の目次をあつめた表だ。

    (1)文献のタイトル、著者などを左端のマスへ入力する。
    (2)目次の見出しを拾い出し、タイトルの右に1つずつマス(セル)へ入力。
    (3)一つの文献が終わったら次の行へ(1)〜(2)を繰り返す。
    以下はおまけ
    (4)必要なら(目次の見出しだけでは内容がわかりづらい場合は)各章の概略をメモる
    (5)(どこになにが書いてあるか可視化できたら)同じ/似た内容をマーキングしたり囲んでつないだりする



    step3.png

    書籍だと現物を手に入れなくてもネットで目次がみれるからひたすらコピペすればいい。Webcat Plus Minusあたりで見れるだろ。詳しい作り方は、次の記事を参考にしろ。




    無知:こんなもの作って何か意味があるんですか?

    親父:お前さんがこれから調べたい分野やトピックについていくらか知っていて「土地勘」みたいなものがあるなら、もっと効率がいい手が思いつけるだろう。しかしまったくの無知なら、そこでどんなことが話題になっているか、どんな言葉・概念が使われているか、見当つかないだろう。そこで、目次を先に眺めておくと雰囲気みたいなものが分かる。同じようなことを書いてる本がやたらとあることだとか、そういう焼き直し本がどれかも見当がつく。頻出のキーワードや、論者によって意見が分かれてるトピックも分かってくる。すると、もう少しましな検索ができるようにもなる。

    無知:わざわざ表にまとめなくても、たくさんの文献を読めばいいのではないですか?

    親父:効率と根気の問題だな。目次だけなら100冊ぐらいこなすのは屁でもないが、手当たり次第に読むやり方は(慣れないうちは)よくて十数冊、でなきゃ数冊あたりで失速する。同じ分野の本は重複が多いから、そのあたりで「これ以上読んでも仕方ないんじゃないか」と思えてくる訳だ。文献を何十ってオーダーで扱うには、どのみち文献リストっていう外部記憶が要る。それに不案内なうちは、最初にカスみたいな文献をつかんじまって迷走しがちだ。目次だけでも網羅しとけば、たとえ迷走しても、別の文献が見えてるから立ち戻るのもはやい。


    無知:次の文献×文献マトリクスっていうのは?

    親父:それぞれの文献が、他の文献を参照したり言及したりしている部分を拾ってまとめた表だ。

    (1)表の上端に集めた論文名等をコピペする
    (2)表の左端に合わせた参考文献リストをコピペする
    (3)他の文献を参照している箇所を拾い出して入力
    (以下はおまけ)
    (4)言及が多い順に被引用文献をソートする(より多く参照された文献がマトリクスの上部に浮かび上がってくる。)
    (5)引用している側の文献についても必要なら並び替える


    mat-make.png

    これも詳しくは次の記事を読め。




    無知:つまり文献の参照関係をたどる表ですか。

    親父:ある文献が参照している文献、その文献が参照している文献、という具合に芋づる式に参照関係をたどって文献を追いかけていくのは文献調査の基本だ。実際は、ひとつの文献は複数の文献を参照しているのが普通だから、追っかけて行くと捕獲できる文献は雪だるま式に増えていく、スノーボール・リサーチだな。

    無知:はっきりいって面倒くさいです。

    親父:はっきり言うな。ある文献Aが他の文献Bを引いて何を言っているかをチェックしていけば、文献Bの概要やら評価の一欠片が分かる。文献Bを読むのに、外部支援として文献Aが使える訳だ。

    無知:文献の関係も、文献を読むのに活用するわけですか。

    親父:いろんな文献がこぞって取り上げてる文献は、その分野では基本的な必須文献か、それに近いもんだろう。これを見つけるということは、逆に見れば、一つの文献を共通して取り上げてる複数の文献を捕獲できることになる。文献Aだけだと心もとないが、他の文献A'、文献A''……と、文献Bを取り上げている複数の文献たちを見ていけば、文献Bの評価はもっとはっきりするだろう。要するにその分野の前提や文脈みたいなものが分かってくるという訳だ。まあ、手っ取り早いのは知ってる奴に聞くか、その分野の教科書でも読むことだけどな。しかし教科書のない分野は多いし、知り合いが物知りとは限らん。

    無知:おまけに友達もいないんです。

    親父:面倒くさいお前に幸いあれ! でだ、文献Bに対する、文献A、文献A'、文献A''……それぞれのスタンスは、逆に文献A、文献A'、文献A''……を評価する手がかりにもなる。共通必須文献として取り扱っているまともな(メインストリームにいようとする)文献か、それともあえて逆らおうとしている異端派なのか、ぐらいはすぐ分かるだろう。

    無知:最後は文献×概念マトリクスですか。

    親父:文献×目次マトリクスで、よく出てくるキーワードが分かってくるし、文献×文献マトリクスで文献が雪だるま式に集まって、それぞれの評価や関係も浮かんできた。そしたら、特に気になるキーワード(概念)について、それぞれの文献では何と言っているかを引っ張りだして、これまた表にまとめるんだ。

    (1)文献を集めて年代順に並べる
    (2)マトリクスへ抽出するキーワードを決める
    (3)文献からキーワードに関する記述を摘出してマトリクスを埋めていく



    これは次の記事で書いたレビュー・マトリクスの簡易版って感じだ。


    ひとつのキーワード(概念)に対して複数の文献から見ることができる。一つの視点からは見えなかったものが、他の視点からは見えるかもしれん。ある者の主張には良いとこばかり(悪いところばかり)だけでないことも気づきやすくなるだろう。誰かの受け売りやってるレベルをできるだけ速やかに抜ける方法は、複数の見方を何度も/何十にも突き合わせてみることだ。

    3matrix.png


      
    スポンサーサイト
    少女:聞きたいことがあるんだけど。プログラミングとかする?

    少年:しない。

    少女:前に何かちょこちょこっと作ってたことなかった?

    少年:コンピュータ周りの雑用をやらせるスクリプトのこと? 大抵は数行くらいの使い捨てだけど。繰り返し使ってるのは、近代デジタルライブラリーからダウンロードして一つのファイルにまとめる奴くらい。

    少女:あ、それ欲しい。そういうのってどうやったら作れるようになるの?

    少年:うーん、こういうのは禁煙さんが詳しいんだけど。よく使ってるのはPythonってプログラミング言語だけど、これも禁煙さんのオススメだったし。

    少女:そうなんだ。ねえ、今度一緒に禁煙さんとこ行かない?

    少年:いや、それはちょっと。

    少女:あれ?苦手だっけ?

    少年:少し。コンピュータの話になると、あの人ちょっと…・・・。

    少女:ふーん。じゃあ禁煙さんに教わったこと、教えて。

    少年:教わったっていっても大したことじゃ。「とりあえず、これ読め」とか、そういうのだし。

    少女:それそれ。何を読んだのか、具体的にそこを教えてよ。



    Pythonとコピペ・コーディング

    少年:Pythonは、特に本は見てなくて、公式サイトのドキュメントだけ。「Python のセットアップと利用法」(http://docs.python.jp/2/using/index.html)で、手順通りPythonをダウンロードしてきて使えるようにして、それからチュートリアル(http://docs.python.jp/2/tutorial/index.html)を半分くらいやった。

    http://docs.python.jp/2/tutorial/index.html

    少女:えーと、チュートリアルって何?

    少年:操作や使い方を一通り練習できる手順書。このように操作するとこうなる、こういうプログラムだとこうなる、って感じの構成になってて、書いてある手順通りやってみたり、例題の短いプログラムを入力して実行してみたりしながら、ひと通りのことが学べるようになってる。

    少女:君がよくやってる〈写経〉みたいに〈読む→写す→試す〉を繰り返していくの?

    少年:それよりは、出てくる数式を数式処理ソフトで計算しながら本を読むのに似てる。コンピュータ相手に入力しそこなうと、書いてあるとおりの事が起こらないから間違いには気づきやすい。

    少女:写してるだけで分かったりするものなの?

    少年:コンピュータにコードを入力していくのは、ただ書き写す(精確に自分の中を通す)だけじゃなくプラスアルファがあって、むしろ棋士が盤の上に棋譜を並べるのに近い気がする。実際にプログラムを動かすことと陸続きだし、写したプログラムを一部作り変えては試してみたりできるし。

    少女:駒の動き=プログラムの動きを自分の手でやってみる感じ?

    少年:そう。あと、今プログラムのどの部分を実行していて内部で何が起こっているかを逐一表示してくれるツールがあって、デバッガ(Debugger)とか統合開発環境(IDE)でできるんだけど、序盤過ぎたあたりから結構助けられた。使ってたのはオンライン上でできるやつで、PythonやJavaやJavaScript用だけど、Online Python Tutor(http://www.pythontutor.com)というのがあって、分かりやすかった。

    OnlinePythonTutor2.png


    少女:そうやってプログラムの動き方を追っかけていけば、作りたいものが作れるようになる?

    少年:あー、それはむしろ、逆引きというか「やりたいこと+Python」で検索して、見つけたものを組み合わせるって感じで。「コピペ・コーディング」「開発環境はGoogle」みたいな。

    少女:「写経」どころか「コピペ」? そんなのでいいの?

    少年:使ってる人が多い言語だと、結構なんとかなる。

    少女:「検索で何とかする」ってところが、らしいといえばらしいけど。

    少年:いや、他の誰かがすでにやってくれてることを再利用するのは、誰でもやってる普通のことなんだけど。今どきのプログラミング言語だと、特定の機能を持ったプログラムを「ライブラリ」って形で、他のプログラムから利用できるように部品化して利用しやすくしてある。自分がやりたいことをやってくれるプログラムを作るのは、一から全部自分でやるわけじゃなくて、そういう部品を探して組み合わせるのが主な作業って感じなんだけど。



    C言語とラテン語

    少女:それ以外に禁煙さんから何か教わった?

    少年:「自分では書かなくてもいいけど、C言語は読んで分かるようになっとくこと」って言われた。

    少女:どうして?

    少年:プログラマーの共通語だから。携帯電話や電化製品からスーパーコンピューターまで席巻したUnix(やUnix由来のOS)はローマ帝国みたいなもので(これを「UNIXの平和 パクス・ウニクサ」という)で、そのシステムを書くために登場したC言語はラテン語みたいなものだからって。

    少女:それって死語ってこと?

    少年:まだまだ現役だから、そんなこというと誰かに怒られそうだけど。「C言語=ラテン語」っていうのは共通語だって他に、C言語は文法は結構シンプルなんだけど、文法以外にこうした方がいいとかこうすべきでないみたいな慣習というか経験則があって、これもラテン語に似てる。

    少女:ラテン語って文法かんたんなの?

    少年:他の古典語に比べれば。ラテン語の場合、学ぶことが多いのはむしろ文法を学んだ後の方なんだ。

    少女:それで、どうやって勉強したの?

    少年:ネットの入門サイト(こことかここ)をいくつか眺めて文法事項が分かったらこれを読めって禁煙さんに『デーモン君のソース探検』って本を渡された。

    デーモン君のソース探検―BSDのソースコードを探る冒険者たちのための手引き書 (BSD magazine Books)デーモン君のソース探検―BSDのソースコードを探る冒険者たちのための手引き書 (BSD magazine Books)
    氷山 素子

    アスキー
    売り上げランキング : 621935

    Amazonで詳しく見る


    少女:どういう本?

    少年:主人公が中学1年のデーモン君で、毎回、デーモン君が通う中学校で宿題が出て、いろいろ調べるんだけど行き詰まって、毎回パパ(時にはママ)に泣きつくってパターンの対話もの。

    少女:私達と同じ歳ね。

    少年:いきなり「中学校の授業では、プログラムのソースを読みます。」からはじまる。

    少女:ええっ、読まないよ。

    少年:「ポインタは小学校で習わなかったのか?」とかパパに言われたりする。

    少女:いや、習わないよ。

    少年:こういうout-of-the-worldなノリでガンガン進んでいく、いかにも禁煙さんが好きそうな本なんだけど。NetBSDってUnixの一種なんだけど、そのコマンドとか関数のソースコードを毎回読んでいく。実際に動いてるシステムがC言語でどう書いてあるか探検してくというか。

    少女:いきなり実践って感じね。

    少年:さすがにいきなりは苦しかったんで、C言語の悪い書き方と良い書き方が対照してある『美しいCプログラミング見本帖』って本で、悪い書き方を書きなおしながら、ネットでの質問解答をまとめた『CプログラミングFAQ』ってのを読んでいった。でも、少しでも読めるようになったのは、自分でもすごく短いプログラム(カレンダーを表示する、みたいなやつ)をいくつか書いてみた後かな。

    美しいCプログラミング見本帖―ポインタ手習い指南美しいCプログラミング見本帖―ポインタ手習い指南
    柏原 正三

    翔泳社
    売り上げランキング : 262505

    Amazonで詳しく見る

    CプログラミングFAQ―Cプログラミングのよく尋ねられる質問 (新紀元社情報工学シリーズ)CプログラミングFAQ―Cプログラミングのよく尋ねられる質問 (新紀元社情報工学シリーズ)
    スティーブ サミット,Steve Summit,北野 欽一

    新紀元社
    売り上げランキング : 177096

    Amazonで詳しく見る



    少女:前に何かの時に「書かないと読めるようにならない」って言ってたね。あれは文章のことだったけど。

    少年:「読まないと書けるようにならない」というのもあると思うけど。C言語の入門サイトではあんまりな評判だったけど、ブライアン・カーニハン とデニス・リッチーの『プログラミング言語C』って本が、例題がUNIXコマンドを自分で書いてみるみたいなのが多くて、ちょうどデーモン君と反対側から登る感じで読めた。ホントはその前に『UNIXプログラミング環境』を見つけて、そっちに助けられた感じなんだけど。

    プログラミング言語C 第2版 ANSI規格準拠プログラミング言語C 第2版 ANSI規格準拠
    B.W. カーニハン,D.M. リッチー,石田 晴久

    共立出版
    売り上げランキング : 20157

    Amazonで詳しく見る

    UNIXプログラミング環境 (海外ブックス)UNIXプログラミング環境 (海外ブックス)
    Brian W.Kernighan,Rob Pike,石田 晴久

    アスキー
    売り上げランキング : 262813

    Amazonで詳しく見る



    少女:それってどういう本?

    少年:どっちもUnixやC言語を作った本人たちの本なんだけど、『UNIXプログラミング環境』は、Unixで仕事をするのに、手持ちの道具をどう使うか、どう組み合わせるかみたいなところから始まって、このコマンドちょっと使い勝手が良くないから少しだけ簡単に改良してみるって話から少しずつプログラミングするようになって、最後はC言語でコマンドをつくるところまで進んでいく。

    少女:それもデーモン君の反対側から登る本だったんだ。

    少年:やりたいことがあってやり方を調べるのはネットを使うとそんなに苦労せずに分かることが多いし、もともとやり方(How to do)は見よう見まねでまだ何とかなるものなんだけど、何でこんなことやるのか(Why to do)とか、これができて何がうれしいのかっていう背景というか文脈(コンテキスト)みたいなことが『UNIXプログラミング環境』を読むと随分納得できた。Unix抜きでC言語だけの入門書って、そのへんがばっさり抜けてるから、なんか気持ち悪かったんだけど、そのあたりを埋めてくれた気がする。




    Lispとレトロゲーム

    少女:他には何を?

    少年:あとはLispをやれ、って。

    少女:なんて言って勧められたの?

    少年:……「Lispやるとアタマがよくなる」

    少女:うわあ。それはさすがにちょっと。

    少年:で、『Land of Lisp』っていう禁煙さん好みの本が出てきて、あんまりひどいんで、大笑いしながら勢いで読めた。実はLispの本で最後まで読めたのは初めて。

    Land of LispLand of Lisp
    M.D. Conrad Barski,川合 史朗

    オライリージャパン
    売り上げランキング : 104249

    Amazonで詳しく見る

    Land of LispLand of Lisp


    売り上げランキング : 1897610

    Amazonで詳しく見る



    少女:どういう本?

    少年:レトロゲームというか、パソコン黎明期のゲームあたりからはじめて、だんだんややこしいゲームを作っていく中でLispを学ぼうって本。ノリは何というか、ネットでみかけるLisperのジョークを確信犯的に繰り出してく感じなんだけど。

    少女:LisperってLispやってる人のこと? どういうジョーク?

    少年:いや「神様は世界をLispで書いた」とか、そういうの。(あとこの辺とかこの辺とかこの辺)。

    OnlinePythonTutor2.png

    http://xkcd.com/224/



    少年:でもゲームを題材っていうのはいい手かも、って思った。


    少女:どうして?

    少年:日常のルーチン作業で扱うような表にまとめられるようなデータってそこまで複雑じゃないし、お仕着せのライブラリで済みそうなのだと、Lispの有り難みが出にくいというか。ゲームだと設定とか世界観次第で好きなだけ入り組んだデータ構造とか、面倒くさい問題を扱って「Lispすごい」って話に持って行きやすい。昔だと、そういう面倒くさい題材が人工知能だったんだと思う。

    少女:読んだのはそれくらい?

    少年:いや、『Land of Lisp』 は勢いでどんどん進む本だから、笑ってるうちに途中から理解が怪しくなってきたんで(コンピュータに入力しながら読むのをサボりだしたせいもあるけど)、もっと易しい本とか丁寧な本で補完した。手に取った本の中だと、『対話によるCommon Lisp入門』が一番コンパクトで内容は最低限だけど、前提知識なくても一から説明してくれる感じ。隙あらばダジャレを織り込んでくるのが玉に瑕だけど。

    対話によるCommon Lisp入門 POD版対話によるCommon Lisp入門 POD版
    栗原 正仁

    森北出版
    売り上げランキング : 622423

    Amazonで詳しく見る



    少女:Lispって、普通の本はないの?

    少年:ポール・グレアムの『ANSI Common Lisp』は、人がいうほど癖なかった。これも網羅的とまではいかないけど『対話によるCommon Lisp入門』よりずっとカバーしてくれる範囲は広くて、例として出てくるコードも短くて、入力して試しやすかった。Common Lispには、プログラムのどの部分を実行していて内部で何が起こっているかを逐一表示するっていうのが標準装備(traceとかstep)だから、入力サボったのを反省して、それからは使い倒した。

    ANSI Common Lisp (スタンダードテキスト)ANSI Common Lisp (スタンダードテキスト)
    ポール グレアム,Paul Graham,久野 雅樹,須賀 哲夫

    ピアソンエデュケーション
    売り上げランキング : 386996

    Amazonで詳しく見る



    少年:もう少し早足で進むけど、他にプログラミングの経験がある人なら、『実践Common Lisp』一択かも。Land of Lispと同じくらいのレベルで、ぶっ飛んだところとかマンガはないけど、より丁寧でちゃんと教科書になってる。カバーする範囲も広くて、説明も結構詳しい。ピーター・ノーヴィグの『実用 Common Lisp』は、古いよき時代のAI人工知能(Land of Lisp がレトロゲームなら、こっちはレトロAI)を題材にしていて、Lispを使って未解決の問題に挑むことがどういう感じなのか体験できる本。

    実践Common Lisp実践Common Lisp
    Peter Seibel,佐野匡俊,水丸淳,園城雅之,金子祐介

    オーム社
    売り上げランキング : 395747

    Amazonで詳しく見る

    実用 Common Lisp (IT Architects’Archive CLASSIC MODER)実用 Common Lisp (IT Architects’Archive CLASSIC MODER)
    ピーター・ノーヴィグ,杉本 宣男

    翔泳社
    売り上げランキング : 419190

    Amazonで詳しく見る


    あとScheme手習いScheme修行を算数のドリルみたいに繰り返しやったかな。

    Scheme手習いScheme手習い
    Daniel P. Friedman,Matthias Felleisen,元吉 文男,横山 晶一

    オーム社
    売り上げランキング : 251110

    Amazonで詳しく見る

    Scheme修行Scheme修行
    Daniel P. Friedman and Matthias Felleisen,元吉 文男,横山 晶一

    オーム社
    売り上げランキング : 588128

    Amazonで詳しく見る by AZlink



    ネットではANSI Common Lispの仕様を引けるHyperSpecと、今上げたようなCommon Lispの本(原書)を横断検索できるlispdoc(http://lispdoc.com)が便利。

    http://www.lispworks.com/documentation/HyperSpec/Front/index.htm

    あとコンパクトなSimplified Common Lisp referenceというのがあって、これに出てくる例を全部Ankiに入れて英語の構文みたいに覚えた。

    AnkiLisp1.png






    禁煙さんを訪ねる

    少女:という訳で、一人できました。どうして彼、禁煙さんが苦手なんですか?

    禁煙:そういえば中学に入ったお祝いに、コンピュータをあげようと思ったんだけど、断られちゃったわね。

    少女:なんでまた?

    禁煙:冷却装置に凝った自作機だったんだけど、凝りすぎて水煙管(キセル)みたいになっちゃってね。

    少女:よく分からないけど、なんか分かった気がします。

    禁煙:それで何が聞きたいのかしら?

    少女:どうやったらプログラムを書けるようになるか知りたくて彼に聞いてみたんですけど、聞く相手を間違えたって思いました。

    禁煙:ああ、熊が水を飲むみたいな学び方するからね。

    少女:でも気になったことがあって。禁煙さんが勧めたの、PythonとC言語とLispだって聞いたんですけど、どうしてこの3つだったんですか?

    禁煙:Bookishで自分で調べるのが好きで得意な子だから、ちょっと無茶ぶりしすぎたかもしれないけどね。せっかくプログラミングに触れるのだから、いろんな側面を知ってほしいと思って。

    少女:いろんな側面、ですか?



    巨人の肩に乗るプログラミング

    禁煙:ひとつは、そうね、「既存の解決策を探して組み合わせるプログラミング」って言えるかしら。「巨人の肩に乗る」とまでいうと言い過ぎだけど。

    少女:彼も「コピペ・コーディング」「開発環境はGoogle」みたいなこと言ってました。

    禁煙:もっとも検索のパラドクスというか、分からないものは探せないという問題があるけどね。レベルが低いままだと低いレベルの情報しか手に入らない。検索結果に表示されても理解できなくてスルーしちゃうし、見当違いのキーワードで探してしまう。

    少女:やりたいことができるプログラムの部品を手に入れるのは、やっぱりそれなりに学ばないといけないんですね。

    禁煙:ライブラリを駆使して、短い時間と小さな手間で目的を果たすのは、アプローチっていうより、ごく普通のことになっているわね。世の中で必要とされている大方のプログラムは多分、既存の解決法の組み合わせでなんとかなるものだろうし。誰かが用意してくれているものをうまく使えば、自分だけではとても無理な大規模複雑なこともできるし。仕事で何かつくるときも、時間も人員も限られているならその方が絶対いいし。初心者にとっても、低コストで自分の欲しいものができるって話ならモチベーションも維持しやすいしね。

    少女:それがPythonを勧めた理由ですか?

    禁煙:近頃の人気のあるプログラミング言語は大抵ライブラリを揃ってるから、Python以外でもよかったんだけどね。あの子は今の子にしてはびっくりするくらいBookishだからってこともあるかな。Pythonはドキュメントも良く出来てるし、ソースコードも読みやすいしね。同じ歳でも、他の子になら、もっとヴィジュアルで見目麗しい(bells and whistlesな)ものにしたでしょうね。あとは、初心者にもいいけど、本格的なもの、たとえばあの子が普段使っているようなものだって作れるというのもあったかしら。

    少女:Pythonで作られてるものって?

    禁煙:あの子が使ってるのだと、AnkiとかDropboxとかCalibre(オープンソースの電子書籍管理ツール)とか。

    少女:あ、それ私も使ってます。

    禁煙:初めてだからインデントの習慣を身につけてほしいとか、細かい理由もあった気がするけど。



    大地を掘り下げるプログラミング

    少女:「いろんな側面」というと、あと2つあるんですか?

    禁煙:つぎは「分解と再構成で理解するプログラミング」って感じかしら。身の回りの機械を片っ端から分解してまわったことってない?

    少女:いえ、そういうのは。

    禁煙:ただわくわくするとか面白いから分解するんだけど、あれって機械みたいに複雑なものを理解する原体験ってところがあるの。プログラマのインタビュー集(あとで出てくる『Coders at Work プログラミングの技をめぐる探求』とか)を読むと、やたらと子供の頃、分解したなあって思い出話が出てきたりするんだけど。

    少女:C言語で勧めた『デーモン君のソース探検』って、プログラムの分解本ですか?

    禁煙:お仕着せの部品(ライブラリ)の組み合わせでプログラミングに入門したら、今度はその部品がどんな風にできているか知りたいと思わない? それが分かると既成のライブラリを改造したり、もっと行くと自分でライブラリを作れるところへ進めるかもしれない。自分が使っているソフトで「こうなったらいいな」って改造ができるかもしれない。改造のパッチファイルを作者に送れば、ただ要望出すのと違って、取り入れられる確率は高まるし、お気にい入りのソフト作者とガチでコミュニケーションがとれるかもしれない。

    少女:なんかレベルが上がってる感じがします。でもなんでC言語なんですか?

    禁煙:ひとつは、OSのカーネルから普段使いのアプリケーションまで、いろんなものがC言語で書かれてきたから。Unixやそれに由来するシステムがC言語で書かれてる話はしたかしら。あと、Pythonもそうだけど、C言語以降に登場した多くのプログラミング言語がC言語で書かれてる。ライブラリも、例えばPythonの場合だと、Pythonで書かれたものもあれば、速度や効率の良さからC言語で書かれたものもあるわ。

    少女:もうひとつは?

    禁煙:「C言語=ラテン語」って比喩にはもうひとつ含意があって、C言語が普及したせいで、その後に生まれた言語はC言語の影響を強く受けているものが多いの。ラテン語が分かると、俗ラテン語から生まれたロマンス語派の諸言語(スペイン語,ポルトガル語,イタリア語,フランス語,ルーマニア語等など)が理解しやすくなるように、C言語から影響受けたawk、C++、Objective-C、Java、JavaScript、PerlやPython……を理解しやすくなるかもしれない。もっとも「フランス語を学ぶのにまずラテン語から」っていうのが学習コストからいってナンセンスなように、最初にC言語を学ばないといけないなんてことはないけどね。むしろ最初にプログラミングを学ぶ人にC言語はないわ、って感じに覚えてもらえたらいいかな。

    少女:話を戻すと、お仕着せの部品(ライブラリ)の組み合わせって楽そうに見えたんですけど、そういうのを分解して理解するのって時間もかかるし大変そうですね。

    禁煙:デーモン君も毎回行き詰まって泣いてばかりだったしね。そういう意味では確かに一つレベルアップって感じなのかも。出来合いを並べるだけの《お惣菜》プログラマから、やる気になれば自前でやれる一人前のプログラマになるってことだから。もっとも人が書いたソースコードを読んで(分解して再構成して)理解するというのは、いきなりC言語でやるより、もっと初心者にやさしい言語、彼の場合ならPythonでやった方がずっと易しいから、まずはそちらで経験を積むのがおすすめだけど。

    少女:どうしてですか?

    禁煙:C言語だとプログラマが自分でやらなきゃならないことでも、もっと易しい言語だとプログラミング言語自体が担ってくれる部分が多くて、同じことをやろうとする場合でもプログラムがシンプルかつ短くて済むから。短いプログラムの方が、これはもう圧倒的に、速く読めて理解もしやすい。Pythonには、Nullege(http://nullege.com/)っていうPythonのソースコード専門の検索エンジンもあって、こういうのも彼に勧めた理由なんだけどね。

    http://nullege.com/



    残り1割のためのプログラミング

    少女:じゃあ最後の側面ですけど。それと「Lispやるとアタマがよくなる」っていうのは?

    禁煙:さすがにちょっと引いちゃうね。

    少女:ええ。でも、なんでLispだったんですか?

    禁煙:せっかくだからコンピュータにできる《最果て》を知ってほしいと思って。

    少女:他の言語じゃダメなんですか?

    禁煙:そうね、少し回り道だけど、こんな話をしようか。さっき、プログラミングしなきゃいけない大半のことは、既存の解決策の応用か組み合わせで解決できるし、世の中のほとんどのプログラムはそういうものだって言ったね。

    少女:はい。

    禁煙:ニュージャージ・アプローチなんて言い方があるんだけど、すべての問題に対処しようとすると複雑で大変になってしまうけれど、複雑で大変なのはむしろ少数の例外で9割まではシンプルな手法で間に合うのだから、この9割が解けるシンプルな解決でいいじゃないか、というスタンスで成功したのがUnixやC言語なのね。完全な正しさよりシンプルさを優先するというか。

    少女:実用的というか、実践的な考え方ですね。

    禁煙:ええ。だから、他のものよりは、容易に実装できて、なおかつ世の中の大半を占めるしょぼいマシンでも動いた。だから世界を席巻できたとも言えるんだけど。

    少女:Lispは違うんですか。

    禁煙:UnixやC言語より前の、コンピュータを使うことが、おもいっきり背を伸ばして届くかどうかというところに触れることだった時代の産物というか、プログラミングが既存の手法やシンプルなやり方じゃ間に合わない問題に挑むことだった文化を残している感じがするのね。9割のことが解決できるくらいじゃ満足できなくて、みんなが難問だとして放置した残りは誰が解くんだ?オレだよ!みたいな。そんなギリギリの問題が、ある時代には人工知能だったり、コンピュータ・グラフィックだったりしたんじゃないかしら。

    少女:その時代時代の最先端みたいなところで使われてきたってことですか? どうしてなんでしょう?

    禁煙:取り組む問題はいつも難しくて、プログラミング言語が提供するものでは足りないのがいつものことだったから、自分で一から(アセンブラで)作るか、プログラミング言語を問題に必要なだけ拡張するのは当たり前だったのね。そしてLispは、そういう拡張がやりやすい言語だったの。何しろ、言語の機能をほとんど際限なく、文法構造すら拡張できるぐらい。

    少女:拡張するのと、難問を解くのは、どういう関係があるんですか?

    禁煙:解き方がまだ誰にも分からない難問を前にして手始めにやれることといえば、問題をなんとか書き表すこと、できればその構造を表現すること、それから、それをいじくりながら答えっぽいものに近づける試行錯誤の繰り返すことくらいよね。そうして、一つの例題についてうまく手が見つかったら、それを一般化して他の例題についても解けないかやってみる。Lispは、問題の構造を書き表すのも、それをいじくる試行錯誤も、それを一般化したものも、同じフォーマットで書けたから、今言ったみたいなやり方にうってつけだったの。

    少女:でも、そのうちコンピュータの性能も上がって、これまでの蓄積もあって、コンピュータでできることは広がっていったんじゃないですか?

    禁煙:そうね。コンピュータの歴史が積み重なって、かつての最先端はやがて既存の手法で解けるものになっていったわ。人工知能だって、今どきそんな手探りじゃなくて、確立された手法ごとにライブラリがあるし。それでも、コンピュータで立ち向かう難問が次々生まれてきたし、この先だって今の時点では予想もつかない問題に挑まなくちゃならないかもしれない。そのためには、できるだけ制限のない《何でもあり》の道具が欲しいと願うのも無理ないと思わない? 

    少女:実際になんでもできるプログラミング言語なんて作れないから、だったらどこまでも拡張できる言語って話になるんですね。聞けば聞くほど、既存の解決策の組み合わせですばやくつくるプログラミングの真逆みたいに思えます。

    禁煙:違った経験をしてほしいってところから語り始めたせいもあるけどね。今ではLispにも(流行りの言語ほどじゃないけど)ライブラリ(たとえばここ参照)がそろっているから、既存の解決法の組み合わせを忌避してるわけじゃないし。

    少女:これは聞いていいのか迷うんですけど、Lispってすごそうだけど人気無いんですか?

    禁煙:そうね。理由は偶然を含めて色々あるんだろうけど、Lispに難しいところがあるとしたら、何でもありの拡張性の裏面なんでしょうね。Lispで問題を解くことは、問題に特化した新しい言語をつくるようなものだけど、プログラミング言語を作ることはきっと、プログラミング言語をただ使うことよりはいくらか難しいの。自分以外誰も使わないオレオレ言語であってもね。もちろん、ずっと楽しいことでもあると、言い添えなくちゃいけないでしょうけど。



    (おまけ)様々なプログラミング言語を知る

    少女:オレオレ言語はともかく、他のプログラミング言語のことをもっと知りたいと思ったら、なにかいい本はありますか?

    禁煙:プログラミング言語のはじまりから『ソフトウェアの20世紀―ヒトとコンピュータの対話の歴史』という本があるけど。中村真一郎の『文章読本』みたいに、実際のソースコードつきで、言語の発展にともなってどのような表現に変わって行ったかを示してあって面白い本。当時のコンピュータの状況から世相/時代背景までフォローしてあるわ。この本は20世紀まで扱ってるから、言語で言うと出てくるのはJavaまでだけれど。

    ソフトウェアの20世紀―ヒトとコンピュータの対話の歴史ソフトウェアの20世紀―ヒトとコンピュータの対話の歴史
    長谷川 裕行

    翔泳社
    売り上げランキング : 637687

    Amazonで詳しく見る



    禁煙:それより新しいものも含めて、プログラミング言語を作った本人にインタビューした『言語設計者たちが考えること』は、Rubyのまつもとゆきひろさん以外、みんな他の言語の悪口言ってて楽しめるわ。

    言語設計者たちが考えること (THEORY/IN/PRACTICE)言語設計者たちが考えること (THEORY/IN/PRACTICE)
    Federico Biancuzzi,Shane Warden,伊藤 真浩,頃末 和義,佐藤 嘉一,鈴木 幸敏,村上 雅章

    オライリージャパン
    売り上げランキング : 148283

    Amazonで詳しく見る



    禁煙:全員が言語設計者じゃないけど、JavaScriptやErlangやCommon LispやSchemeやSmalltalkやC言語を作った人たちを含むインタビュー集の『Coders at Work プログラミングの技をめぐる探求』は、これの副読本として読めるかしら。

    Coders at Work プログラミングの技をめぐる探求Coders at Work プログラミングの技をめぐる探求
    Peter Seibel,青木 靖

    オーム社
    売り上げランキング : 226754

    Amazonで詳しく見る



    禁煙:こういう当事者ものじゃなくて、プログラミング言語の発展をもう少し俯瞰的に扱って、新しい概念や特徴がどうして登場してきたかをまとめてくれる『コーディングを支える技術 ~成り立ちから学ぶプログラミング作法』という本も役に立つのじゃないかしら。

    コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)
    西尾 泰和

    技術評論社
    売り上げランキング : 25899

    Amazonで詳しく見る



     
     
     

     筆の遅い人はどの分野にもいる。
     
     けれども、主として井上ひさしの貢献によって、遅筆といえばまず劇作家を思い浮かべてしまう偏見がある。
     これはおそらく、他のジャンルよりも遅筆のイメージが印象的でユーモラスなことによるのだろう。
     すでに幕が上がっているのに台本が完成せず、舞台袖で残りの台詞を書いているようなイメージである。
     
     しかし劇作家のすべてが遅筆という訳ではない。
     たとえば北村想は、本人の表現を借りるなら、初演に台本が出来上がっているどころか、脚本集として出版済みであるほど、筆の速い人である。
     「書くのが遅いのをなんとかしたい」という相談に答える形で、北村想は、何故自分は筆が速いのか、筆の遅い劇作家と何が違うのかを説明している。
     遅筆癖をやめ、はやく書くための〈秘訣〉としても読めるその説明は、ほとんどの秘訣がそうなように、身も蓋もないものであった。




    今回の出典は

    高校生のための実践劇作入門―劇作家からの十二の手紙高校生のための実践劇作入門―劇作家からの十二の手紙
    北村 想

    白水社
    売り上げランキング : 208002

    Amazonで詳しく見る


    具体的で身も蓋もないことしか書いてない、あらゆるジャンルで書き始めようとしている人が手元に置くべき実用書。





    遅筆から抜け出すための身も蓋もない教え

     北村想は何故はやく書けるのか?
     それは、筆の遅い劇作家が最後の最後まで作品を良くしようとぎりぎりまで努力と苦闘を続けるのに対して、自分は粘ってもそこまで大して変わらないだろうと、早々に完成させてしまうからだ、という。

     芸術家にあるまじき投げやりなスタンスだと眉をひそめる人もいるかもしれない。
     しかし芸術家が自身の芸術的衝動や霊感に従う義務を負っているとしたら、劇作家はまた別の義務を負っている。台本を間に合わせ役者や演出家やプロデューサその他関係者に犠牲を強要しないこと、その制約の中で(できるならなるべく良い)台本を書き上げることだ。でないと舞台公演は延期され、役者や劇関係者は仕事を失い、観客は何もみることができない。

    このような〈近代的〉な芸術家像は、料金の未払とかクライエントと揉めたりといった外的原因によってではなく、自らの創作的な意志と衝動によって作品製作を中断し、多くの未完成作品を残したミケランジェロを嚆矢とするというフォークロアがある。
     
     
     なるほどプロは仕事だから締切に間に合わせるのが当然だ。
     しかし誰に求められるでもなく好きに書いている自分には、その話に乗る理由がないという人もいるだろう。
     その心意気やよし。
     だが、上達のためには、「どのように書けばいいか」悩むよりも、最後まで書き終えることを優先したほうがいい。
     
     どう書こうか悩むことと、実際に書くことは、上達に関していえば等価ではない。
     言うまでもなく、実際に書いた方がずっと上達に寄与する。
     どんなものであっても(たとえ目を背けたくなるようなしろものであっても)書き終えることで、人は多くを知ることができ、次のステージに進むことができる。
     
     これらから導かれるのは次のことである。
     「もっとうまく書けるかも」という妄執をやめれば、人はもっとたくさん書くようにもなるから、最終的には、よりうまく書けるようにもなる。
     
     
     
    書き終えることでたどり着く地点

     これだけだと「お前なんかどう頑張ったって、うまく書けっこないのだからあきらめろ」とだけ言われているかのようで、書くことに真剣に向かい合う意識の高い文章書きさんは反発を覚えるかもしれない。
     なので、蛇足と思いながら、もう少し続けてみる。


     「もっとうまく書けるかも」という妄執に囚われていると、書き手はもっとマシな何かを書ける可能性を求めて、完成させることを引き伸ばすか、別の書き物に移る可能性が高い。

     〈完成させることを引き伸ばす〉という症状は、自分に対する要求水準の上昇といった形で現れる。
     「これだけ時間をかけてしまったのだから、並大抵のレベルでは満足すまい」といった心持ちが湧いてくれば、延期と要求水準の上昇の間で悪循環が形成され、完成はますます遠のいてしまうだろう。
     
     〈別の書き物に移る〉ことはこんな風に生じる。アイデアは新鮮な分だけ素晴らしく見えるものだ。より新しい思いつきは、今書いているものよりも〈新しい〉というだけで成功しそうな気がしてしまう。
     今書いているものがうまく行っていないなら、なおさら別の可能性を選ぶほうが利口で合理的な感じがする。
     
     言うまでもなく、これらは悪い選択だ。
     

     ヒトとしての成熟が、「自分はきっと何者にかなれるはず」と無根拠に信じていなければやってられない思春期を抜け出し、「自分は確かに何者にもなれないのだ」という事実を受け入れるところから始まるように(地に足の付いた努力はここから始まる)、書き手としての成熟は、「自分はいつかすばらしい何かを書く(書ける)はず」という妄執から覚め、「これはまったく満足のいくものではないが、私は今ここでこの文章を最後まで書くのだ」というところから始まる

    「どのように書くか how to write」につかまらない、また、つかまったとしてもできるだけすばやく抜け出すコツは、「何を書くか what to write」に注力することだ。「どのように書くのがよいか how to write」という問いは、「どのように振舞えば相手の好意を得られるか」にも似て、答えが無数にある問いである。
     
     これは可能性についての断念ではなく、(誰かに与えられた訳ではない)自分に対する義務を果たそうという決断だ。
     
     そうして書き続けても、書いている間中、それもひっきりなしに「違う!こうじゃない!」という感じに襲われるだろう。
     時には、思ってもみないほどスラスラと、まるで刷毛で撫でただけで土の中から遺物がどんどん現れるかのように、原稿用紙(エディタ)の上に書き言葉が生まれ出る場合もないではない。
     しかし、ほとんどの時間、書き手は違和感という壁に繰り返し頭をぶつける。
     はっきり言って不愉快だし、不快な感じばかりが続けば、「こうまでして書かなきゃいけないものか」という気持ちに襲われる。ついには書き続けられることができなくなる。
     
     しかし、この違和感は、書き手を押し留める障害であるだけではなく、書き手に力を与え、次に進む足掛かりにもなる。
     こうしたギャップに繰り返し頭をぶつけ、未だ形をとらない〈表現〉と思い通りにならない〈書き言葉〉の間を繰り返し往復して、はじめて人は本当の意味で〈考える〉ことができるようになる。

     では最後まで書き終えれば、書き手はこの違和感から解放されるのか?
     否。
     むしろそこで分かるのは、(すぐにかき消えてしまう、つかの間の高揚感を除けば)「違う!こうじゃない!」という違和感から書き手が解放されることは、ほとんどないという事実である。
     しかし、これこそが書き終えた者だけが手にすることができるギフトである。
     《最後》まで書き終えて始めて、人は書きたいと思っていたことが本当は何であるか、自分が現に書いたものはそれといかに違っているかを知る。
     思っていたようには決して書けないということ、書こうとしていたもののすべてを書くことは決してできないのだと思い知る。
     
     このすぐ先に、「うまく書けない」(あるいは「書き方がわからない」「才能がない」)なんてことは、書くことを回避したり、書き終えることを引き伸ばす理由には全くならないのだと、覚知する瞬間がやって来る。こうして書き手としての幼年期は終わりを迎える。
     


     「この先は荒野です。道がありません」
     「そうか。では進もうか」

     

    (参考記事)