SSブログ

オブジェクトを使い回す [プログラム]

プログラムを設計するとき、まずはどういうオブジェクトを配置するかを考えよう。たとえば、何かのイベントを企画するとしよう。そのとき、どういう役割の人を配置するかを考えて計画を立てるだろう。それと同じだ。

 それぞれのオブジェクトには、それぞれの役割が割り当てられる。よく使われるのは、ファイルから読み込んだデータを表すオブジェクト。それから、計算した結果を持っていてもらうオブジェクト。計算にはいくつかのオブジェクトが必要かもしれない。それに、関数を使うと、関数というのは、あるデータを渡して、何か一定の処理をしてもらって、結果を報告してもらうものだ。するとその報告を受け取って、後で使い回すためのオブジェクトが必要になる。関数にはほとんど結果を受け取るためのオブジェクトを用意しておいた方がいい。

 プログラムの世界で、もっとも基本的なオブジェクトの種類は、文字列と数値である。これは「型」に当たる。もちろん、一つのプログラムで、文字列が一つ、数値が一つなどということはないので、いくつもの文字列オブジェクトが作られ、いくつもの数値オブジェクトが作られる。「作られる」というよりは、あなたが「作り出す」ことになる。

 新しいオブジェクトを、プログラム世界の中で「創造」するには、オブジェクトの型を考えた上で、何らかのデータに名前を付ける。データと名前を組み合わせることで、オブジェクトが活動を始めるのである。必ず、最初に、この「創造」の儀式が必要になる。

 一度作った名前は、さらに別のものに貼り替えることもできる。データ自体は、いくらでも変更することが出来る。名前は、そういう変化するデータに対して、一定の永続的な存在となっている。「変数」というのも同じことで、変数は名前は変わらないが、その値はいろいろに変わるから「変数」と言われるのである。まあ、変数というよりは、オブジェクトと言う方が、プログラム世界の構成要素としては適しているだろう。

 この、どういうオブジェクトを作り出し、それらにどういう役目を担わせるか、ということを計画するのが、プログラムを作るときの最も重要な点である。


変数が主役 [プログラム]

 プログラミング言語の文法を覚えることと、実際に何かの問題を解決するためのプログラムを作ることの間には、大きなギャップがある。何も難しい、複雑な問題を解決しようというのではなく、プログラミングの初心者が最初に越えなければならない壁について、である。

 この点について、プログラムをバーチャルなロボットと考え、ロボットにどのような動きを命令するか、という観点からプログラミングについて、いくつかの記事をこのブログでも書いてきた。

 これは教育的には非常におもしろい問題で、学生を教えながら、その躓き方、それの乗り越え方をよく観察すると、その「難しい」というメカニズムが分かるような気がする。

 それなりにできる学生でも、何のサンプルもなく直接何か問題を解かせようとすると、かなりの試行錯誤をする。特に変数というものの重要性や使い道、使い方がピンとこないようだ。

 これまで、僕は変数という概念を使わないでプログラムを出来るのではないか、というようなことを書いてきた。確かにそれは可能だろうと思う。プログラム世界が現実の世界のあるモデルであるとすると、現実の世界に「変数」に当たるものは存在しない。具体的な物、つまりオブジェクトが存在し、それに対して名前が付いている。あるいはそのオブジェクトが、何らかの種に属している、その種はまた、より上位の類に属している、といった関係があるだけだ。

 とすれば、プログラム世界でも、そこには具体的なオブジェクトが存在し、それが何らかの種、プログラムミングの用語では「型」あるいは「クラス」に属している。そして、それぞれの型やオブジェクトには「名前」が付いている。「型」や「クラス」は既に名前が決められているが、個々のオブジェクトについては、プログラムを作る人が、創造主になって「名前」をつけ、世界にあらしめないといけない。

プログラムを構成する主要な要素は、二つ、オブジェクトと関数(メソッド)である。そして、それらを組み合わせるための文法が、様々な構文である。プログラムは、一つの仕事を実現するために、必要なオブジェクトを作り出し、それらを利用して関数で動かし、そういうステップを、文法規則に副って連ねていくことで、出来上がっている。

 だから、まず、問題を解くときに、どういうオブジェクトを必要とするかを考え、関数と構文でもって、そのオブジェクトを操作していく、と考えると、分かりやすいのではないかと思う。

 


