LLの立ち位置をOSに例えるなら...

Ruby・Python・JavaScriptはLinux、様々なアイデアの実験場となり、

ユーザ数増加中。

PerlはFreeBSD、枯れていてコアなユーザもいるが、ユーザの更なる

増加は望めない。安定を優先するため、実験場にはなりえない。

PHPはWindows、その簡便性でユーザを一気に延ばしたけれど、言語と

しての進化は手詰まり、お手軽言語であることを売りにしたため、(先進的

で)マニアックな言語仕様を導入しにくいorできない。

Perlの場合、互換性を維持するための言語仕様上の負の遺産の継承がその

進化を阻害している(枯れて安定していることを優先して今まで大規模な

言語仕様の改訂を行ってこなかったことが言語としての進化を停めて

しまった)、今や大規模な改訂は大きすぎるイタミに直結する、そのため、

言語仕様上の負の遺産を滅するような改訂をもはや行えない、その時期

を逸してしまった。

現にPerl5.8とPerl6の関係はCとC++の関係よりもVB6とVB.netの関係

に良く似ている、Perl6のOOはPerl5.8の仕様のオブジェクト指向的

側面を見直し、多少、体裁を整えたようにしか見えない。

それでもVB6からVB6.netへの移行時にそのユーザが経験したイタミと

同種のイタミをPerlユーザは経験することになるだろう...。

Rubyのように言語仕様を段階的に改訂する場合、ユーザに多少の混乱は

与えるものの、大きすぎるイタミを伴う大規模な言語仕様の改訂をユーザ

は経験しなくて済む、それを最善とはいえないが...。

PHPの場合、言語仕様が成熟する前に、ユーザ数が急激に増加したことが

不運、お手軽言語として確立した地位を維持していく以外に道はない。

(先進的で)マニアックな仕様のメリットをPHPユーザに納得させるのは

難しい。そのような仕様を導入しても利用されずに終わる可能性大。

続・Perl6は何処にいった

昨年末のアルファ版リリースはならなかったようだ。

Perl6用でも使用されるParrot VMは先月23日に0.9がリリースされ

現在は３月の1.0リリースに向け、開発中。(こちら)。

少なくともPerl6はPerl6自体の中間コードコンパイラとPerl5互換の中間

コードコンパイラの両方が実用レベルで動作する必要があるため、この

２つが実用レベルで実装されるまでリリースされない。いつリリース

されるかは已然不明。

中間コードコンパイラは任意の言語をParrotバイトコードに変換する

コンパイラをここでは指します。

Perl6は複数の言語を利用できる夢の言語のようにPerl6使いの間では

思われていた節もあるようだが、この夢物語を現実にするには、それ

ぞれの言語に対して中間コードコンパイラが必要であり、実用レベル

の中間コードコンパイラのある言語は何処にも存在しない現状では

当分の間は夢物語になりそうである。最低限必要なPerl用のコンパイラ

でさえ実用にほど遠い現状では。

Parrotは実装が開始されてから、かなりの年数がたっており、先進的な

VMとはよべなくなっている。

Parrotは今や数あるVMの一つにすぎず、他のVMを圧倒する性能と

いうわけでもない、Parrotに格別の思い入れのあるエンジニアでも

なければ、Parrot用コンパイラを書く事はないと思われる。

それを証明するかのようにPerl以外のParrot用コンパイラの実装は

遅々として進んでいない(実験的なモノを除く)。

Parrot.orgのlanguagesのリストに記載されている中間コードコンパイラ

のほとんどは実装途中で開発が停滞・停止あるいは放棄されている。

Parrot用にPerl以外の言語の言語仕様を満たすコンパイラを書く

ことに意義を見いだすエンジニアがこのさき、多数出てくるか

甚だ疑問。

以前、Perl６はParrotVMへの移行よりも現行VMベースでの実装を

先行したほうがいいのでは、と書いたが、現行のPerl5系をParrotVM

上に実装、Perl5.12(?)として公開してからPerl6を進めるのが現実解で

あると今は思う。

Perl5系のParrotVM実装(5.12)、PerlのOO言語化(6.0)、現行のPerl6

仕様のOO言語化以外の機能の実装(7.0?)くらいが妥当ではないだろう

か？

Rubyの場合、アグレッシブな変更を伴う予定で仕様の確定しない

Ruby2.0を先送りし、代わりに1.8仕様の改良版をYARV上に実装する

現実解を開発陣が選択した。それが功を奏し、安定板である1.9.1が

既にリリースされている、１年以内に実運用に耐える段階に達する

だろう。Ruby2.0で予定されていた機能が1.9系に取り込まれながら、

段階的に2.0(理想形？)に近づいていくと思われる。

Perl開発陣もPerl6のリリース時期が確定できないのなら、現実的な

ロードマップを模索してはどうだろうか？

たのしいCocoaプログラミング[Leopard対応版]

http://d.hatena.ne.jp/asip/20080905#1270774559

ECMA Script(≒JavaScript)の次期仕様に大変動

http://d.hatena.ne.jp/asip/20080818#1270774839

大阪桐蔭、優勝

１点を争う接戦になるかと思っていたので、あの展開は予想外だった。

在学時、初出場初優勝のとき、３年以外の在校生全員で甲子園で

応援したのも今はいい思い出、応援合戦のときは絵文字のパネル

の一枚を持ってました。

24時間365日サーバ/インフラを支える技術

高負荷サイトを実際に運営されている会社の方がこの本を

執筆されていることは勿論、この本をレビューして自分の

ブログの書評で高評価をされていた方もいたので購入しました。

発売前にAmazonで注文し、発売数日後に届きました。

自分(たち)のノウハウを公開しないポリシーの人間(会社)が

多い中、高負荷サイトのインフラ構築の技術的なノウハウ

が技術者の視点で詳しく書かれているこの技術書は

かなり貴重です。

読み始めたばかりですが、良い本です、勉強になります。

WEBサービスサイト等WEB系システムのインフラ構築に

携わろうとしている技術者だけでなく、インフラ上で動く

システムの開発に携っている(あるいは携わろうとしている)

技術者も読むとかなり勉強になる本だと思います。

今日の大阪桐蔭×東邦の試合、ABCテレビのアナウンサー、アナウンサー失格

あのABCテレビのアナウンサー、東邦が８・９回にチャンスを作ると

異様に東邦を持ち上げ、しまいには部員数まで持ち出して、個人的に

東邦の逆転を願っているのか東邦の逆転が既定路線のような発言まで

する始末、アナウンサーは中立が本分違うんかい、とむかついた。

おまけに、試合後に「桐蔭が相手のミスに"つけこんで"得点を重ねた」

(「桐蔭が相手のミスを上手くついて得点を重ねた」と発言すべきところ)

「一本(ホームラン)が出れば桐蔭を立ちすくませることができた」

等の発言をする始末、あのアナウンサー、アナウンサー失格。

何故、むかつくかというと大阪桐蔭は母校だから。自分の在学中あたりは

並の進学校だったけど、卒業してから数年後に中高一貫にしてから

進学校としてかなり躍進したと風の噂で聞いた。

ちなみに野球部等体育会系は別コースとなっていて、文武両道というわけ

ではありませんでした、在学時。今も別コースのまま変わっていないと

思います。

今回に留まらず、本来中立であるべきアナウンサーが自分の個人的な見解

や自分の考えで発言するようになっている、放送局の堕落だろうか？