-nle と .pm から始める Perl 入門とかどうかしら？（前編）

この記事は Perl Advent Calendar 2019 の 12/4 の記事です。内容は主に職場で Perl を 教える側 の人に向けた提案です。

（今から仕事で Perl を学び始める人は、多分 Linux/Unix 環境に関わる人であろう、と想定しています。違ったらごめんなさい。）

初めて書く Perl は何が良い？

皆さんは職場の新人さんに Perl を教えるとき、初めにどんな形式でプログラムを書いてもらっていますか？

普通は何らかのエディタで foo.pl, hello.pl のように *.pl ファイルを作ってもらって実行、ではないかと思います。この方法は、使い慣れたエディタが有る人には最も安心感を与える方法でしょう。

ですが、この方法には二つの弱点があるのではないでしょうか？

$_ などの特殊変数や、その省略法則（ex.デフォルトの m// の対象、split の第２引数、 -X テストの対象…）を教える切っ掛けが乏しい
*.pm 形式のモジュールの書き方が先送りされる

そして何より、 今さら、 Perl を学ぶメリット を語る力が弱いのではないか？と私は思うのです。 1990年代ならともかく、現代では Perl は Python, Ruby, PHP そして JavaScript と強く比較しながら使われる時代です。今さら何故 Perl? という問いに答えを用意してあったほうが、学ぶ人も意欲を持ちやすいのではないかしら？という考えです。

最初はコマンド行のワンライナーから、でどうでしょう？

その意味で、私は、最初に教える Perl はコマンド行での perl -nle … が良いのではないか？と考えます。何故なら、 コマンド行ツールとしての Perl の強さは、2020年代を迎える今でも十分な輝きを保っているからです。幾つか挙げるなら、

とにかく記述量が少ない。なのに、大きな働きをしてくれる
起動が速い、実行速度も十分速い、もちろんビルド不要
多くの Linux/Unix 系システムで、環境構築作業をほぼせずに、使い始められる
コア機能だけで十分役に立ってくれる（パッケージ管理の勉強を後回しに出来る）
仕様が長期に渡って安定している

つまり、コマンド行ツールとしての Perl から始める理由は、簡単に学習を始められる上に、努力と得られるメリットの比率も抜群だからです。

また、Perl を学ぶ時の難所である $_ などの特殊変数やその省略法則を教えるという点でも、コマンド行スタートにはメリットが有ります。何故なら、それらがワンライナーを少しでも短く楽に書けるように設計された、lwall からのギフトだからです。なのにコマンド行を全く避けてしまうと、その短い記法が分かりにくさ・読み難さの元凶、害悪にしか思えなくなるでしょう。説明する側も言い訳がましくなり、辛いところです。

他にも副次的効果を何個も挙げられます。

shell と端末に馴染む機会にもなる
- 特にワンライナーを書いてすぐ試す、リズムを会得できる。これは後のプログラミングにも有効。
sed, awk などの作ってきた Unix 文化の説明の良い機会にもなる
ミスが増えるので、perl -w の説明も導入しやすい
perl -d のデバッガに馴染む切っ掛けにも繋げやすい（ただし Term::ReadLine::Gnu の導入を推奨）
段々プログラムが複雑化する過程で、変数名の綴り間違いの怖さに気づく切っ掛けにもなり、 use strict の意義を伝えやすくなる。
BEGIN {}, END {} を教える切っ掛けも作りやすい

この教育方法の弱点

この方法の弱点は、学習の記録を残すことが難しいことです。学習の効果を定着させるには、学習者が学んだことを容易に振り返って復習出来ることが大事です。しかしコマンド行は一過性の側面が大きいため、そこを不安に（不安定に）感じる人もいるでしょう。

これについては、以下の対策が有りえます。

シェルのヒストリー機能とそのダンプ方法(history -w, fc -W)を初期に教える。
- ヒストリーのダンプを git に保存しても良いかもしれない
コマンド行の短縮記法を教えた後に、B::Deparse を使いながら冗長な（省略を廃した）記法も教える。それをスクリプトファイルとして残し、これを git に保存する。
いっそ script コマンドで全て記録するとか？ ttyrec? asciinema?

組織を超えた教材化は難しいかも？

あとひとつ難しいかもしれないのは、コマンド行での Perl の使い方は環境（組織、文脈）に特化する面が大きく、汎用の教材を作りにくい、かもしれないことです。例えば業務の副次的なプログラムのエラーログから情報を抜き出して DB に投入するとか…それが一般的で頻出する問題なら、既に専用のプログラムが作られていたり、予め構造化してログを吐くことが出来ているはずです。（もっと良いツールがあるのに何で自分で書くの？と言われると…教える時の言い訳が増えますね…内容次第ですが…）

なので、教育のためのシナリオと、そこで使うデータセットの準備が、最も手間取る所になりそうです。

（適切なツールが既に存在しても、それを探し出すのに何十分もかかるなら、自分でさっとスクリプトを書いたほうが早い、というケースの話も、しても良いかもしれません）

とはいえ、既存の教材も無くはないので、例えば↓この辺りから題材を抜き出しつつ教えるのも良いかもしれません。