検索と置換と正規表現 [プログラム]

 エディタで編集をする場合、検索と置換は最も有用な機能である。と思うのだが、余りエディタを使わない人、Wordを主に使い、時にメモ帳でプレーンテキストを使うだけのような人は、一体どれくらい検索・置換を使っているだろうか。

 そのうち、検索は、それなりに分かりやすいかも知れない。おそらくインターネットでの検索(Googleのように検索語句で検索するような)ならば、よく使っているだろう。表示した一つのページの中で、何かを検索することもしばしばあるだろう。そのことからの連想で、ワープロやエディタでも同じように、検索することはあるかも知れない。とは言っても、正規表現で検索するようなことは少ないはずだ。そもそも、テキスト編集によく使われるMS Wordの検索機能は、すごく使いづらい。特殊文字とか言って、非標準の記号を使う。正規表現と似ているが少しずつ違っているものを、独自の記号に割り当てている。これはとても覚える気がしない。

 実際に編集作業に威力を発揮するのは、置換の方である。しかし、これはWebサーフィンでは必要ないこともあり、テキスト編集中にもほとんど使われないのではないだろうか。単純な置換であっても、かなりの省力化になるはずだ。

 たとえば、まったくでたらめな内容だが、次のようなJavaのコードを再利用して、Pythonのスクリプトに書き換えるとしよう。

System.out.println("abcd " + (1 + 2 + 3) + " efgh");
System.out.println("ijkl " + (4 + 5 + 6) + " mnop");
System.out.println("qrst " + (7 + 8 + 9) + " uvwx");
System.out.println("yzAB " + (10 + 11+ 12) + " CDEF");

これは、Pythonでは、

print "abcd ", (1 + 2 + 3), " efgh"
print "ijkl ", (4 + 5 + 6), " mnop"
print "qrst ", (7 + 8 + 9), " uvwx"
print "yzAB ", (10 + 11+ 12), " CDEF"

と書かれる。このように書き換えるためには、

  1. System.out.println( を print に置換する。
  2. " + ( を ", ( に置換する。
  3. ) + "を、), に置換する。
  4. ); を空文字列に置換する。つまり、削除する。

というように、何度か置換を繰り返す。

 このような置換をする場合、対象となる文字列をよくよく観察し、そこに一定の法則を発見することだ。法則性があれば、それをいっきに置換することができる。あるいは何もない文字列に置換すれば、削除することができる。

 正規表現を使えるようになれば、もっといろいろなことができるようになる。たとえば、(や)の前後にあるスペースを削除する、という課題があるとき、あるいは、二行以上の空行を削除する、という課題があるとき、簡単な正規表現が使えれば、非常に効率的に置換をすることできる。もし正規表現を使わなければ、いくつあるか分からないスペースや空行を一々指定しなければならないことになる。そして今よりも忙しくなる。

 とはいえ、これまで正規表現を教えていて、うまくいった試しがない。その場その場でホワイトボードでやった置換をやってみるところまではいいが、その先に、応用問題を考えさせると、もう、固まってしまう。どのように教えたら、正規表現 を身に付けられるか、今年も何らかの工夫をこらしたいと思う。。

 まあ、最初は単純な検索や置換をして、編集作業に慣れるようにしよう。そして、単純な正規表現を使ってみよう。最初は3つ、4つの記号(たとえば、*, +, . , \n, ^, $, 繰り返しの数、など)だけを使って、いろいろな検索をしてみよう。また、()を使って、検索語句をグループ化し、それを置換でも利用してみよう。これだけができてもかなりの効率化ができるようになる。そして、できるだけ大きな文書で、置換を試してみよう。


文系がKnoppixを使う理由 [プログラム]

