続・Perl6は何処にいった その8

未だ、未リリース。

仕様を満たす実装が何処にも存在しない。

いつの間にか、Parrotは半分過去の遺物となり、
JVM上でのサブセット実装が登場。

そして、今年の5月にPerl6用にMoarVMが
表舞台に踊り出る。。。今はその上に
Perl6のサブセットが実装されつつ、開発
進行中。

実用に耐えうる実装が登場するのはいつの日か？

Perl6の仕様"黙示録？"自体が過去の遺物と
なりつつある現在、仕様自体の見直しが
急務な気がする。

少なくとも、実装もなしに机上(の空論)だけで
策定された一部の仕様はこの際、すっぱり
捨てたほうがいいんではないだろうか？

昔の机上だけの実装の存在しない仕様策定で
深みに嵌っていたW3Cを彷彿とさせる。
(実装もなしに頭のなかだけで転がされた仕様は
往々にして実装を考慮しないモノとなる。)

過去の資産を顧みず、RubyやJavascriptの良い
ところを取り込む、大胆な仕様改訂をすべき
時期にPerlはきているのではないだろうか？

今のままではPerlは明らかにレガシーであり、
モダンな言語とはいえない。

続・Perl6は何処にいった その7

あれから一年...以上、リリース等の話題は聞こえてこない。

ベイパーウェアとなって久しい、というか、はじめから
ベイパーウェア。

数年前に発表された仕様ももはや現在のニーズに
マッチしたものではない、ものの、仕様改訂の
ニュースもない。

Perlはもはや過去の遺物なのか？
現状ではそうとしか思えない。

【蛇足】
Perl6のサンプル・スクリプトをみてダサいとは
思っていたが...(特にハッシュがほぼ剥き出しの
クラス周り)、実装がでてこないのでは評価の
しようがない。

クラス周りはJavaScriptのほうが余程洗練
されている。

続・Perl6は何処にいった その５

Rakudo Star、6月も中旬になったけど、リリースの気配なし？

第２四半期リリースのはずだが？このまま、第３四半期に延期か？

続・Perl6は何処にいった その４

http://www.publickey1.jp/blog/09/perl5perl6perl2.html

http://www.publickey1.jp/blog/10/perl_5_perl.html

PerlはPerl5系とPerl6系の実装の２つにメインストリームが

分岐することになっていた模様。

その結果、Perl5系の実装は既存の実装とRakudoに

組み込まれている(?)Parrot利用型の実装が並立

することになる。

この並立はリソースが分散するだけでなく、その同期

にコストが掛かるので、効率が良いとは思えない。

傍からみていると、Rakudo組み込みのParrot利用型

のPerl5実装を別プロダクトとして分離し、そこに

リソースを集中させたほうがPerl使いは幸せになれる

ような気がする。

シナリオ的には分離したRakudo組み込みのParrot利用型

のPerl5実装を現行のPerl5実装の後継と位置づけ、リソース

を集中、短期間での安定版のリリースを目指す。Rakudo

開発者と緊密に連携し、Rakudoに簡単に組み込めるように

しておくと、Rakudo開発者はリソースをPerl6実装に集中

でき、Perl6実装の開発の進展に繋がる。

続・Perl6は何処にいった その３

その２の後、Perl6の仕様と実装を切り離す方向で話が進んだらしい。

Perlの産みの親であるラリー・ウォールは実装には直接タッチせず、
仕様策定に注力する模様。

Rubyと違いPerlには実用に耐えうる実装が一つしかない、
仕様と実装を切り離すことに今更何の意味があるかは謎。

とりあえず、今月、Perl6実装の本命?Rakudo初の安定版"Rakudo Star"
が公開予定。

少なくともPerl5系のParrotコンパイラが完成していないと使い物には
ならないと思われる。

Perl6実装の痛いトコロは過去の資産を維持するために、必ずPerl5実装を
内包しなくてはならない点。

VBでCLRが採用された時点で、マイクロソフトがユーザーの過去の資産を
切り捨てたのとは対称的ではあるものの、賢い選択かは疑問。

Rakudoの場合、Perl6系のParrotコンパイラと並行してPerl5系のParrot
コンパイラを作成しなくてはならず、Perl5系のParrotコンパイラが完成
していないと実用には至らない。

"Rakudo Star"はPerl6仕様の基礎部分は実装しているだろうが、
Perl6仕様の完全実装ではなく、あくまでPerl6仕様の部分実装。

Rakudo自体は何回かのリリースで徐々にPerl6仕様の完全な実装に
近づけていく予定らしい。

"Rakudo Star"が出れば、アーリーアダプター以外も試用する、
Rakudo初の試練がやってくる。

ParrotがPerl5実装と同等の処理速度を叩きだせているのか、
それがPerl使いにとって最大の問題ではないだろうか？

Perl6の仕様、余所者からみると過去のレガシーな遺産を引きずりまくって
いるようにみえる。あの仕様のまま、実装されているのなら、個人的に
使う気にはなれない。数年も経てば、要求される仕様は変化している
と思われるが、Perl6の仕様が大きく変化したというニュースはない。

「SIerの解体と再生」を読んで

>この不景気をきっかけに、発注側のユーザ企業に

