Perl、Python、PHP、Ruby、JavaScriptについて - Mar 2016 -

Perl、Python、PHP、Rubyについて の「言語の未来」の2016年3月版。

2016年3月5日時点の各ランキング

|Rank|RedMonk (Jan 2016)|TIOBE (Mar 2016)|PyPL (Mar 2016)|
|--:|---|---|---|---|
|1|JavaScript|Java|Java|
|2|Java|C|Python|
|3|PHP|C++|PHP|
|4|Python|C#|C#|
|5|C#, C++, Ruby|Python|C++|
|6|-|PHP|C|
|7|-|Visual Basic .NET|JavaScript|
|8|CSS|JavaScript|Objective-C|
|9|C|Perl|Swift|
|10|Objective-C|Ruby|R|
|11|Shell|Delphi/Object Pascal|Matlab|
|12|Perl|Assembly Laguage|Ruby|
|13|R|Visual Basic|Visual Basic|
|14|Scala|Swift|VBA|
|15|Go, Haskell|Objective-C|Perl|
|16|-|R|Scala|
|17|Swift|Grooy|Lua|
|18|Matlab|MATLAB|-|
|19|Clojure|PL/SQL|-|
|20|Groovy, Visual Basic|D|-|

Python 「Perlがやられたようだな・・・」
PHP 「フフフ・・・奴はスクリプト言語四天王の中でも最弱・・・」
Ruby 「JavaScriptごときに負けるとはP言語の面汚しよ・・・」

いや、Rubyさん、あんたも結構負けてるし、そもそもPから始まらないでしょ。¹

さて、2015年は色んな年になった。ECMAScript 2015の承認、6を飛ばしたPHP 7のリリース、Python 2.7のサポートが5年を切り、Ruby 3の話題もでてきた。そして、待ちに待ったPerl 6の正式リリース。なんか、もうおなかいっぱい。ということで、そんな2016年とそれ以降について、各言語がどのようになっていくかを見ていきたいと思う。

セカンドシステム症候群を乗り越えろ！

「バカな・・・早すぎる・・・」

まずは、下の記事を読んで欲しい。

セカンドシステム症候群にまつわる3つの話―Perl 6, Python 3, PHP 6

お、Rubyについてないね。あれだ、Rubyは唯一の成功例だから、無いんだ。**決して無名だからではない。**うん、決して。

さて、この記事から現在はすでに9ヶ月ほどたっている。それらは今どうなったのか、そして、未来はどうなるべきなのかを独断と偏見で語ろうと思う。

Perl 6 - もはやPerlではない

「早すぎるということはない、我々は十五年待ったのだ」

15年の月日をかけて、Perl 6が正式リリースされた。余りにも長い開発期間とも思われるが、この15年間は、オブジェクト指向の成熟、非同期処理の流行、関数型プログラミングの見直し、といろいろなことがあったような気がする。そんな中、中途半端な完成品をリリースすることなく、最新の技術をふんだんに積み込んでいった貪欲さは称賛に値する。

さて、そんなPerl 6だが、もはやPerl 5とは全く別物となっている。どれぐらい違うかというとCとC#ぐらいに違う²。そして、言語に含まれる機能は豊富の一言に尽きる。例えば、言語仕様を簡単に学べるコードのサンプルをまとめたLearn X in Y minutesを見てみると、各ファイルのサイズや行数は下記のようになっている。

言語	ファイル名	サイズ	行数
Perl 5	learnperl.pl	6786	274
Perl 6	learnperl6.pl	56194	1439
Python 2	learnpython.py	18946	689
Python 3	learnpython3.py	21491	749
PHP	learnphp.php	18821	831
Ruby	learnruby.rb	12333	589
JavaScript	javascript.js	16009	517

ぶっちぎりである。というより、機能が多すぎて、覚えきれない。まさしく「やり方はひとつじゃない」を地で行きまくっている。分単位で学べるものじゃないだろ、これ。

