PerlユーザーがRubyユーザーに伝えたいこと ～ PerlとRubyの比較を通して

PerlユーザーがRubyユーザーに伝えたいこと ～ PerlとRubyの比較を通して

Perlユーザーとして、PerlとRubyを比較を通して、Rubyユーザーに伝えたいことを実名で書きます。匿名でPerlに対して書かれたネガティブな信頼性の低い記事がネット上に、あふれているからです。

「RubyからPerlへ」という記事でPerlの価値を落とさないで

Rubyの公式ドキュメントには、「間違いなく複雑」というPerlに対する誤解を招くネガティブなメッセージが含まれています。

Perlはすばらしい言語です。ドキュメントもすばらしいし、Perlコミュニティもすばらしいコミュニティです。 しかし、言語はかなり大きく、間違いなく複雑です。 RubyからPerlへ

Rubyの実装には、複雑さが少なく、Perlには多いような印象を、初見のユーザーに対して与えています。

Rubyの言語実装は小さく、Perlは大きいような印象を与えています。

Rubyの実装の複雑さ

ひとつの例として、PerlとRubyのGCの実装について考えてみましょう。

Perlは、リファレンスカウントGCと呼ばれるGCの実装を持っており、Rubyは、世代別GCというGCの実装を持っています。

さて、リファレンスカウントGCと世代別GCは、どちらの実装が複雑でしょうか。

一般的に理解されていることを、土台にすれば世代別GCのほうが、実装が複雑です。

リファレンスカウントGCのほうが、シンプルなのです。

このような一つの面を取り上げてみても、Rubyの公式ドキュメントが、Perlを複雑と一方的に語っているのは、不公平といえるでしょう。

Rubyのドキュメントは、Rubyが、複雑さの側面を持っているのに、まるでPerlだけが、複雑であるかの印象を与えています。

Rubyの言語の大きさ

Rubyは、バージョンを追うごとに、新機能が追加され続けてきました。Rubyは、言語機能が大きくなり続けています。

• Ruby 2.0 新機能
• Ruby 2.1 新機能
• Ruby 2.2 新機能
• Ruby 2.3 新機能
• Ruby 2.4 新機能
• Ruby 2.5 新機能
• Ruby 2.6 新機能
• Ruby 2.7 新機能

一方Perlは、2002年Perl 5.8の時代に、言語機能をたくさん追加していく方針を転換しました。「もし、必要な機能があれば、モジュール(ライブラリ)において実装する」そういう方針への転換です。

Rubyのドキュメントは、Perlについて、まったく反対のことを語っています。

Perlは大きくなる速度をゆっくりさせたのに対して、Rubyは、言語の大きさを着実に増しているのです。

言語の大きさに関して、Rubyの公式ドキュメントは、Perlに関する正しい事実をユーザーへ伝えていません。

CSVを処理するRubyとPerlのソースコード

「Perlの文法はクズのようだ」

Rubyユーザーの皆様は、そう思っておられませんか。

では、実際に、Perlの文字列処理でCSVを処理するコードを、実際に見てみませんか?

Perlで標準入力から受け取ったCSVデータを、入力して、出力するサンプル

ファイルあるいは、標準入力から受け取ったCSVデータを、入力して、出力するサンプルです。Windowsで日本語対応。

# Perlで標準入力から受け取ったCSVデータを、入力して、出力するサンプル

use strict;
use warnings;
use utf8;
use Encode 'encode', 'decode';

# コマンドライン引数、あるいは、標準入力から受け取る
while (my $line = <>) {
  # Perlの内部文字列にデコード
  $line = decode('cp932', $line);

  # 改行削除
  chomp $line;
  
  # split関数で分割して配列に代入
  my @items = split(/,/, $line);
  
  # join関数でタブ区切りでつなげる
  my $new_line = join("\t", @items);
  
  # 標準入力に出力
  print encode('cp932', $new_line) . "\n";
}