僕のゼミは、文学部に属している。つまり、ばりばりの文系である。普通、文系がコンピュータ技術を勉強するとしたら、大抵はできあいのソフトウェアーの使い方に習熟するか、あるいは、それを使って何か、たとえば、Webページを作ったり、画像を作ったり、表をつくったり、データベースを作ったりする。こういう使い方をする場合には、当然Knoppixが必要となることはない。

 それでは、文系がKnoppixを使う用途というのはないのだろうか。

 僕のゼミでは、単にできあいのソフトを使うのではなく、何かこれまでにない、人の役に立つツールを作るのだから、何らかのプログラミングが必要となり、また、特に現在においてツールを作るとき、インターネット上に構築するのが、楽でもあり、利用者にとっても便利である。そういうものを作るための環境を手軽に作るとすれば、Unixを使うのが一番であり、その中でも、インストールの必要のない(あるいは既にCD-ROMにインストール済みである)Knoppixを使うのがいいということになる。以前はVineLinuxを使っていたが、これはインストールだけで何回かの授業を潰してしまった。インストールもできればいいが、より本質的にUnixの勉強の方が大事なので、それは無駄な時間だった。

 しかし、僕のゼミは文系ではあるが、必ずしも一般的ではない。そこで、文系を文系の研究者に限って言えば、やはりUnixは有効の研究の道具になりうる。本当はMacOSXの方が楽だし、安定しているし、機能も豊富だ。純粋にUnixの環境があると同時に、GUIの部分は、使いやすいMacOSの伝統を継承している。コンピュータを利用した文系の研究を行うには最適だと言っていい。

 そうではあるが、現在の大学のコンピュータ環境というのは、ほぼWindows一辺倒である。Macは申し訳程度に数台置いてあるだけで、数百台のWindowsマシーン一色に染められている。その中でUnixを使うとすれば、どこでもCD-ROM一枚で、あとはUSBメモリでもあれば快適に使えるKnoppixは、学生がWindowsの代替として使うには適しているのだ。

 テキスト処理を中心として、Emacsと検索ツールとTeXとスクリプト言語、これらがあれば研究には十分な環境が構築できる。というか、僕の研究環境はこういうもので成り立っている。(ただし、Knoppixではなく、MacOSXだが。)テキストファイルを検索し、エディタで文章を書き、また検索や置換を行い、印刷はTeXで行う。TeXのソースファイルからHTMLとPDFを作って、FTPでWebサーバーにアップロードする。

 文系の研究にとって、TeXは論文やテキストを作るのに欠かせないツールだ。従来のワープロが、場当たり的なレイアウトで見た目だけの文書を作っていたのに対し、TeXでは組織的に文章を作ることができ、特殊な文字の入力やレイアウトの変更にも簡単に対応できるので、レイアウトや入力文字に関するストレスを感じることなく、内容に集中することが出来る。

 そうやって作ったテキストの様々な変換処理のためには、ほとんど使い捨てのスクリプトを使う。僕(および、ゼミの学生)は、Pythonを使っているが、PerlでもRubyでも同じである。これらもKnoppixには最新の一つ前のバージョンがインストール済みである。

 3、4年生の2年間を使うならば、必要にして十分な範囲でKnoppixを身に付けることができる。たぶん、最初の半年のトレーニングで十分だろう。その後は、余計なストレスのない環境で研究をすることができる。全員がKnoppixを使うべきだと言っているわけではない。が、特にTeXを使うならば、全部の環境をCD-ROM一枚で持ち歩けるKnoppixを使うのが一番適しているのではないだろうか。