そんなPerl 6の評価だが、今のところ未知数だ。正式リリースされたばかりと言うこともあり、言語としての評価が出そろうには今年いっぱいはかかるだろう。そこからライブラリや書籍が揃っていくのはしばらくかかると思われる。そんな中、Perl 5からPerl 6へ移るべきかというとそれはまた別の問題になる。

まず、Perl 5がなくなるというわけではない。Perl 5は今後もサポートされるだろうし、メンテナンスが停止することはないと思われる。ただし、これ以上発展することはないだろう。それはshやawk、sedのように、ただそこにある存在として使われていくだろう。逆に言えば、レガシーなどこでも動く処理を書く場合、Perl 5は安定した環境を用意してくれる。ただ、気をつけなければならないのはライブラリだ。全てのライブラリがずっとサポートされるという保証はない。そこは気をつけなければならい。

Perl 5がレガシーな言語として生き残るとしても、最新の技術を用いて新しいアプリケーションを作成するときの選択肢としては相応しくない。では、どの言語に移るべきかを考えたとき、Perl 6は選択肢の一つになり得る。しかし、あくまでも一つで有り、決定的に選ぶべきとは言い難い。Perl 5に慣れたユーザがPerl 6をすぐに使えるようになるとは思えない。Perl 6はPerl 5になかった多くのモダンな機能が追加されており、Perl 5しか知らないレガシーなプログラマーでは使いこなすことが困難だからだ。むしろ、PythonやRubyなどで今風の書き方を知っている人の方がPerl 6をすぐに使えるだろう。そういった人々が果たしてPerl 6を選ぶのか、その結末が見えるのはまだまだ先だ。

Python 3 - 2を窓から投げ捨てろ

「こちらの準備は抜かりない。『2008年12月3日』から、ずっとな…そうだろう？」

Python 2のサポートは2020年までである。サポートと言っても、セキュリティフィックスははされるが、バグフィックスがされることは基本的にもうない。すでに期限は迫ってきており、Python 3への移行は必須の状況だ。あと4年もあると見るか、あと4年しかないと見るか、どちらにしてもそのときは来る。

Python 2からPython 3への移行は非常にゆっくりとしている。移行のもっとも足かせになっているのは、コマンド名が被ることだ。Pythonを用いるアプリケーションはpythonというコマンドでインタプリンタが実行されることを期待している。しかし、そのpythonで実行されるPythonが2なのか3なのかは環境による。そして、システムに使われるアプリケーションであるほど2にしか対応していないのがほとんどだった。結局、システムのデフォルトはPython 2にせざるを得ないというスパイラルに陥っていた。

かといってこのままでは不味いと思われているとのも事実である。LinuxディストリビューションにおけるPython 3デフォルト化の流れによれば、各ディストリビューションで徐々にPython 3への移行を行っている。しかし、それが今年中に完了するのか、それともどこか諦めが発生するのかはまだわからない。

Python 2からPython 3への移行は失敗だったと言わざるを得ない。その原因は何だったのか？

• 移行期間を伴わずに、print文廃止や整数における/の振る舞い変更などの大きすぎる変更。
• Python 2からPython 3への移行へのメリットが少なく、Python 2で十分と考えるユーザーが多すぎた。
• すでにPython 2が広く普及し、システムのアプリケーションに使用されていた。
• Python 2とPython 3両方で動作する書き方が複雑になりすぎる。
• 各ライブラリのPython 3への移行があまり進まなかった。

結局はPython 2が完成されすぎていた事が原因かも知れない。しかし、Python 2は確実になくなる。早急にPython 3へ移らなければ、未来はない。

PHP 7 - 5.7だと思えばいい

「今更5.xと何も変わらない――全て、無意味だ」

PHP 6は黒歴史となり、PHP 7がリリースされた。さて、PHP 7で何が変わったのだろうか？PHP 5.6.x から PHP 7.0.x への移行 - 下位互換性のない変更点を見て欲しい。なんか、いつもの変更とさほど変わらないような印象を受ける。いや、これは悪いことではない。過去のバージョンと互換性が高いことはスムーズな移行を促し、程なく、PHP 7への移行が済まされるだろう。しかし、これぐらいならPHP 5.7で良かったのではないだろうか？