どうでしょう。世間でPerlが、言われているような、可読性が皆無のクズみたいなコードでしょうか?

それとも「うーん、まぁ、普通」という感じですか?

実行はコマンドライン引数から受け取って

perl script.pl foo.csv

あるいは、標準入力から受け取って

cat foo.csv | perl script.pl 

ですね。

「あれ、Perlって、CSV処理するライブラリ、ついてないの。ついてないの小学生までだよねー」

なんて、思いませんでしたか?

Perlの標準ライブラリの設計は、CPANをブートストラップできる小さな構成です。

Perlのコア自体のライブラリを肥大化させず、Perlコア自体の開発者が、メンテナンスするコストを下げています。

Perlでは、CPANから、Text::CSVか、処理速度の速いText::CSV_XSを、ダウンロードすることができます。

RubyでCSVデータを、入力して、出力するサンプル

RubyのCSV処理のサンプルはこちら。Rubyには、最初からCSV処理ライブラリが、入っています。便利ですね。

require 'csv'

csv_data = CSV.read('member.csv', headers: true)
puts "start..."

File.open("intro.txt", 'w') do |file|
  csv_data.each do |data|
    intro_msg = "#{data["club"]}クラブ所属の#{data["age"]}歳、#{data["name"]}です。\n"
    puts intro_msg
    file.write(intro_msg)
  end
end

puts "complete! See intro.txt."

Ruby CSVを扱うためのメモから引用させていただきました。ありがとうございます。

さて、PerlとRuby比べていかがですか?

Rubyの方が、10倍、きれいに楽しく書けますか?

それとも、まぁ、どっちもどっちでしょうか?

Ruby開発者からのPerlへの悪口はストップ

Rubyの作者のまつもとゆきひろ氏は、Perlのコアのコードを見て「Perlは私が見たソースコードの中で最悪のソースコードです。」と申しました。

また、PHPでは、プログラムはきれいに書けないとか、Javaではきれいに書けないとか、申しておりました。

Rubyのコミッター様のおひとりは、Perlに対して、PHPに対しても、Javaに対しても、C言語に対しても、攻撃を繰り広げておりました。

この方は「俺は、Rubyに対する批判もしているからOK」みたいな態度をとっておられますが、さて、いったいこれは、どうなのでしょうか。

読者の皆様は、Rubyは、過去に、全方位で、ネガティブキャンペーンを行っていたということを、知っておいてください。

さらに2019年、Rubyの開発者様は、Rubyが批判されたときに、「悪いところはPerlからとった」と申しました。

わたくし、これを見てショックを受けました。

しかし、それならば、Rubyの良いところは、どこからとったのでしょうか?

Rubyの楽しい機能を作成するために、参考したPerlの良い機能は、たくさんあるんじゃないでしょうか?

「俺がRailsを殺す」のように、すぐに「殺す」というような非倫理的な言葉を使ってしまう、Rubyコミッタの方もおられます。

「最悪」とか「殺す」とか、無料のオープンソースで、善意でボランティアで作成している作者の方への敬意はないのでしょうか?

RubyとPerlのWebフレームワークの比較

「Perlには代表的なWebフレームワークないしね」

そんな会話がRubyコミュニティで話されていませんか?

Rubyには「Ruby on Rails」と「Sinatra」という代表的なフレームワークがありますが、Perlには、何があるでしょう。

Rubyユーザーの皆様に知っていただくために、PerlのWebフレームワークをご紹介します。(50音順)

• Amon2
• Catalyst
• Dancer2
• Mojolicious
• Plack/PSGI

Amon2は日本の開発者が開発しているフレームワークです。

ちなみに、わたくし、Mojoliciousの開発チームに過去に参加していました。

Mojoliciousのテスティングフレームワークである、Test::Mojoは、わたくしが実装しました。

仲間とともにMojoliciousの日本語への翻訳もやっております。

Plack/PSGIというのは、RubyのRackに該当するミドルウェアです。