人の役に立つものを作る [プログラム]

 昨日の文系における情報処理の補足。

 僕のゼミの基本コンセプトは「人の役に立つツールを作る」というものだ。ツールを作るときのプラットホームをUnixにしているが、それはもちろん本質的なものではない。ほぼ同じ環境をWindows上でも実現できるから。Unixは単に技術の勉強のためのテーマにすぎない。

 何が人の役に立つのか、あるいはどうしたら人の役に立つのか、これを考えるのは結構難しい。それなりの経験や観察力、想像力を必要とする。

 「人の役に立つもの」を考えるには、人が困っていることを見つけることから始める必要がある。困っていること、不便だと思っていること、こうなったらいいな、と思っていること。しかもそれが、自分がそう思っているのではなく、他の人が思っているのを発見する、気付くことだ。それだけ、いろいろな人の様子に目を配る必要が出てくる。

 これは社会に出ても必要な態度だと思う。資本主義社会は確かに「人の役に立つもの」よりも「儲かるもの」を作る、という方向に向かいがちである。どうしたら儲けられるか、売り上げを増やせるか、を真っ先に考える。おそらく、成長しない会社はそうだろう。しかし、役に立たないものを作れば、人はそれを買わなくなり、結局は売り上げは落ちる。人々が欲しいと思うものは、それがあることでとても便利になるようなものだ。

 だが、僕が言いたいのは、もっと困っている人のことだ。儲かるようなものならば、誰かが作ってくれる。しかし、儲からないようなものはどうなるのか。たとえ、それが必要で、なくて困っていても、それを必要とするのが10人とか20人しかいなかったら、あるいは100人でもいい。それを誰が作ってくれるだろうか。

 世の中は経済原理によって成り立っている。だから、儲からないものには、あるいは相当の人が必要としないものは、たいてい見向きもされない。そういったものに取り組むのが、僕の言う「人の役に立つツールを作る」ということなのだ。

 そういう小数の人たちは、実は自分たちの必要ものを作ってもらえるとは思っていない。半ば諦めている。だから、それが必要だという声も上げない。それを発掘し、彼らに変わって何が必要なのかを考え、場合によっては、それを必要としている人の考えている以上のものを実現できたら、それは素晴らしいことだろう。

 逆に言うと、誰も作ってくれないからこそ、自分たちが作らなければ、ということだ。

 こういう目や視点を養っておくと、社会はそういうふうには動いていなくても、きっとその人の人格のスケールアップにつながると思う。


C・Pascal→Perl→Ruby→Python→Scheme [プログラム]

 これは僕が普段使うプログラミング言語の変遷である。と言っても、きちんと分かれているわけではなく、現在は実用的なものにはPythonを使い、趣味でSchemeを勉強している。

 何かプログラミング言語について意見を書く場合には、このような変遷をしてきた経験からものを言うことになる。それは経験に基づく言葉、と肯定的に捉えることもできるが、その人の偶然の経験に縛られた特殊な意見、と否定的に捉えることもできる。そのどちらであるかは、僕には分からない。

 それでは、何故、あるいはどういうきっかけで、言語を変えてきたのか。

 最初、まだMS-DOSの時代、そもそも、Unix起源のスクリプト言語を動かすのは、かなり大変だった。いろいろ工夫をしなければならなかったし、今のように参考書もたくさんは出版されていなかった。いきおい、プログラミングと言えば、コンパイル型、特にCかPascalかBasicだった。(もちろん、アセンブラもあったが。)

 僕は職業プログラマでもなく、またコンピュータ科学者でもなかったので、自分の仕事や研究に役に立つようなプログラムしか作るつもりはなかったし、そういうことに必要な知識しか身に付けてもこなかった。一言で言えば、テキスト処理がほとんどのテーマだった。グラフィカルな処理やゲームのようなリアルタイムの処理、科学的な計算などは何一つ作ったことはない。

 いつも必要に迫られプログラムを作っていたし、その必要も、個人的な必要性だったので、プログラムは公開されるような品質のものではなく、とにかく目の前の仕事を楽にするためのツールとして作っていた。当時も、CのコンパイラはMicrosoftかBorland(当時は別の名前だったかも知れない。要するにTurboCだ。)、あるいは日本のLSI-Cなど多様なものが製品としてしのぎを削っていたので、使いづらいPerlを使おうとは思わなかった。それに非力な機械でも、Cで書けばそうとうに高速に動いてくれた。

 その後、Macintoshに移ってからも、CodeWarriorという使いやすい統合環境を備えたCを使ってテキスト処理のプログラムをしていた。

 始めて公開するようなプログラムを作ったのは、ローマナイズされたチベット語のテキストを、Macintosh上のチベット語システムのコードに変換するソフトだった。TibetanConverterという。これは、単にテキスト処理の部分だけではなく、Macintoshのプログラムとしての必要な要素を備えていた。つまり、AppleEvent対応とか、ダイアログによる環境設定の処理とか、プログラム全体も、コマンドラインとしてではなく、グラフィカルなユーザーインターフェースで動くようなイベント・ドリブンなプログラムだった。

 そういう部分と、チベット文字コードの変換エンジン部分は別に切り離され、特にその変換エンジンの部分のコードはかなり複雑なものとなった。

 このプログラムは極めて高速に動いた。1M以上のテキストを1、2秒で変換してしまった。さすがにCである。

 しかし、その変換処理は余りにも複雑なので、細かい手直しをするのは非常に骨が折れた。今だったら、YaccとかLexとかを使って書いていただろう。(「いただろう」という過去形ではなく、時間があれば、そうしたいと今でも思っている。)

 その後、今度はTeXでチベット文字を表示したいと考え、ローマナイズしたチベット語テキストやチベット文字のテキストをTeX用の文字コマンドに変換するプログラムを公開した。これを作るとき、今後のバージョンアップなども含めてメンテナンスがしやすいように、そして、前の経験から、Cでテキスト処理を書くのが極めて大変だということもあり、Perlの正規表現を多用したスクリプトで作った。他に、もちろん、TeXのコマンドも作り、フォントもポストスクリプトフォントをTeX用に変換したり、と複数のファイルからなるパッケージとして公開している。

 正規表現で実現しようと思ったのは、実は、オライリから出ている、あの有名な『詳説 正規表現』という本を読んだことがきっかけになっている。この正規表現の威力は素晴らしく、コード量はCで書いたときと比べて劇的に減ってしまった。確かにスピードは若干遅いかもしれないが、30秒もかかることはない程度だったので、十分実用になった。もはや、こういうテキスト処理をCで書く気にはならなくなった。

 その後、Rubyがおもしろくなって、目録検索のCGIはRubyで書いているし、授業で教育言語としてPythonを使うようになってからは(最初はRubyを教えていたが、あの純粋オブジェクト指向やイテレータの概念はやはり初心者には難しい)、自分で書くものもPythonにしている。現在、模索している日本語スクリプト言語wythonも、Pythonで書いている。Pythonのどこがいいか、ということについては、また別の機会に書くことにしよう。ただし、僕はPythonに満足しているわけではない。PythonはPerlほどではないが、余りきれいな言語ではないと感じられる。

 そして、今はLispの一方言であるSchemeとか、XSLTとかに興味を持っている。特にSchemeは極めてシンプルで、しかも文法がきれいで、作るのがおもしろい言語だ。まだこれで実用的なプログラムを作ってはいないし、大きなものも作れないかもしれないが、趣味の楽しさは十分味わえる。ただ、余りにも特殊なので、これを授業で取り上げることができないのが、玉に瑕である。


