みんな昔は厨房だった
僕がmono開発に関わるようになった動機は、仮にもCLI/.NETが技術標準であるならば（しかも優れた技術であるのだから）、その唯一的な実装であるMS.NETの間違いを正せるだけの競争力のある実装を作るのを手伝ってみよう、と思ったからであって、別にMS.NETで動くアプリケーションをそのままLinuxでも動作させるなんてことには、（面白いとは思うけど）それほど興味は無い。だから、正しい実装のMonoをbuggyなMS.NETに合わせろ、なんていうのは、僕にとっては敵そのものだ。このスタンスは関わり始めるずっと以前の2002年頃から変わっていない。
ま、そんなん僕だけなんだけど。
でも敵もまた強い…というか執拗でもう疲れた。時間の無駄だしもうbuggyにして終わりにしようかと思っている。ユーザーのモラルなんて所詮そんなもんかね。
ていうか、ユーザーのモラルが低いのは別にかまわないけど、プロジェクトの価値を勝手に決められては困る。
でもまあどう考えても本質的ではないedit & continueなんかに少なからぬ開発リソースを費やしてしまっているMSの開発者に比べれば、こっちはずっと恵まれているよなぁ。
中の人曰く
16:10 (eno) whoa, kazuki fixed the xpath bug I posted
16:10 (eno) I should hire him to work instead of meネタはコレ
うーん、三人称複数現在形でもsが付いちゃうおれさまちゃんの英語ってステキ。
コメント
ladybug — 02/09/2005 04:13:59
MSの実装にあわせる必要なんてないと思うんだけど、仕様や文面の互換性よりも、それが動くことの互換性を求める人が多いのはわからんでもないかなぁ。
個人的にはMSの実装を正としないで、MonoにはMonoとして正とする実装があって欲しいですね。
ソースコードが #if __MonoCS__ だらけで、成果物も for MS と for Mono で異なるアセンブリというのは好ましくないでしょうけど、#if __MonoCS__ に頼らないで双方で動くコードを書ける場合も多いだろうし。
＃ 互換性があがるオプション設定、というのは解の１つかもしれないけど歓迎しないなぁ
atsushieno — 02/09/2005 06:15:44
ええ。まあ一番手っ取り早いmonoの価値が互換性にあることは僕も認めますけどね。ところで__MonoCS__定数の存在をご存じとはけっこうマニアックですね(笑