Perl/CGIは古いといわれ続けておりますが、実は、PerlのWebアプリ開発の主流は、CGIではありません。

Webサーバーを立てて、リバースプロキシ構成を使うのが、PerlのWeb開発の主流なのであります。

Rubyユーザーの知らないところで、PerlのWebフレームワークも発展しています。

またわたくしの開発しているCMSツールGiblogもWebサイト・ブログを作成するのに便利でございます。

RubyとPerlのパフォーマンスの比較

ネットだけで情報を仕入れている皆様。Rubyは、Perlより速いと思っていませんか?

これは、半分は、本当で、半分は、間違えています。

一般的なベンチマークではRubyの方が速い

よくWeb上ではたくさんの言語を比較した、一般的なベンチマークが掲載されていますね。

再帰呼び出しや、数値計算など、一般的なベンチマークがあります。

それで、PerlとRubyを比較したときにRubyのほうが速いという結果が掲載されていますが、これは本当です。

PerlのVMは、抽象構文木を、直接実行しますが、RubyのVMは、バイトコードを生成して、それを実行します。

Perlのオペレーション実行のノードが、メモリ上で飛び飛びなのに対して、Rubyのバイトコードは、連続的にメモリ上に配置されています。

また、Rubyは、jump命令の実行を、分岐予測を使って、最適化するために、ダイレクトスレッディドコードになるように、最適化しています。

もう一つの理由は、PerlのGCが、リファレンスカウントGCなのに対して、RubyのGCは、世代別GCであるので、スループットは大きくなります。

また、Perlが数値と文字列を区別しないのに対して、Rubyは、数値と文字列を、区別していますから、型の判別という点でも、Perlよりも有利です。

「なんだー、Rubyの完全勝利じゃん」

そう思ったあなた、この話には続きがあります。

大量の文字列処理に最適化されたPerl

Perlのパフォーマンスの最適化は、数値計算や再帰呼び出しに対してされているわけではなく、大量の文字列処理に対して、最適化されています。

ですから、一般的なベンチマークでは、Perlは一見すると遅く見えます。

Perlは、リファレンスカウントGCを実装しており、スループットよりは、レイテンシ(応答時間)に対して最適化されています。

PerlのリファレンスカウントGCは、スコープの最後で、そのつどオブジェクトを解放するので、スループットは下がりますが、平均待ち時間は、良好です。

大量の文字列処理をする代表といえば、Webアプリケーションです。

2017年と少しだけ古いですが、Webフレームワークのパフォーマンス比較を見てください。わたくしが、少し前の調査で調べていたときに、見つけたものです。

PerlのMojoliciousという、プリフォーク + 非同期I/OのWebフレームワークが掲載されています。

Mojoliciousは、フルスタックのWebフレームワークです。RubyのフルスタックWebフレームワークであるRuby on Railsと比較してみてください。

Webフレームワークのベンチマーク リクエストあたり20クエリでの1秒あたりのレスポンス 2017-05-10 ラウンド14

RubyとPerlのメモリ使用率の比較

RubyとPerlでは、Perlの方がメモリ使用率は数分の1程度になるようです。

これは、実装について考えてみると理由は、わかります。

Rubyは、ソースコードを抽象構文木にコンパイルした後、さらに、それを解析して、最適化して、RubyのVMのバイトコードに変換して実行します。

Perlは、抽象構文木を生成したタイミングで、実行を開始しますから、バイトコード分のメモリを使わないです。

また、Rubyは、世代別GCを採用していますから、世代別GCを実行するための、新しいオブジェクトのエリアと古いオブジェクトのエリアを事前に確保しておく必要があります。

Perlの場合は、リファレンスカウントGCですから、メモリ生成のタイミングで、もしあらかじめとっているメモリのエリアが足りなくなれば、拡大するということで済みます。

この二つの理由で、Perlのメモリ使用率は、Rubyのメモリ使用率よりも小さくなります。

RubyとPerlの起動速度

小さなスクリプトを動かしているときは、ほぼ気にならないでしょう。

