パスワードを忘れた? アカウント作成
127060 journal

taro-nishinoの日記: 私がMoose(Perlポストモダンオブジェクトシステム)を使う理由

日記 by taro-nishino

Perlerの内でも、Mooseに対して懐疑的な人もいます。それは主としてテクニカルな理由からです(例えば、ロード時間が大きい等)。勿論、Mooseを知らずに批判し、Perlも次いでに批判する人もいます(そういう人はPerlも知っていると言うのですが)。
私はどうかと言えば、大いに支持する立場です。但し条件があって、メタ機能(これが最大のMooseの特性だと思っています)を使う必要が無いなら、Mooseライトとも呼ばれるMouseを使います(例えば、ただ単にアクセッサメソッド生成のために使うなら)。
私の如き底辺の者が言っても説得性ゼロなので、Moose及びCatalyst方面で活躍されているJohn Napiorkowski氏がMoose礼賛、Why I use Moose, Perl's Post Modern Object Systemを書いております。これは、テクニカルなエッセイではなく、Mooseへのオマージュなので気軽に読めると思います。以下に私訳を載せておきます。

私がMoose(Perlポストモダンオブジェクトシステム)を使う理由
2009年4月24日 John Napiorkowski

以下は、私がかなり前にGoogle AppEngine for Perlプロジェクトのメーリングリストに書いた、Moose弁護を修正、更新したバージョンである。中核の技術基礎としてMooseを使用するCatalyst 5.8が最近リリースし、私がこれを素晴らしいと思う理由について熟考することはいいことであろうと感じたので、ここに再度発表することを決心した。Mooseが優れたオブジェクトシステムである理由について、かなり多数のチュートリアルやコードオーバービューがあるが、Moose及び、1デベロッパーとして、MooseがPerlにあることの幸福感の理由を述べたポストは多くないと思う。
また、Google AppEngine for Perlプロジェクトは十分に理解されていないと思うし、少しでもプロジェクトにも注目が行くことを望んでいる。
オリジナルのバージョンここで読むことが出来るが、そのバージョンは恥ずかしいスペルと文法エラーがある。

Mooseが無かったなら、私はおそらくPerlに信頼性を持てず、他の言語へと向かっただろう。私は1996年からずっとサーバーサイドの主要な開発言語として使って来たので、このことは軽い声明ではない。最初にプログラミングを始めた時、2つの理由でPerlに引き寄せられた。先ず第一に、大変な苦労無しに若しくは、大変な苦労を強要されずに、私が必要とすることをさせてくれた。第二に、私の理想家気質を惹いたソフトウェア開発と知識の共有の方法の概念、今日ではオープンソースコミュニティと拡大的に考えられるものに私を導いた。同じ経験を持つプログラマがPerlにかなりいると想像しなければならない。CGIモジュールがサーバーサイドフォームを作ることを自明にしたので、我々の多くがPerlを使い始めた一方で、DBIはウェブとバックエンドのデータベース間で情報の移動を直接的にした。私が必要としたことをPerlはした。

しかし、やがて、私のPerlへの愛着は低下した。Perlのデフォルトのオブジェクトシステムは非常に最小限であり、アプリケーションのモデリングにおいて、最良の実践的アプローチを認める(しかも、奨励さえしている)言語を羨んだ。問題ドメインを記述することなしに、多大な苦労が時間を割いたので、始めて私は、しなければならないことをPerlが邪魔をしているかのように感じ始めた。さらに悪く、このPerlの欠点は、既存の方法論による標準との隔たりを埋めるため、多くの大きなプロジェクトで独自の方法を作る要因となった。いかに多くの異なった、しかも非互換のコンポーネントシステムがPerlのために書かれたことか。オブジェクト指向プログラミングをより簡単にするシステムがいかに多いことか。そして、CPANから新しいモジュールをロードする度に、一握りのプロジェクトでしか使われない、生煮えのOOフレームワークのための依存の塊をもロードすることになる。毎回、根底にある新しいフレームワークと独自性を学ぶ必要があるので、新参者のコードへの寄与を非常に難しくしている。それが、最も重要なPerl CPANモジュールの貢献者がせいぜいほんの一握りである理由である。さらに悪く、Perlは大きなアプリケーションに不向きで、スパゲッティコードであるという相変わらずの信条を与えるかも。
考えの競合があることはいいことであり、それがPerlの強みにしていると思うが、基礎的な中核のプログラミング作業に対して、一貫性の無さは我々に害を与える。CGIがそれほど完全でなかったなら、又はDBIがデータベースアクセスの主要メソッドでないなら、Perlはどうなっているだろう?

Mooseは、Perl及び一般的には、そのコミュニティとプログラミングに対する私の愛着を復活させている。MooseはPerlの最小なOO特性を綺麗に解決している。私は少ない定型を書き、大部分の時間を問題のドメインに費やす。それは、最良な実践と共有ソリューションの倹約が増大出来るように豊富な記述を与える。更に、プログラマによるプログラマのために書かれているので、他の浮世離れなOOソリューションより私の頭に適応することを知っている。私の知るかぎり、他の競合するPerlのOOフレームワークよりも、大きく且つ増大している、活発なデベロッパーのコミュニティを持っている。最近、Catalyst、DBIx::Class等の、私達の時代の最も重要なプロジェクトの幾つかは、Mooseを使っているか又は、Mooseへ移行している。私にとって、ウェブサイトのアプリケーションを書き始めた当時、Perlがこうである思ったように、MooseはPerlのOOを表現力豊かで楽しくしている。

パーフェクトなのか? いや、確かにMooseには改良する余地がある。しかし、これらの改良を行う正しい決定は既にされている。デベロッパーコミュニティは、貢献者の増大と同じく、フィーチャーの増大とフレームワークの採用の増大について真剣である。10年より以上Perlを使用して来ているけれども、Mooseは貢献者として私が参加出来る数少ないプロジェクトの一つであるように、私が好例である。Mooseが貴方が必要とするように動かない? それは素晴らしい。IRCへ来て、貴方のケースを話しなさい。
しかし、Mooseチャネルは、私が今まで見た交戦のうちでも、最も頭の良い知力持ち主の集まりなので、貴方の宿題を先にすることを奨励するだろう。

私にとって、適切に書かれているPerlはMooseに始まる。貴方が請負うかも知れない深刻なプロジェクトの基礎として、Mooseは役立つに違いない。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...