EmacsのYaTeXからAcrobat Readerを呼び出すコマンド [プログラム]

 Knoppixのカスタマイズをいろいろやっている。特にEmacsの環境整備をしている。KnoppixはCD-ROMに焼いてしまうので、後からの追加が容易ではない。最初にできるだけ、作り込んでおかないといけない。

 今でも普通僕はTeXやPython、Cなどを書くときにEmacsを使用しているが、必ずしも快適な段階までカスタマイズして使っているわけではない。そうしなくても十分使いやすく高機能なのだが、様々な演習で使うとなると、いろいろと便利な機能を組み込んだり、細かいカスタマイズをしたりする必要が出てくる。

 さらに、そのカスタマイズをする環境が、起動しているKnoppixとは別のシステムとして作らなければならず、しかも起動しているKnoppixはCD-ROMで動いているので、データの保存もままならない、という訳で大変なのだ。

 今日は、Emacs上でTeXを使いやすくする環境であるYaTeXに対して、コンパイルしたdviファイルから作ったpdfファイルを、Acrobat Readerを起動して表示するコマンドを作った。

(defun call-acrobat ()
   "Call Acrobat Reader with a pdf file made from the tex file of current buffer"
   (interactive)
   (let ((filename (concat (file-name-sans-extension (buffer-name)) ".pdf")))
         (if (file-exists-p filename) 
              (call-process "acroread" nil nil nil filename)
              (message "Cannot file pdf file"))))

(setq yatex-mode-load-hook
     '(lambda() (YaTeX-define-key "p" 'call-acrobat)))

