Perlの正しい潰し方

perl ruby_dis

Perlを潰したい他の言語の派閥の人に教えてあげます。Perlの正しい潰し方を。
まず言語自体を潰すのは難しいと考えてください。
いいとこ取りして出来た言語なので、致命的な欠点がありません。
狙いどころは開発体制やコミュニティなどです。

過去に失敗したが、そんなに無茶ではない方法

最初に何個か便利なライブラリをPerlで作ってリリースしてください。
#perl-users, #perl-casualの両方にアナウンスするのをおすすめします。
これでPerlコミュニティに潜入できます。
自分の作ったライブラリを標準添付してくれと言い張ります。#perl-casualで議論することを勧めます。
#p5pではコミュニティのメインストリームでしか議論が起きません。
拒否されたら、それまでに追加された標準添付ライブラリの採用根拠を説明させます。
ライブラリのメンテナ一覧を出してくれと騒ぎます。
#perl-casualではそんな事を知らない人も居る思うので、そこをつつきます。
感情的にならなければ(ここを私は失敗しました)、かなり開発体制についてダメージを与えられます。

社会的な信用をなくさせる

言語としての美しさだとか、速さなどは世間はあまり興味がありません。
狙うのはセキュリティです。脆弱性です。これなら世間的にはニュースのネタになります。
なにしろかなり大きな企業であるAmazonでPerlを採用しているからです。
Perlに脆弱性があったらAmazonにも脆弱性の影響がでるはずです。
狙うなら、やはり脆弱性ですね?
脆弱性を探すのは、いますぐはじめてください。
脆弱性の面で本気のチェックをうけたライブラリはほとんどないはずです。
あるならopensslくらいでしょうか。
たぶん、何個か脆弱性が見つかるでしょう。
でも、すぐに報告してはいけません。
効果的なタイミングを狙います。
脆弱性報告の効果的なタイミングはリリースしてアナウンスして世間がバージョンアップした直後です。
リリースして3日〜1週間後くらいがいいと思います。
溜めていた脆弱性のうち、軽いものから一つずつ報告していきます。報告するときは発見者はそれぞれ別の個人ということにしましょう。
標準添付ライブラリの脆弱性対応程度ではPerl本体のバージョンアップは行われませんが、新しいバージョンが出るたびにまた3日〜1週間毎に徐々に重度な脆弱性を報告していきます。

世間的にはバージョンアップしてすぐに脆弱性がみつかり、対策しても該当するモジュールだけ差し替えれば良いんだなととられます。
脆弱性を3つ見つけたなら、1ヶ月もたたないうちに多ければ3回ものバージョンアップを、該当するモジュールを使ってなければ対応さえ不要です。

もうPerlの社会的な信用は底までいきます。
信頼を回復するにはかなりの長い時間が必要です。

財務面を攻める

お金の流れをはっきりさせます。
JPAスポンサーの出したお金が最終的にどこに流れるかを追求します。
サーバー維持費などは攻めようがありせんが、人件費については攻められます。
開発は労働です。労働には報酬が必要なはずです。
ですが、コミッタなどには支払われていないはずです。あくまで請負という形のはずです。

JPAでの地方勉強会に講師派遣制度を利用した、特定の人に資金が流れていることになるでしょう。

それをコミュニティに問いかけます。「これでいいのか?これが正しいのか?」

これだけで十分でしょう。

規格としてのUnicode、標準添付ライブラリであるEncodeの関係をはっきりさせる

UnicodeはJIS規格になりました。

ですが、規格になったのはコア部分だけであることを強調します。

また現在、Encodeが唯一の実装ではないことも強調します。

規格としてのRubyとCRubyとの違いを調べて強調します。「規格に準拠していないじゃないか」と。

find_encodingなんて規格にないんですけど?

Encode::UCSなんてクラスもありませんね?

$^ENCODINGってなんですか?

Bindingなんてありません。

攻める場所はすぐにみつかりますね?

Perlはいつ潰れてもおかしくない

かなり無茶をやってきています。

叩けばほこりはいくらでもでてきます。

楽勝でしょう?

参考文献：Rubyの正しい潰し方 - 嘘か本当かわからないどうでもいい話