>変わってもらいたい。

他力本願。根本的に間違ってる。

ユーザ企業の前にSIerが変わるべきだろ...。

とにかく数で押す人月商売からの転換が先。

人月商売の中では数が正義だから、真のプロ意識のない

「なんちゃってエンジニア」が生息できる。

少数の精鋭が頑張って多数のなんちゃってエンジニアを

支えるスタイルから少数精鋭スタイルへの転換。

数だけは揃えて後は現場にお任せがまかり通っていて、

現場に少数でも精鋭がいなければすぐに破綻する。

だいたい、精鋭だけを揃えれば10人もいれば納期内に

完成できるシステムを玉石混交(ほとんどはなんちゃって

エンジニア)で数倍の人数がいても納期内に完成できない

ケースがざらにある現状が異常。

これから数年のSI業界不況でなんちゃってエンジニアは

黙っていても淘汰されるだろうが...。

次に実装屋よりも設計屋が偉いという間違った思考回路

の是正。

実装屋と設計屋はベクトルが違うだけで本来その間に

優劣の違いはないにも関わらず、SIerの中ではクライアント

と会話して外部設計を行う設計屋が重視され実際の実装面を

担当する実装屋は軽視されてきた。

本来は車の両輪である筈の設計屋と実装屋、SIerの中では

設計屋のみが即席培養され実装屋は育成されてこなかった。

その結果、SIerの中には実装のプロがほとんど、いない。

外部仕様はそれなりに立派でも実装がヘタレで使い勝手の

悪いシステムが多数量産されてきたし、きているのが

現実。

実装屋と設計屋を対等に位置づけ、それぞれの社内での

職位を設計しなおすくらいの大変革が必要。

SIerの中で実装屋と設計屋を兼務するオールラウンダー

の育成はまず無理。

オールラウンダーの育成を目指しても、中途半端な

似非オールラウンダーができあがるだけ。

設計にも実装にも特化しない中途半端な似非

オールラウンダーが跋扈するから実装がヘタレで

使い勝手の悪いシステムが多数量産される結果

になる。

それなら、SIerの中で実装技術には疎いが顧客との

対話が得意で顧客の代わりに要求仕様・外部仕様を

纏める設計屋部門と実装技術に特化し内部仕様以降を

担当する実装屋部門を明確に分離するか別会社化した

ほうがよい。

そして、社内では設計屋部門と実装屋部門を独立採算

制にし、顧客に対しては設計屋部門と実装屋部門で

別契約にする。

SIerの中では設計工程と実装工程の責任を明確に分離

し、責任の所在を不明瞭にしたまま設計工程の失敗を

実装工程で補填する悪しき慣習をなくすことに繋がる。

独立採算制にすれば、設計工程で失敗があった場合、

設計屋部門から実装屋部門に金銭の移動が発生する

ことになるので、責任の所在を不明瞭にしたままとは

ならない。

設計屋部門と実装屋部門に分割すれば、設計屋部門は

外部設計のプロとして外部設計に特化し、実装屋部門は

実装のプロとして内部設計・実装に特化すればよくなり、

それぞれの部門でその部門に適した人材を育成すれば

よくなる。

現状、SIerでは実装のプロではない設計屋か似非オール

ラウンダーが実装の指導を行うので、実装のプロが育つ

はずがない。

ここでの外部設計は実装を意識しない表層の設計、

内部設計は実装を意識した深層の設計を指します。

更に無意味な中間管理職への過度のインセンティブ

の撤廃。

実務にほとんど従事せず管理だけを行う人員が

SIerには多すぎる。

PMにしてもPLにしてもマネージメントが上手いか

どうかの指標が一人歩きして、過度に評価されすぎ

ている。

PMにしてもPLにしてもその管理手腕が卓越していて

全体が上手く回っているのは稀、ほとんどの場合、

PMやPLが実務を割り当てる際にできる人間に本来

こなすべき量より多くの作業を割当、その人間を酷使

して、全体が上手く回っているかのように帳尻あわせ

しているケースが多い。

つまり、PMやPLの管理手腕が優れていてプロジェクトが

回るのではなく、できる人間(数人)がいてそこに作業負荷

を集中させることができるからプロジェクトが何とか

回っているケースが多い。

会社としてはプロジェクトの実態はどうでもよくて

プロジェクトが表面上、上手く回っていれば問題なく、

実際の管理手腕は問われない。特定の個人(数人)に

作業を集中させてその犠牲？でプロジェクトを回して

いるPMやPLであっても、高く評価されるし、されてきた。

推敲中...。

「PHPを叩く人にガツンと申し上げたい」を読んでふと...

ttp://d.hatena.ne.jp/higayasuo/20090707/1246940526

>すべての国民は何か一つ言語をマスターしなければ

>いけない。

>※ただしモテ言語に限る

日本国民の99%(?)はある特定のモテ言語をマスター

している。その言語の名は日本語、日本で一番の

モテ言語。

日本で２番めモテ言語は英語。

他国もまた、母国語と呼ばれるその国一番のモテ言語を

ほぼ全ての国民がマスターしている。

プログラミング言語は言語としてはどマイナー、

プログラミング言語にモテ言語と呼べるモノは

存在しない。