Pyhontが好きです。
Lightweight Languageというと、Perl, Rubyなど、いろいろと選択肢があります。 Javaでもできる分野もありますし、Schemeなんかも手早く試せます。
ただ、自分はPythonが性に合います。
- 習得しようとした当初に、Object思考の知識が少しばかりあったこと
- Pythonがメンバアクセスの制限をせず、プログラマに任せていたこと
- ドキュメントが整っていて内省的(introspective)であったこと
これらが大きな理由かな、と思っています。
メンバアクセス制御は絶対に必要です ……時には
Pythonにはメンバアクセスを保護する機能はありません。publicとか、privateとかです。 保護したいと思ってもできない『不便』な仕様です。
プログラムを記述するときには、いままでの成果を捨てて再設計することが多くあります。 クラスを単なる関数に落としこんだり、機能を別クラスに掃き出したりと、掃除みたいなものです。
このとき、メンバアクセスを考慮したメソッドが厄介なことになる場合があります。 いわゆる、getter-setterというやつのことです。
// C++
class Hoge {
private:
int m_Counter;
// ...
public:
inline int getCounter() const throw();
inline void setCounter(int a_Counter) throw();
//...
};
// ...
// ================================================
inline int Hoge::getCounter() const throw() {
return m_Counter;
}
// -----------------------------------------------------------------------------
inline void Hoge::setCounter(int a_Counter) throw() {
m_Counter = a_Counter;
}
一部分を変更すると、これらも波及的に変更しなくてはならない場合があります。 ささいな事かもしれませんが、こいつが存外に煩わしいのです。
アクセス制限をかけるということは、その部分だけは一定の規約の元で外部からの操作を許すということを宣言しています。 そういった規約を取り決めるのは、対象物が完成に近づいてからでないと難しいものです。
頻繁に内部構造が入れ替わっている設計段階では、規約は後回しにしたくなります。 アクセス制限のようなことに気を配る余裕がありません。
高速にプロトタイプを組み上げるラピッドタイピング段階では、 Pythonのメンバアクセス制限のように保護機能を全く考慮しない言語の方が気楽に扱えます。
ドキュメントやら体裁を整えるのに夢中になり、 肝心の本体がスカスカなんてことを自分は非常によくやります、格好から入るタイプです。
で、あれば。過度な保護機能は最初から無くても構いません。 必要になったら、組み上がった設計を元に他の言語……、C/C++などで組み直すのが良策です。
個人的に独自の圧縮ファイルライブラリを作ったときは、
- Pythonで設計
- C/C++でクラス階層実装
- staticな使用を前提としたライブラリ化
- C言語のみでインターフェース設計
- 内部はC++で、shared library(DLL)化
という、手順を取りました。
この流れが快適だったというのが、Pythonの評価を押し上げた経験の一つです。
──続きます。
0 件のコメント:
コメントを投稿