JavaよりPerlを覚えたほうがいい、っていうか覚え書レベル

ちょっと感じたことをパラパラと書こう。
全然まとまってないし。そのうちまとめなおすかも。

規模がやや大きくなってくると似たようなコード･･･パラメータの一部だけが違うとか･･･を書くことが多くなることがある。
設計がそれなりに練られていればそうでもないのだが、ベタベタな設計だと、似たようなモジュールが量産されることになる。

ソースを生成するためのツールというか、CVS形式のデータを読み込んで、テンプレート化されたモジュールを一気に作りこむ等そういうツールが欲しくなる。
私感だが、Perlがもっとも適しているような気がする。文字列処理が強力だし、何しろすぐに書けるし。

もし詳細設計まですぐに決まっていて、何も考えずにコードを大量に生産するのがより求められるのであれば、Perlなどを用いて、機械的にコードを生産することをお薦めする。
というか、JavaBeanってたとえばPOJOであろうがベタベタ（setとgetばかり）になってしまう。その為のXDocletなどのツールなんだろうけども。

実はMDAにしても、
「WordをVBScriptで解析し、そこからソースコードを吐き出す」
という仕組みが出来れば、すぐにでもやれるのではないか？とか。

スクリプト系言語についてももう少し。
ルールエンジンなんて発想しかり、どこかで「手続き型コード」というのを求めており、それが手っ取り早く書けるのがスクリプト系言語なんだろうなぁ。

あとAOP実現の為のバイトエンハンスドとか見ると、「スクリプト系だったらソースを正規表現でひっかけて書き換えればいいじゃない」ってなってしまう。
J2SE5のメタデータは便利かな、って思うけど。

個人的にPHP、Perlのイヤな部分って、OOPをやる際の厳密性チェックの緩さなんだけども、そこが今後厳密になっていうのであれば･･･実行時のオプションとか？･･･、スクリプト系のほうがいいのかなぁ。

バイトコード化の利点の一つはソースコードの隠蔽なんだけども、こんだけネットにパブリックドメインでしかも洗練されたソースが溢れているんだもの。今更何を隠蔽しようとするのか？
また、ネイティブコードについても、.NET Framework しかり、年々重要度は低くなってきているというか。

AOPについて。
AOPは横断的関心の分離が肝。
じゃあ横断的関心って何？ってなったときに出てくるのがロギング、トランザクションなどの非機能的要件。
個人的には非機能的要件って例えばAPサーバ側の設定とかそういう形で分離可能だったのかな、って思うけど、同じ言語構造の中でそれらも管理したいのか。
こうすればすごくメリットがあるよ、みたいな部分がいまいち分からない。
C++からJavaが会得できたことって、多重継承の中止による複雑性の排除だと思うのだけども、AOPって実は複雑性を増すだけじゃないのか？シンプルになるのか？