仕事でPerlを使ったことはあるのだけれど、Webのつまみ食いだけで済ませてきたため、一度腰をすえて「入門」してみようと購入して早何年。ようやく「入門」できました。
#amazon||>
||<
#amazon||>
||<
もともとCとかJavaとかPHPなど、Perlに比べて文法の自由度が低い言語に慣れていたため、Web上でPerlの書き方をつまみ食いしてると「なんで２文字とか３文字の特殊な変数をこんなに用意してるんだ？」とか「"$_"とか、なんで省略系が多いんだ？」とか、「そうである」ことは理解できるんですが、「そもそもなんでそうなっちゃったの？」という疑問が沸き起こって、結構作業の邪魔になってました。"Why?"の部分を調べ始めてしまって、時間取られちゃうんです。
有り体に言えば「Perlの文化」を知らなかったわけですが、初心に戻って今回の"Learning Perl"を読み通し、ようやくその一端を垣間見ることが出来ました。
- 「なぜ○○という書き方を許したのか？」
-- 「Larry Wallがそれを望んだから」
- TMTOWTDI; There's more than one way to do it.
-- Larry Wallの哲学。
- なんで変数名の文字数を少なくしたり、いろいろな"省略"機能が存在するのか？
-- タイピング量を少なくしたいPerlユーザが多いから。
うまくまとめられませんが、とにかく個人的に「まぁPerlならしゃーないよね ┐(´∀｀)┌ 」という諦めがつくようになりました。
Slashdotのインタビュー記事が参考になったのでメモ：
- 本家インタビュー：Perl開発者ラリー・ウォール - スラッシュドット・ジャパン
-- http://slashdot.jp/developers/article.pl?sid=03/03/06/1041206
最後に、Perlユーザだけでなく、あらゆるプログラマに対してあてはまる印象に残った一節を引用します。
"Learning Perl", 4th edition, p136:
>Remeber you're always writing code for two readers:
>the computer that will run the code and the human being who has to keep the code working.
>If the human can't understand what you've written,
>pretty soon the computer won't be doing the right thing either.
他人が理解出来ない、理解が難しいコードを書くな、「動けばOK」で済ませるな、という事ですね。
自分の書いたソースコードを、後々メンテナンスしていく「人間」がいるということを忘れるな、と。