数千もの大量のライブラリを読み込んだときは、少し差が出るはずです。

でも、これはきっと、ほんの少し。

Rubyは、ソースコードを抽象構文木にコンパイルした後、さらに、それを解析して、最適化して、RubyのVMのバイトコードに変換して実行します。

Perlは、抽象構文木を生成したタイミングで、実行を開始します。

バイトコードへ変換処理をしない分だけPerlの方が速いですが、気にならないレベルでしょう。

Rubyのgemに該当するのは、Perlのcpan/cpanm

RubyにはRubyGemsというライブラリをWeb上に配置して、ダウンロードできる仕組みあります。

Perlにも、これに該当するCPANという仕組みがありますが、RubyGemsはPerlのCPANが発明され成功した後に、それを参考に作られたものです。

「RubyGemsすごい」は、「CPANすごい」にそのまま該当します。

Perlには、cpanの動作を軽くして、バージョン管理とCAPNに加えて、Githubからのインストールも可能なcpanmという優れたツールもあります。

RubyでBundlerを使ってバージョン管理できるように

cpanmを使えば、PerlのCPANモジュールのバージョン管理を行うことができます。

Perlの紹介を極端に避けるRubyユーザー

Rubyに限ったことではありませんが、Perlを参考にして作成された動的型付け言語のユーザーは、極端にPerlへの言及を避ける傾向にあります。

PHPユーザーは、RubyとJavaScriptとPythonを紹介し、

JavaScriptユーザーは、RubyとPythonとPHPを紹介し、

PHPユーザーは、RubyとJavaScriptとPythonを紹介し、

Rubyユーザーは、PythonとJavaScriptとPHP(?)を紹介します。

Perlから多くを参考にしている動的言語、スクリプト言語のユーザー様は、Perlをどうして極端に避けるのでしょうか?

「Perlは古い」「Perlは死んだ」「Perlはトレンドではない」「Perlユーザーは少ない」「Perlはこれから学ぶべきではない言語」

と考えているのでしょうか?

しかし、わたくし、Perlを現場で使って、開発しております。顧客に対してPerlでサービスを提供し、顧客と会社に対して利益を生み出しております。

現場で働く、わたくしの存在を、消してしまおうということですか?

Perlは、現代的スクリプト言語の父や祖父のような存在であるのに、それを無視し、軽蔑しようとするのですか?

学生にPerlを過去のものと信じ込ませ、新規案件にPerlを採用をさせないことに、熱心なのですか?

こういうことをやめて、敬意をもって、公正な競争の元にPerlを置いていただけませんか?

RubyユーザーのPerlへの中傷は、セミコロンにまで及んだ

これは、本当の話ですが、RubyユーザーのPerlへの中傷は、セミコロンにまで及びました。

「毎回セミコロン打つの、小指いたいよねー」

みたいなレベルです。

小学生?

Perlを悪くいってよい雰囲気が、Web全体に広がっていって、Perlに関してだったら、極端に悪く評価してよい風潮が広がりました。

「RubyはPerlを改善したもの」として徹底的に、宣伝されました。そして、Webの表面しか情報がない、無知な学生は、そのまま信じました。

実際は、それは、Rubyの側からの意見であって、事実ではないにも関わらず。

「『$』打つの、めんどくさいよねー。古代語みたい」

そして、どんどんエスカレート。最後には「プっ、セミコロン打ってるの?」みたいな。

Perlの文法はシェルスクリプトとC言語ユーザーが、扱いやすい用に設計されている

Perlの側から援護すると、Perlは、独特の文法を採用せずに、Unix/Linuxで、シェルスクリプト、sed、awk、C言語を利用しているユーザーが、違和感なく、使える用に設計されています。

Unix/Linuxのなじみの記法を、使っているユーザーが、とまどわないで、スムーズにPerlを利用できるように、ユーザーに対して配慮がなされています。

セミコロンや$は、シェルスクリプトユーザーやC言語ユーザーに対するPerlの配慮であり、優しさなのです。