これは、今編集しているバッファの名前から拡張子を取り去り、それに.pdfという拡張子を付け、その名前でAcrobat Readerを呼び出す機能を、YaTeXのキーとして定義している。コントロール-C, pで、現在編集中のファイルのPDF書類がAcrobat Readerで読めるわけだ。まあ、胸張って公開出来るようなものではないが、最近はこんなことをしている、という報告までに、公開しておこう。


Javaを使ったオブジェクト指向のてほどき [プログラム]

 この4月からの演習の中で、プログラミング演習1, 2では、スクリプト言語を学ぶことになっている。以前、Rubyを取り上げたこともあったが、その後はずっとPythonを使った演習にしている。

 Pythonは文法規則が少なく、また非常に整った形式で書ける。定石などに余り頼らず、非常に素直な書き方でプログラムを組んでいくことができるので、初歩の教育用言語としては最適なものだと思う。

 しかし、それでもこれまでの経験で、変数や代入、文字列リテラルや繰り返しなど、プログラミングの最も基本的な概念が十分に理解できない学生がいた。またこれらが、それ自体としては理解できても、具体的な問題を解く段になるとどうしたらいいか分からない学生も多かった。

 そこで今年は、そういうプログラムの初歩的な概念について、くどいまでに丁寧に説明している結城浩の『Java言語プログラム・レッスン』を使ってみることにした。これを予習中心に読ませ、授業では実際にコーディングしたり、それをPythonで書き直したりし、さらに基本的なプログラムは暗譜する課題を出す。

 いずれもこれまで何度か書いてきた感想に副った方針だ。

 さらに、結城本を使うことで期せずして別のメリットが生まれた。この本の下巻はJava言語のオブジェクト指向についての、これまた丁寧な解説になっている。これまで、上に述べたようなプログラミングの初歩的な部分に躓いていたので、Rubyにせよ、Pythonにせよ、元々オブジェクト指向の言語ではあるが、その点については一切触れずに来た。しかし、結城本でJavaのオブジェクト指向の側面を勉強することで、それがPythonでどのように書かれるかを説明することもできるようになるだろう。

 オブジェクト指向自体は、自分でプログラミングするときにそれほど必要性があるわけではないが、既に提供されているライブラリのインターネット関連のものには、オブジェクト指向で書かれているものがかなりある。もともと純粋なオブジェクト指向言語であるRubyはともかくとして、PerlでもPythonでも、最近のものはみなオブジェクト指向で書かれている。これらを効率的に使うためには、オブジェクト指向の知識ないしは感覚が必要である。そのことの手ほどきができるのは、思わぬ効果である。

 ただし、wythonではそこまでカバーすることは難しいので、これは非オブジェクト指向の部分のみに限定した言語にしておきたいと思う。


Unix的プログラミングとカーニハン先生(3) [プログラム]

4.
プログラミング作法

『プログラミング作法』(カーニハン、パイク共著、福崎俊博訳)ASCII、2000年 (原書: The Practice of Programming, 1999)

カーニハンが、以前『Unixプログラミング環境』でも共同執筆していたパイクとともに、そのプログラミング技術論をアップデートして書いたテキストである。しかし、これまでのものが、どちらかというと初歩(といっても、本当の初歩ではなく、既にその言語を身に付けた人がステップアップするためのものだったが、)の人のための教科書という書き方で、簡単なところから徐々に高度なところへと組織的に学べるような本であったのに対し、この本は中級から上級者向けのプログラミングのティップス集という感じで、いろいろなトピックスについてのアドバイスを集大成したようなものだ。

 もちろん、その内容というか、書き方はこれまでの本と同様に、それぞれの話題についてまとまったプログラムを徐々に作り上げながら、そこに現れる問題点を指摘していく、というスタイルであり、やはり読んでいて、おもしろい。

 言語はC言語を種にしているが、しかし、昔と違って現在はプログラミング言語に様々な選択肢があることを反映して、同じ題材について、C言語以外にJavaやPerlも使って比較している箇所がある。

 最後には、プログラミングするときにどういう点に気を付けるべきかを「ルール集」という形でまとめている。それだけを見ていると、ある意味では当たり前だったり、あるいはそんな細かいところまで覚えきれないよ、という気がしてくるが、本書全体が、そのルールの具体的な例を通じての説明になっているのである。

 まあ、この本は、そうとうプログラミングの経験があり、しかも、現実の仕事で壁にぶつかっているような人がもっとも役に立つようなものなので、普通の我々のように、プログラミングを勉強しています、という人が読むには、高度すぎるようだ。ただ、お守り替わりに座右に揃えておいてもいいかもしれない。


