\documentclass{howto}

\title{Python Advocacy HOWTO}

\release{0.03}

\author{A.M. Kuchling}
\authoraddress{\email{amk@amk.ca}}

\begin{document}
\maketitle

\begin{abstract}
\noindent
オープンソースソフトウェアの使用を、経営者に認めてもらうのは難しいもので、Python も例外ではない。この文書では Python を使う理由、受け入れてもらうための戦略、説得に使える事実と論拠、Python を使う\emph{べきでない}場合について検討した。

最新版は Python HOWTO のページ \url{http://www.python.org/doc/howto} で入手できる。

\end{abstract}

\tableofcontents

\section{Python を使う理由}

開発プロセスに、スクリプト言語を取り込むのには理由がある。この章ではその理由と、Python を特に良い選択たらしめる、いくつかの特徴を検討する。

 \subsection{プログラム可能性}

プログラムは、モジュール化して構成することがよくある。低レベルの処理をまとめておいて、高レベルの関数から呼び出す。高レベルの関数は、さらに高レベルの関数に使われる。

たとえば、最も下位レベルでは、ハッシュテーブルにアクセスするための非常に低レベルな機能群を定義するとしよう。次のレベルでは、ハッシュテーブルを使って、電子メールのヘッダを保持するために、ヘッダ名 \samp{Date} に、\samp{Tue, 13 May 1997 20:00:54 -0400} という値をマッピングする。更に上のレベルでは、メッセージヘッダがハッシュテーブルに保持されていることを知らずに、または気にせずに、メッセージオブジェクトを操作する、という具合に。

多くの場合、最下位レベルでは、二分木やハッシュテーブルのようなデータ構造の実装や、文字列から数値への変換のような単純な計算など、非常に簡単なことを行う。高レベルのモジュールは、そういう原始的な処理をつなげるロジックを含んでいる。このアプローチでは、原始的なモジュールを基本的なブロックとして扱い、つなぎ合わせることで、完全な製品を作ると考えることができる。

この設計アプローチが、なぜ Python に適しているかっていうと、Python が糊言語として機能することに向いているから。一般的なアプローチは、下位レベルの処理を実装するような Python モジュールを書くことだ。処理速度が必要であれば C 、Java あるいは Fortran で実装することになるだろう。基本的な部分が Python のプログラムから使えるようにしておけば、高レベル処理のロジックは Python のコードの形で書くことができる。これで、高レベルの処理が、理解しやすく変更が容易になるというわけ。

John Ousterhout は、このアイディアを「Scripting: Higher Level Programming for the 21st Century」という長い論文で発表した。参考文献リストに URL を載せてあるので、読んでみることをオススメする。Ousterhout は Tcl の開発者なので、この目的で Tcl を使うべきだと主張している。Python、Perl、Lisp/Schime など他の言語には、簡単に触れるだけなんだけど、他の言語にも拡張できる話なので、スクリプト言語一般に適用できる。

 \subsection{プロトタイプ}

Fredrick Brooks は\emph{人月の神話}の中で、ソフトウェアのプロジェクトを計画する時には、次のルールに従うことを提案している -- 「ひとつは破棄するつもりでいろ。どうせ捨てることになる。」 
Brooks は、ソフトウェアの設計における最初の試みは、多くの場合、間違った結果になると言っている。
プログラムが凄く単純か、著しく良いプログラマでない限り、開発が実際に始まってから、新しい要求や機能が明らかになるもんだ。
新しい要求を、プログラムの構造の中にすんなり取り込めない場合、嬉しくない究極の選択を迫られる -- 新しい機能を強引に叩き込むか、全部捨ててしまって新しい機能を考慮した上で、新しいバージョンのプログラムをはじめから書き直すか。

Python を使えば、最初のプロトタイプを、素早く開発するのに適した環境が手に入る。
これにより、全体的なプログラムの構造とロジックを正しく把握することができて、Python が提供する速い開発サイクルの中で、細部をきちんと調整できるというわけ。
一旦、GUI やプログラムの出力に満足したら、Python のコードを C++、Fortran、Java、あるいは他のコンパイルする言語に書き直せばいい。

プロトタイプの段階では、Python の機能を使いすぎて、他の言語で実装するのが困難になってしまった、ということのないように注意しよう。
たとえば \code{eval()}、正規表現、あるいは \module{pickle} モジュールを使って書いたら、C や Java に書き直すときに、式評価、正規表現、あるいは、シリアライゼーション用のライブラリが必要になることになる。
実際のところ、そういうトリッキーなコードを避けることは難しくないので、書き換えも難しくない。
それに、できあがったコードは素早くデバッグできる。深刻なロジックのエラーはプロトタイプの段階で取り除かれていて、書き換え後のコードでは、あまり重要でない間違いを潰すだけでいいから。

この戦略は、プログラム可能性の最初の方でも書いたとおり。
Python を、低レベルの部品をくっつける糊として使うことには、プロトタイプ・システムを構築する上で、明らかな有用性がある。
この方法なら、エンドユーザが Python コードに触れることがなくても、Python が開発を支援できる。
Python で書いたコードのパフォーマンスが十分で、組織の方針が許すなら C や Java に書き換える必要もない。
いずれにしても、プロトタイプを開発してから書き換える方が、いきなり最終版を作ろうとするより早く仕上がるんだ。

この開発戦略の例として Microsoft Merchant Server を挙げておこう。
バージョン 1.0 は、後に Microsoft に買収された企業が、全て Python で書いた。
Version 2.0 は、\Cpp への書き換えを開始し、\Cpp と Python のコードが混ざって出荷されることになった。
Version 3.0 には、まったく Python コードが含まれていない。全てのコードが \Cpp に書き換えられたのだ。
この製品には Python インタプリタが含まれないけれど、開発のスピードを上げるという目的で Python が役に立っている。

これは、とても一般的な Python の使用方法だ。
古い学会論文でも、高レベルな数値計算アルゴリズムにおいて、このアプローチを使った実績が紹介されている。参考文献の David M. Beazley と Peter S. Lomdahl の論文 「Feeding a Large-scale Physics Application to Python」も良い例なので読んでみて欲しい。
あるアルゴリズムの基本的な操作が「4000行4000列の行列の逆行列を計算する」みたいなもので、低レベル言語で実装されている場合、 Python には追加のパフォーマンスコストが、ほとんどない。--  \code{m.invert()} のような式を評価するのに Python に必要な時間は、実際に計算するコスト程度だ。
これは、きちんと動かすのに、継続的に調整が必要なアプリケーションにとって、特によいことだね。GUI インターフェイスやウェブサイトなんかがそう。

Python のコードは、（一旦 Python に慣れたら）短く速く書けるので、自分のアプローチがダメだと思ったら、簡単に捨てられる --  2 時間ではなく、2 週間かけて取り組んだ場合、その2週間が無駄だったことを認めるのは不本意だよね。パッチをあてるという時間の浪費に走るかも知れない。
本当は、問題解決に必要な技術について、何か学んだんだから、2週間は無駄じゃなかった。でも、これを失敗だと思ってしまうのが人間の性というもの。

\subsection{簡潔さと理解しやすさ}

Python は、小さな作業にしか使えないような、おもちゃ言語では\emph{ない}。
Python は汎用的で強力で、様々な目的に使える。
小さい側の末端である 10 行や 20 行程度のスクリプトにも便利だけど、何千行ものコードを含む、大きなシステムにも有効なのだ。

この豊かな表現力があるからといって、不明瞭な、あるいは、扱いにくい文法などの代償もない。
Python にも読みにくいコードを生み出すような、見通しの悪い部分がある。でも、そういう部分は比較的少なくて、適切に設計すれば、読みにくいコードをクラスやモジュールの中に隔離することができる。
もちろん、分かりやすいコードを書く努力をせずに、色んな機能を使いまくれば、こんがらがったコードを書くことも可能だ。けど Python で書いたコードは、少し形式ばった、人間にとって可読な擬似コードのように見えることが多い。

\emph{The New Hacker's Dictionary} の中で、Eric S. Raymond は「compact」を次のように定義している。

\begin{quotation}
Compact （\emph{形容詞}）  設計において、価値ある性質を、一度で頭の中で理解されるように表現されている様子。一般に compact な設計から作られた物を使うとき、compact でない等価なツールに比べて、多くの機能と少ないエラーがあることを意味する。compactであることは、些細であるとかパワー不足であることではない。 -- たとえば、C は compact だが、 FORTRAN はそうではない。しかし C は FORTRAN より強力である。設計過程で、全体的な設計計画に、きれいに融合しないような機能や無駄なことを増大させると compact ではなくなる（したがって、昔の C を支持する者の中には、ANSI C はもはや compact ではないと主張する者もいる）。
\end{quotation}

(\url{http://sagan.earthspace.net/jargon/jargon_18.html\#SEC25} より)

この意味で Python は、なかなか compact だ。
この言語には、多くの場所で使われる、ごく少数のアイディアがあるだけだから。
たとえば名前空間を例にとってみよう。
\code{import math} でモジュールをインポートすると、新しい名前空間 \samp{math} が作られる。
クラスも名前空間で、モジュールと同じような性質を共有していて、いくつかの独自の機能もある-- たとえば、クラスのインスタンスを作るとか。
インスタンスとは何だろう？
これもまた名前空間だ。
今のところ、名前空間は Python の辞書で実装されているから、標準の辞書型と同じメソッドを持っている。 -- だから .keys() で全てのキーを受け取ることができる。

この簡潔さは、Python 開発の歴史に起因する。
言語の文法は、異なった言語から派生してきた -- ちょっと分かりにくい教育用言語 ABC と、Modula-3 から、特に大きな影響を受けていて（ABC と Modula-3 の詳細は、それぞれのウェブサイト \url{http://www.cwi.nl/~steven/abc/} と \url{http://www.m3.org} を参照のこと）、他にも C、Icon、Algol-68、Perl から頂いて機能がある。Python はそれほど革新的ではないけれど、他の言語で既に試され、便利だと分かっているアイディアを積み重ねながら、小さくて習得が容易な言語であるよう保たれてきたのだ。

簡潔さは、過小評価してはならない美徳だ。
その言語をより素早く学び、迅速にコード -- 多くの場合、最初の実行で動くようなコード -- を書けるんだから。

\subsection{Java との統合}

Java を使って仕事をしているなら Jython (\url{http://www.jython.org/}) は、確実に注目するに値する選択だろう。
これは Java による Python の再実装で、Python で書いたソースコードを Java のバイトコードにコンパイルする。この環境は、Java との親和性が非常に高くて、ほとんどシームレスに統合できる。
Python から Java のクラスに簡単にアクセスできるし、Java のクラスを継承した Python のクラスを書くこともできる。
Jython は CPython と同じような方法で、 Java アプリケーションのプロトタイプ作成に使うことができる上、Java のコードのテスト・スイートに使ったり、 Java アプリケーションに組み込んで、スクリプト機能を追加したりすることだってできる。

\section{議論と反駁}

Python が、自分のアプリケーションにとって最高の選択であると結論づけたしよう。
どうすれば、経営陣や同僚の開発者に Python を使うように説得することができるだろう。
この章では Python を使うことに対抗する一般的な論拠を挙げ、使えそうな反駁を伝授する。

\emph{Python ってタダで手に入るソフトだろ。そんなものが、まともに使えるのか？}

もちろん、使える。
最近は、 オープンソースソフトウェアである Linux と Apache が、商用ソフトウェアの代替品として尊敬されているけれど、Python はそれほど一般に知られていない。

Python が出てきて何年も経って、今ではたくさんのユーザと開発者がいる。
だから、Python インタプリタは多くの人々に使われてきたし、ほとんどのバグが潰されている。
今でも、ときどき、バグが見つかるけれど、一般に非常に目に付きにくい (誰も以前にその機能を使っていないんだから) か、外部ライブラリへのインターフェイスが絡んでいるかの、どちらか。
言語本体の内部コードは非常に安定しいる。

ソースコードがあるということは、そのソフトウェアがピアレビューできるということだ-- 誰でもコードをテストしたり、 改善を提案 (そして実装) したり、バグを潰したりできる。
オープンソースのアイデアについて、議論とそれをサポートするケーススタディは \url{http://www.opensource.org} をご覧あれ。

\emph{誰がサポートしてくれんだよ？}

Python には、非常に大きな開発者コミュニティがあって、成長し続けている。
この言語を取り巻くインターネットコミュニティの活発さは、長所のひとつと言っていいだろう。
ニュースグループ comp.lang.python で質問すれば、多くの場合、すぐに誰かが答えてくれる。

必要に迫られて Python のソースコードを読めば、コードが分かりやすく、きれいに、まとまっているので、拡張したり自分でバグ取りをしたりすることが、それほど難しくないことが分かるはずだ。
もし、対価を払うサポートがいいなら、Python の商用サポートを提供する企業や個人も存在する。

\emph{Python を、まともな仕事に使ってる奴なんているのか？}

たくさんの人々が、そういう目的で使っている。
Python の面白いところは、アプリケーションが驚くほどの多様であることだ。Python は次のようなことに使われている。

\begin{itemize}
\item ウェブサイトの運営
\item CGI
\item スーパーコンピュータ上で、大量のデータ処理を行うコードの制御
\item Python インタプリタを内部に組み込んだ、スクリプト可能な商用アプリケーション
\item 巨大な XML データ群の処理
\item C や Java で書いたコードのテストスイート
\end{itemize}

アプリケーションのドメインが何であれ、おそらく似たようなことに Python を使った人がいるだろう。
しかし、そのようなハイエンドなアプリケーションに使うことができる一方で、小さな仕事に使うのに適した程度にシンプルなのだ。

Python を使っている組織のリストは \url{http://www.python.org/psa/Users.html} を参照のこと。

\emph{Python を使うのに、制限があるんでしょ？}

事実上、そのようなものは存在しない。
詳細は、ソース配布に含まれる \file{Misc/COPYRIGHT} ファイルか\url{http://www.python.org/doc/Copyright.html} を読めばいいんだけど、次に3点に要約できる。

\begin{itemize}
\item ソフトウェアの著作権表示を残すこと-- もし製品にソースコードを含めない場合、著作権表示を説明書の中に入れなくてはいけない。
\item  Python を開発した組織に対して、いかなる形であれ、あなたの製品に対する保証を請求してはならない。
\item もし何か間違いが起こっても、損害に関する訴訟を起こすことはできない。事実上、全てのソフトウェアライセンスは、この条件を含んでいます。
\end{itemize}

Python を含んでいたり、Python と一緒にビルドしたソフトを配布するとき、ソースコードを提供しなくてもかまわない。
また Python インタプリタと、付属のドキュメントは、どのような方法であれ、修正および再配布してもかまわないし、ライセンス料を誰かに支払う必要もない。

\emph{どうして、よく知られた言語 X ではなく、誰も使っていない Python みたいな言語を使うのか？}

この HOWTO 文書と参考文献を読めば、Python は知られていないわけではなく、健康的に成長しているユーザベースがあることに、同意してもらえるだろう。
ひとことアドバイス -- 言語 X の短所ばかり話さず、Python の長所を話すこと。
人は、なぜ解決法が良いのかを知りたいのであって、なぜ他の解決法がダメなのかを知りたいんじゃない。
競合する解決策を様々な論拠で攻撃するのではなく、Python の長所がどのように便利なのか教えてあげよう。

%\section{Useful Resources}
\section{有用な情報源}

\begin{definitions}

\term{\url{http://www.fsbassociates.com/books/pythonchpt1.htm}}

\emph{Internet Programming with Python} の第1章は Python を使ういくつかの理由を検証している。この本は買う価値のある本なのに、出版社は第1章をウェブで公開してくれたのだ。

\term{\url{http://home.pacbell.net/ouster/scripting.html}}

John Ousterhout のスクリプティングに関する白書は、スクリプティング言語の有用性に関するよい議論です。当然、彼は自分が開発した言語である Tcl を強調していますが。ほとんどの議論は、どんなスクリプティング言語にも当てはまります。

\term{\url{http://www.python.org/workshops/1997-10/proceedings/beazley.html}}

著者である David M. Beazley と Peter S. Lomdahl が、ロスアラモス国立研究所での、Python 利用について述べたもので、
Python がどのように実際の仕事の助けになるかを示す好例。
この文書は、何度も引用されている。

\begin{quotation}
元々、Python を使って、大規模並列処理システム用に巨大な一枚岩のアプリケーションとして開発していたのだが、シミュレーション、データ解析、可視化の用途のアプリケーションを柔軟で、高度にモジュール化され、非常に強力なシステムに変化させた。
更に、Python がどのように、科学ソフトウェアの開発、デバッグ、展開、メンテナンスに関する数々の重要な問題を解決してきたか述べる。
\end{quotation}

\term{\url{http://www.python.org/psa/Commercial.html}} 

Robin Friedrich は、商業プロジェクト内で、いかにして Python 利用を支援するかについてまとめている。

\term{\url{http://www.python.org/workshops/1997-10/proceedings/stein.ps}}

第 6 回 Python 会議で発表された内容で、Greg Stein は eShop の立ち上げと、後の Microsoft における Python の採用と利用を回顧したもの。

\term{\url{http://www.opensource.org}} 

経営陣は、商業的に書かれていないソフトウェアの信頼性と有用性を、疑問視しているかも知れない。
このサイトでは、オープンソースソフトウェアが、クローズドソースソフトウェアに比べて、どのような重要な長所を持っているかを説明している。

\term{\url{http://sunsite.unc.edu/LDP/HOWTO/mini/Advocacy.html}}

Linux Advocacy mini-HOWTO に感化されて、この Python Advocacy HOWTO 書いた。Linux や Python といった新技術の受け入れを勝ち取ることに関しての一般的な提案として、読む価値がある。一般に、すでに存在するシステムを攻撃したり、不備に文句を言ったりするだけでは、大した進展しない -- 焦点の定まらない泣き言のように受け取られるのがオチ。他のシステムよりも、Python が上回っている様々な分野の一部を指摘するほうが、 はるかに有効。

\end{definitions}

\end{document}


