Perlゼミ

1. Perl
›
2. 読み物

Perlは後方互換性を維持するスクリプト言語

後方互換性の維持という観点から見ると、二つのタイプにスクリプト言語を分類することができます。後方互換性を維持する方針を持つスクリプト言語と後方互換性を維持しない方針を持つスクリプト言語です。

各スクリプト言語の後方互換性

Perlの後方互換性

Perlは非常に高いレベルで後方互換性が維持されてきた言語です。古いバージョンのPerlで書いたスクリプトは、多くの場合新しいバージョンPerlで動かすことができますし、スクリプトの変更は最小限のものですみます。

安定性という点では、非常にPerlは定評があります。

JavaScriptの後方互換性

JavaScriptも非常に高いレベルで後方互換性が維持される言語です。ブラウザに組み込まれているスクリプト言語なので、後方互換性を崩すことはまずできないといってもいいでしょう。

Pythonの後方互換性

Python2というバージョンに限っていえば、Pythonは非常に高いレベルで後方互換性が維持されてきた言語です。Python2の古いバージョンで記述したスクリプト新しいバージョンのPython2で動かすことができますし、スクリプトの変更は最小限のものですみます。

けれども、Python2と最新バージョンのPython3には、後方互換性がありません。かなり高いレベルで後方互換性がありません。Python2をPython3に移行するためには、非常に多くのスクリプトの書き換えを必要とします。

ですから、現在ではPython3とPython2という二つの系統が存在する状態になっています。(Python2のサポートは終わる予定です。)

Rubyの後方互換性

Rubyは後方互換性が維持されないスクリプト言語です。どのバージョンにおいても、後方互換性は維持されません。1.6, 1.7, 1.8, 1.9とどのバージョンを見ても、後方互換性は維持されません。

Ruby1.8はJIS規格で標準化が行われたのにもかかわらず、次のバージョンのRuby1.9では、後方互換性が崩されました。

ですので、現在ではRuby1.9とRuby1.8という二つの系統が存在する状態になっています。

PHPの後方互換性

PHPも後方互換性が配慮されない言語です。バージョンが上がるたびに書き換えを行う必要があります。

後方互換性を維持することの意味

後方互換性を崩すということの重大な決定を、プログラムを知らない若い人たちは、比較的軽く見る傾向があると僕は思っています。

たぶん後方互換性を崩すという決定が、どれくらい大きくプログラムに影響を与えるかということを知らないのでしょう。

ではここでは、Python3とPython2は後方互換性がなく、Perlは一貫して後方互換性があります。この二つを比較してみましょう。

後方互換性が崩れるとプログラムの書き換えを行わなければならない

まずだれもが思いつくのは、後方互換性が崩れるとプログラムを書き換えなくてはいけないということです。書き換えればいいじゃんと思うかもしれませんが、10個くらいのスクリプトだったら、がんばれます。

でも10000個あったら、どうするのでしょうか。全体をきちんと書き換えなければ、動かないタイプのものであったら、10000個変更してから、プログラムの動きを確認することになります。

ささいな書き換えであったとしても、相当難しいでしょうし、とてもつまらない作業でしょう。つまり、後方互換性を崩すということは、今までプログラムをその言語で書いていたユーザーの負担を相当増やすということです。

Perlで書いておけば、将来的には大規模な書き換えが起こりません。でもPython2で書くと、将来大規模な書き換えが発生します。だから、スクリプトの数が100個を超えるのであれば、僕はPerlで書くことをお勧めします。

後方互換性が崩れると新規ユーザーはどちらを選んだらよいかがわからない

後方互換性が崩れると新規ユーザーはどちらを選んだらよいかがわからくなります。Python3にしようか、Python2にしようか、Ruby1.9にしようか、Ruby1.8にしようか迷います。

新しいほうを選んでおいたらよいんじゃないのということも簡単にはいえない。それは、ライブラリが新しいバージョンではそろっていないので、古いバージョンを選ばざるをえないということが、とても多いから。

古いほうには未来がないし、新しいほうにはライブラリがそろっていないという、ジレンマをいつでも抱えることになっちゃう。ユーザーのバージョン選択の複雑性が増しちゃうってことです。

言語の開発者は新しいバージョンを選んでほしいと思っているのだけれど、そううまくはいかない。結局別の言語を選んでおいたほうが、生産性が高いと思っちゃうかもしれない。

Perlだとそんなジレンマがなくって、常に新しいPerlを選んでおけばいい。いつでも、新しいバージョンを選べばいい。ただそれだけ。とても決定が楽だ。

ユーザーが古い書き方を続けちゃうという欠点もあるのだけれど、その点は、新しい書き方のほうがよいよーとWebでどんどん伝えていこう。Perlはゆっくりと漸進的に新しくなっていくのがよいね。

ライブラリ作者はどのバージョンを対象にライブラリを書けばよいかに困る

一番辛いのは、ライブラリ作者がどのバージョンを対象にライブラリを書けばよいのかということを、いつも考えなくちゃいけないってことだ。

Python3用に書けばPython2では動かない。Python3用に書けば、Python2では動かない。Ruby1.9用に書けばRuby1.8では動かない。Ruby1.9で書けば、Ruby1.8では動かない。

ライブラリ作者はいつもこんな悩みを抱えることになる。どちらをいつまでサポートしようか、古いバージョン用のライブラリでバグが見つかったらどうしよう。バグフィックスのサポートをいつまで続けるか。

特に大規模なライブラリを作っている場合は、移行は容易ではなくって、ほとんどの場合は古いバージョンのサポートがなくなる運命にある。両方のサポートは非常にしづらいからだ。

ユーザーから見ればこうなる、あるライブラリは古いバージョンでしか動かないが、あるライブラリは新しいバージョンでしか動かない。こうなると決定はとても苦しい。新しいバージョンに移行したくてもできないか、非常に難しいか、とても手間のかかる作業になる。

この点Perlは超優秀。Perlの場合はライブラリ作者は、ひとつのPerlだけを考えればいい。まぁPerl5.8.7で動くようにしておけば、まぁどこでも動くでしょう。CPANにあるモジュールは、このバージョンのPerlでは動くが、このバージョンのPerlでは動かないということを、ほとんど意識しなくってもいい。

ライブラリ作者にとっては、ライブラリの2重管理というのは、とても退屈で大変な仕事なので、できればやりたくない。Perlで書いてしまえば、2重管理しなくてもよいので、とても楽です。

後方互換性を維持することは複雑性を減らす

ここまで読んでくれればわかると思うのですけれど、新しい言語のバージョンをリリースして、きれいな書き方ができるようになっても、表面的にはシンプルになったように見えるのだけれど、プログラムやアプリケーションの全体という観点から見てみると、より複雑さを増していることがわかる。

Perlは古い書き方を残すので、表面的にはシンプルに見えないし、クリーンには見えないのだけれど、プログラムやライブラリの全体という観点から見ると、非常にシンプルでクリーンさを保っている言語だ。

プログラムの選択をするときは、表面的な記述だけではなくって、プログラムやライブラリを含めた、クリーンさというものにも注目してもらえたらと思います。特に若い人たちや経験の浅い人たちは表面的なものをみがちなので。

そうすると、Perlでプログラムを記述しておくと、とても楽なんだよということがわかってもらえるかなぁと思います。迷わずにとても気持ちよくプログラムができる。