Unix的プログラミングとカーニハン先生(2) [プログラム]

昨日の続き。本当は一回で紹介しようと思ったのだが、ちょっと長くなったので、分割することに。

2.
プログラミング言語C ANSI規格準拠

『プログラミング言語C』(カーニハン、リッチー共著、石田晴久訳)共立出版、初版1981年、第二版1989年 (原題: Progamming Language C, 1st ed. 1978, 2nd ed. 1988)

 これは、C言語の作成者リッチーとの共著で、初版はC言語の教科書であり仕様書でもあった。その後、C言語がANSI規格として策定されたに対応して、第2版が出版された。この時点では他にもたくさんのC言語の教科書が出てきて、以前に比べてこの本で勉強する人は少なくなってきたかもしれない。しかし、著者名の頭文字をとってK&Rという名称で呼ばれる本書は、未だにC言語のバイブル的存在と位置付けられる。

 前回も書いたように、この本の例題や練習問題の題材は、単にC言語の個々の文法を説明するための単純なものではなく、むしろ、Unixのコマンドの基本的なものを作るようなものが多い。『ソフトウェアー作法』でFortranで書かれていたものをC言語で書き直した、という感じである。そのため、問題を解いていても、非常におもしろい。逆に言うと、説明よりも、この例題と問題を自分で作ってみなければ、この本の価値は半減する。

 たとえば、関数の説明をする章では、簡易電卓を作る例題が取り上げられている。もちろん、全体をどのように分割し、それをどのように関数に分けるか、ということを説明しながら、徐々に作ってみせるのである。こういうところは、カーニハンの真骨頂である。

 だから、練習問題を解いていても楽しい。楽しみながら勉強ができるし、結構高度なツールのプログラムを実際に体験できる、という意味でも良い本である。

3. 『Unixプログラミング環境』(カーニハン、パイク共著、石田晴久監訳)アスキー出版社、1985年(原著: Unix Programming Environment, 1984)

 Unixは、アメリカの電話公社であったAT&Tのベル研究所で、ケン・トンプソンと、C言語の創始者デニス・リッチーとによって作られものであり、C言語自体がUnixを実装するための言語として開発された、という経緯を有する。

 この本では、もう一方のUnixについての、ごく初期の総合的な教科書である。今となっては、そのUnixの使い方の部分は古く、他に良書があるので、この本でUnixを勉強する必要はないが、しかし、後半はシェルから始まり、C言語を使ったプログラミングの教則本になっており、この部分は、やはり非常におもしろい。

 例によって、単純な文法の説明のための例題ではなく、たとえば、Unixに備え付けのカレンダ表示コマンドcalを、最初awkというツールで、次にはシェル・スクリプトでどのように使いやすくカスタマイズできるかを、やってみせる。

 またC言語については、コンパイラ支援のUnixツールyacc、lex、そして、プログラミング一般の支援ツールmakeの使い方を説明しながら、例題としてBASICのサブセットのようなプログラミング言語hocを作ってみせる。しかも、最初は四則演算だけができるバージョン、変数が使えるバージョン、制御構造を組み込んだバージョンという具合に、徐々に拡張していく。これが、非常に勉強になる。

 この本ではパイクという人と共著になっているが、この人とは、最新刊の『プログラミング作法』(似たタイトルの本だ)でも、一緒に書いている。カーニハン先生は、誰かと共同で執筆するのが好きらしい。

 本当は、1977年に『プログラミング言語AWK』という本を、これも共著で書いている。AWKは有名なUnixのツールで、Perlが出来る前に、テキスト処理を簡単にプログラムするためのスクリプト言語として開発された。名前は、その言語の作者三人、Aho、Weinberger、Kernighanの頭文字に因んで付けられたものだ。この本も、おもしろかった記憶はあるが、今、手元にないので、後日に説明を追加しよう。

 最新の『プログラミング作法』については、また明日。


この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。