5.6->7.0への非互換な部分は問題ではない。結局、PHPはいつも非互換な部分が出てくる。いつものことだし、いつものように対応すればいい。なので、PHP 7への移行は決して畏れるものではない。むしろ、積極的に移行し、速度などの恩恵を受けるべきだ。いつもと同じ感覚で、順調に移行は行われると思われる。むしろ、PHPを使うなら、これぐらいは対応できないと困る。

PHPはこのままハウルの動く城型システムとして突き進むと思う。PHP 6で夢見たUNICODE化なんてものはとうてい無理なのだ。何も変わらないし、変えられないし、歪な構造を互換性という名の下に残しながら、バージョンアップでの非互換性を生産し続ける。PHPを使い続けるのであれば、それを解っていれば問題ない。ただいつか、Larry Wallが述べた

By and large PHP seems to be making the same progression of mistakes as early Perl did, only slower.

の意味に気付いた時、真のPHPが30年かけて作られることになるだろう。

Ruby 3 - 来たるべき言語

「あなた達、よく聞いて。Rubyの未来はあなた達にかかっているわ」

Rubyでの1系から2系への移行は成功だったと言えるだろう。互換性がない所はもちろん存在するが、Perlのように全く別の言語になったわけでもないし、Pythonのように移行が全然進まなかった訳でもないし、PHPのようにやりたかった変更ができなくてお茶を濁したわけでもない。では、どうして成功したのか？それは次の理由によると思う。

• 互換性が崩れたのが1.8 -> 1.9といういつの間にかバージョンアップした作戦。というか、1.9は開発版じゃなかったのか？³
• 1.9に移行するメリットが大きすぎた。特に速度の面で。1.8までが遅すぎたとも言えるが。
• システムのアプリケーションにほとんど使われてなかった。なので、最初から入っていることなんてなかった。
• 一番非互換な部分が文字列のエンコードという、英語圏ではまったく問題にならない所だった。非互換に泣いたのは日本人だけ。
• 1.8と1.9両方で動くコードが簡単にかけた。というか、ほとんどのコードが(日本語さえ処理しなければ)そのまま動いた。
• RVMやrbenvなどのバージョン管理ツールが発展しまくった。というか、そもそもシステムにRubyが入っていることが少なかった。
• Railsの新しいバージョン出る -> 最新のRuby推奨 -> Rubyもバージョンアップしないと。

Pythonとの大きな違いはRuby 1.8までは未完成だったと言うことだろう。1.9以降のバージョンアップは互換性がほぼ維持されており、問題になることは少ない。最近はセマンティックバージョニングの亜種を採用し、バージョン毎の違いもはっきりさせてつつある。

さて、そんなRubyだが、次は来たるべきRuby 3である。Feature #11473 Immutable String literal in Ruby 3がRuby 2.3.0で先行実装(ただし、デフォルトは逆)されるなど徐々に準備を進めているようだ。しかし、1.8 -> 1.9の時のようにいつのまにか作戦も使えないし、システムのアプリケーションに使われることも多くなってきているし、どのようにしたらうまく行くのかはまだ見えていない。先輩達の失敗を見ながら、どう対応していくのか。Rubyの真価が問われる時がもうすぐ来る。

もうひとつ、Ruby 3で大きく変わるとしたら、静的型付けの導入だろう。しかし、今のダックタイピングを崩さずに、どういう風に導入するのかは迷走している段階のようだ。Python 3のようにアノテーションというコメントだけで終わるのか、PHP 7のようにタイプヒントとして実装するのか、Perl 6のように多重ディスパッチにも使えるような静的型付けするのか、どうなるのは全く解らない。もしかしたら、やっぱり導入しないと言うこともあり得るのかも知れない。

ECMAScript 2016 - Tower of Babel

「や～れやれ…『JSer』は待つって事を知らないねぇ……」

2015年6月、ECMAScript 2015(ECMAScript 6)が承認された。classなど多くに人が待ち望んだ機能が追加されており、今後はJavaScriptが主流になると思った方も多いと思う。だがしかし、2016年3月5日現在、ECMAScript 2015に完全対応したブラウザは存在しない⁴。といっても、Microsoft Edge、Mozilla Firefox、Google Chrome、Apple Safariは確実に対応状況が改善しており、近い将来、問題なく使えるようになるだろう。