その優しさ設計を、まったく知らずに、まったく評価せずに、中傷することまで進んでしまいました。

いまRubyユーザーは、自分が、PythonユーザーやTypeScriptユーザーに、中傷されて、それが痛いことに、やっと気づいた。

だから、わたくし、このタイミングでメッセージングすることにしました。

2019年現在は、Rubyに増して、ビッグデータ、AI、Pythonによる印象操作、誇大広告が、Webや書店を覆って、学生を惑わしています。

わたくし、Rubyユーザーと戦いたいのではありません。Rubyユーザーは、誇りをもって、Rubyユーザーを続けていただきたい。

解決したいのは、IT業界を覆っている、倫理観の欠如、不公正と無視と軽視と扇動と独占と排除ととか、そういう悪いものです。

もし、Rubyユーザーが、一時的に、これらに関わっていたのでしたら、離れていただきたい。

dhhというRuby on Railsの扇動者

扇動のパターンは決まっています。それが、どこから始まるかというと、シリコンバレーです。

シリコンバレーの投資家に対して、アプローチが成功して、マウンティングをとることができれば、そこから扇動が始まります。

dhhというRuby on Rainsの作者も、シリコンバレーの投資家に対して、アプローチが成功し、マウンティングをとったのです。

スクールカーストでいう上位をとる、そういうことです。

学校における醜い階級主義が、世界レベルで行われているということです。

シリコンバレーには投資家がおり、中国の政府に近い場所にいる投資家、サウジアラビア、イスラエルなどです。

シリコンバレーの企業と、中国の政府に近い投資家は、実際は仲が良いのです。

サウジアラビア、中国の投資家は、スタートアップに投資していましたが、トランプ大統領時代になって、これらの投資が減り、投資が減らされた企業は、力の面で、GAFAに依存せざるを得ない状況になっています。

自然に流行しているのではなくって、権力の力学が働き、大量のお金の流れがあり、そのお金を使って、Webコンテンツ自体に宣伝を埋め込みます。政府にも接触しますし、経済団体にも接触します。

大切なことは、自然に流行している・自然に人気を得ていると、無知な学生に信じこませることです。

人々は、それを吸い込み、心がコントロールされ、誘惑され、一時的な札束で叩かれ、理性を失って、徒党を組み、中傷の段階にまで発展します。

IT技術者は「アドセンス広告を間違ってクリックしない」ということに自信と誇りを持っていますが、コンテンツの中に仕込まれている広告を見抜くことができません。

Webコンテンツには、事実ではなく、大量の資金を使った広告が埋め込まれていると認識してください。

Rubyユーザーを攻撃するgo、python、JavaScript、Rustユーザー

Webのてっぺんでは、10年前から、ずっと同じことが繰り返されています。

Rubyに愛着があり、Rubyで開発しているユーザーに対して、go、python、JavaScript、Rustユーザーは、ネット上でネガティブキャンペーンを繰り広げております。

「Rubyはチームを幸せにしない。これからは〇〇」という言葉を、残してRubyを去っていきます。

Rubyで作った収益がでているサービスを、自分たちの言語で、リプレースしようと、狙っています。

かつて、Railsは、WebのてっぺんをRailsへの賛美で埋め尽くしました。今度はPythonがWebと書店のてっぺんを賛美で埋め尽くしております。

Perlゼミは、こういう不公平で、不健全で、不毛な状況を改善したいと思っております。

Rubyユーザーの皆様は、気持ちがわかってきたと思うので、Perlに対して、やってきたことをどうか反省してください。

プログラミング言語のそれぞれのユーザーは、実際は、本当の加害者ではありません。

PerlやRubyを攻撃していたとしても、その人たちは、本当の意味での加害者ではありません。

もっと上流から「権威と一時的な札束」を使って、エンジニアを分断させて、自分たちが独占的な利益を得るために、悪意を流している大元がいます。

(明日も、明後日も、続くよ)