（話が１年程古い事に今気づいた）SWIGを使ってサポートされてる全ての言語のバインディングが作れるというのは魅力的に見えるかもしれませんが、私は反対派です。
http://chasen.org/~taku/blog/archives/2005/07/_swig.html
まず大前提として"各言語間で全く同じAPIを使えたほうがいい"は賛成できかねます。現実的にperlでそのAPIを使ってる人がJavaで似たようなアプリを書くかというと、書かないとおもいます（そのもとのライブラリの開発者なら書くかもしれません）。Perlを７０％の時間書いてて、残りは違う言語を必要な時に使う、みたいな私のような人のほうが多いと思うのです。MeCabを使う時は１００％Perlから書きます。よって、各言語間の事は私にとってはどうでもいい事で、それよりどれだけ自分が書いているほかのライブラリにうまくはまるか、のほうが重要です。
また、私にとってとても大きい問題点はSWIGは特定のライブラリの特定のバージョンから生成されるもののため、基本的にその固有のバージョンしかサポートしてないということですね。最初の一回は確かにSWIGで作成されば楽ですが、その後例えばバージョン1.0.0, 1.2.0, 1.2.1と下層のライブラリのほうが進化していった時に複数バージョンのライブラリをサポートするのがかえってめんどうくさそうです。手で書くともちろん色々と煩雑ではありますが、細かいサポートが可能です。
あと以下は蛇足的ですが・・・
- やっぱりCライクな構文をPerlで見ると気持ち悪い。
- SWIGが生成するPerlコードが（Perlチックになっていても）気持ち悪い
- ドキュメントを書かない癖がライブラリ作者につきそう
特に最後のポイントはSWIGで他の言語のモジュールを使った事がないので、Perlだけの事かもしれませんが、ドキュメントの問題があると思います。PerlにはPODという優れたドキュメントシステムがあります。ドキュメントを書くフレキシビリティに関しては疑問点の残るPODですが、perldoc Moduleとやるとドキュメントがでてくるというこの安心感は他の言語ではなかなか得られないものです。ところがSWIGは自動生成である分、正直そういう普通手書きなら必ず書くべきものがかなりおざなりである事が多いように思われます。
SWIGにメリットがあることはわかります。ですが、SWIGは下層のライブラリの開発者向けで、あまりエンドユーザーに向いていない気がします。結局は最終的に使われる言語やユーザーベースの状況を細かくコントロールしないとバインディングが成功することはないと思うのです。逆に言うと、ライブラリ開発者の方々は、もしC/C++でライブラリを書いたならそれに対するバインディングはその言語のハッカーと共同開発のような方向に持って行ったほうが生産性が高いと思うのですよね。
ちょっと散漫な終わり方ですが、とりあえず以上で。
追記：某バインディングを書いている知り合いが「全スクリプト共通のSWIGコード書くのが面倒くさい」という意見も言っておりました。書いた事ないのであんまり細かい事わからないですが、「callbackとか指定する時に扱いが違いそう」という事なので、なんとなく納得。