しかし、問題はInteret Explorer(IE)である。最新のIE 11であっても対応状況は絶望的だ。そして、IE 11は少なくともWindows 8.1が無くなるまではサポートされ、使われると予想される。そう、それまではブラウザでECMAScript 2015が使えることを期待することはできないと言うことだ。

もちろん、JavaScriptエンジンが固有化されるnode.jsやElectronを使う場合は無視できる話だ。しかし、JavaScriptのメイン舞台であるブラウザでの使用が制限されるとなると、誰のためのECMAScript 2015なのか解らない。結局、ECMAScript 5を使い続けるしかないのだろうか？

ということで、今後も、それはほぼ永久に、最新のJavaScriptを使いたければBabel等のトランスパイラを使い続ける事になる。だが、考えてみてくれ。それはTypeScriptやCoffeeScriptを使う場合と何が違うのだろうか？手間は全く一緒なのに、ECMAScript 2015には、TypeScriptのような静的型付けも、CoffeeScriptのような安全な書き方も無い。それにだ。altJSはそれだけではないのだ。PureScript、LiveScript、Dart、Haxe、Scala.js、Opalなどたくさんあるのだ。

旧約聖書の創世紀によれば、人々はかつて天にも届く塔を作ろうとした。しかし、言葉を乱され、言葉が通じなくなった彼らは街を離れ、塔を作ることをやめてしまった。こうして、彼の地はバベルと呼ばれるようになった。JavaScriptはバベルの塔なのかだろうか？ECMAScriptは多くの方言をまとめ、統一することには成功した。しかし、多くのaltJSは誕生し、それぞれが独自に進化しつつある。多数の言語が誕生しては消えていく中、どれを使えば良いのかと、未だ混乱のさなかにあると言わざるを得ない。

ただ一つ言えることは、ECMAScript 5は旧時代の遺物になると言うことだ。

冒頭のランキングは正しかったのか？

2016年3月5日調べ

yukicoder提出数とChocolateyのダウンロード数

言語	提出数	パッケージ名	ダウンロード数
Perl 5	1400	strawberryperl	22,401
...	-	activeperl	3,947
Perl 6	16	rakudostar	123
Python 2	4777	python2	48,975
Python 3	4384	python	77,347
...	-	python3	26,974
PHP	780	php	32,768
Ruby	5569	ruby	112,194
JavaScript	142	nodejs.install	502,729
...	-	nodejs	120,733

なんだろう、Rubyの人気があるようでないような安定感がたまらない。そこそこ頑張っているけど、一番は決して取れないあの娘っていう残念臭が常に漂うんだよな。

ランキングなんて恣意的に取れば何とでもなるものなのだ。大事なのは、それぞれの言語の特性を考え、使用に相応しいシチュエーションに合わせていくことだ。そんな中、各言語は次々とリリースされていくし、言語も産まれては消えていく。そう言った新バージョンや新言語が出たら、すぐさま見るべきだ。新機能や新バージョンを積極的に使えと言うのではない、積極的に検討や検証をしろと言うことだ。そうしなければ、気付いた時には時代の波に乗り遅れているだろう。

---

引用元ネタ

• 『ギャグマンガ日和』増田こうすけ著『ソードマスターヤマト』夢野カケラ著
• 『空を見上げて「バカな・・・早すぎる・・・」ってつぶやいたら』2ちゃんねるVIP板

1. とある言語開発者の日記等によると「Rubyはロングテールの付いたP言語である」という学説がYAPC::Asia 2006 Tokyoにて発表されたらしい。現在の所、独自研究の域を出ていないためか、WikipediaのP言語の項目には反映されていない。 ↩

2. つまり、全くの別物と言うこと。 ↩

3. 1.8までは、マイナーバージョンが奇数なら開発版、偶数なら安定版という位置づけだった。 ↩

4. ECMAScript 6 compatibility table ↩