言語設計者たちが考えること

プログラミングは創造性を発揮できる創作活動の1つです。機能を実現したり、決められた仕様通りに出力すること自体は単なるお仕事の作業でしかありません。しかし、要件を満たすためにどう設計、抽象化してメンテナンスし易く拡張性の高い仕組みに創り上げるか、そこに楽しさやおもしろさを見出せるかでプログラマという職業の幸せ感が違ってくるように私は思います。

本書はプログラミング言語の設計者たちがどういう哲学をもって設計したかをインタビュー形式で紹介しています。先人の知恵というか、設計において何を重要視して最終的な成果物はどうなったか、そういったものを知ることそのものが私は興味深かったりします。自分が使ったことのある以下の言語の章だけ読んでみました。

Python(Guido van Rossum 氏)
AWK(Alfred Aho 氏, Peter Weinberger 氏, Brian Kernighan 氏)
SQL(Don Chamberlin 氏)
Ruby(まつもとゆきひろ氏)

この4つの章の中で私が一番興味深かったのは AWK の三巨人のインタビューです(^ ^;;
3人いるのでページ数も60ページ近くあります。偉大な先人であり、歴史を踏まえた上での今の振り返りには説得力と重みを感じ、それでいて未来への普遍的なキーワードも見え隠れします。コンピュータサイエンスへの入り口として読むとおもしろい気がします。AWK の章を紹介していると、量が多くなってブログを書く意欲がなくなりそうな気がしたので本書を購入して読んでください(> <)。

ということで、やはり Python の章だけを紹介します。個人的に興味深かった受け答えについて、質問と回答を引用、要約して紹介します。Guido のインタビューは20ページ程度あり、他にも興味深いやり取りがたくさんあり、実際の回答ももっと詳細に答えています。

Python(Guido van Rossum 氏)

ある機能を拡張機能としてライブラリに格納するか、言語の核となる機能としてサポートするかは、どのようにして決めるのでしょうか？

Guido は基本的に先ず「ノー」と言う。先ずは Python のライブラリで作ってみたら？が第一次防衛線。Python だけで実現することが難しいなら次に C 言語の拡張機能とするように示唆、推奨するのが第二次防衛線。C 言語の拡張機能でも無理で便利そうな機能だったら言語への拡張となるようです。先ず「ノー」と言って相手が諦めるか、自ら解決できるかどうかが驚くほど効果を発揮するというのがおもしろいです。単純に「ノー」と主張する以上に深い意味を持っているようです。

制約は創造性を加速するといった働きかなぁ。

「間違えようのないやり方が一つだけあるのがいいね」という哲学はどのような経緯で採用されたのでしょうか？

Guido 自身の潜在意識にあったものの明言してくれたのは Tim Peters 氏の Zen of Python だと答えています*1。Pythonic という言葉も多用するものの、定義がきっちりなくて、直感以外の何者でもないとも答えています。PEP や公式サイトやメーリングリスト等も Guido 自身はあまりそういった開発体制やプロセスには注意を向けていなくて、周りのコアデベロッパーが提案してくれて、今のような体制に落ち着いたようです。Python の特徴の1つである wikipedia:直交性_(情報科学) やインデントブロックも ABC という言語から大きな影響を受けています*2。インデントブロックを採用した理由が C 言語開発者で行われる中括弧をどこに書くかという不毛な議論を解消できると考えたからという理由も1つにあったようです。

まぁ、、、バランスですかね。

マルチパラダイムをサポートしたのは何故ですか？

Python は手続き型のプログラミング言語であり、その手続きのスタイルがオブジェクトから強い影響を受けているので、ある意味、オブジェクト指向なのだと説明されています。関数プログラミングも少しだけサポートしているけど、実際の関数型言語とは似ても似つかないものであり、今後もそうあり続けると明言しています。関数が wikipedia:第一級オブジェクト (ファーストクラスオブジェクト) である点と Lisp 的なアプローチを取っている仕組みがあるので関数型言語のコンセプトのいくつかを容易に実装できているだけだと答えています。Python で開発する際の基本的なコンセプトに対する質問の回答においても「実践主義」を唱えて、データ隠蔽や抽象化といった理論的なコンセプトにこだわりすぎない方が楽しくプログラミングできるよと言っています。

ここでも Python の汎用言語としてのバランスなのかなぁ。

優れた Python プログラマを見つけ出す際の基本的な評価項目はありますか？

質問自体が間違っていて、Python プログラマを雇用するのではなく、スマートで創造的且つ自主的な人を雇用するべきと、ばっさり斬り捨てているのがおもしろいです。1時間の面接で見極めるのは大変なので、一緒に行動を共にして、その人の得意分野や優劣を見極めるそうです。

言語は関係なくて、プログラミングができる人はできるんだということが分かります。

並行性にはどう取り組むべきなのでしょうか？どういったレベルでこの問題と取り組むのか、また願わくばどうすれば解決できるのでしょうか？

今の、そしてこれからも流行りの話題ですね。Guido 自身は、マルチスレッドのコードは実装するのが難しいので粒度の細かい同期プリミティブや共有メモリではなく、メッセージパッシングが解決策、CPython から GIL を削除しようとする試みもうまくいくとは思っていないようです。そして、スレッドよりもマルチプロセスという、プロセス管理のサポートを行うのが鍵になると考えているようです。Python 2.6, 3.0 で入った multiprocessing をお奨めしています。

Python の創出、開発、普及における教訓は、今日の、そして未来のコンピュータシステム開発者にどういったことを伝えるのでしょうか？

この回答は示唆に富みます。ABC が採らず Python が採用した仕組みの1つに、ユーザによって2つ(以上)のレベルで機能拡張できるようにしたことであり、それが普及の差に表れたと考えているようです。この2つのレベルというのは Python で書くライブラリモジュールと C 言語の拡張モジュールの2つを指しています。この C 言語で拡張モジュールを開発する仕組みがなければ、言語自体の変更が必要なときに高度な判断基準が必要になったり、自らのニーズを満たすために言語の実装に手を入れたコピーが流通して互換性やメンテナンスの問題が発生したかもしれないと答えています。

自分でライブラリやフレームワークを開発するときのヒントになりそうですね。