CNET Japanの記事によれば、 アメリカの新興企業ClearMethodsが XML処理用プログラミング言語である「Water」を発表したとある。 正確にはWaterの新処理系Steam*1が発表されたということのようだ。
昨年、LL2に参加した時にClearMethodsの人たちに会った。Waterは
が素晴らしく、XMLプログラマはXMLの文法だけですべてが処理できる、のだそうだ。 書籍の出版も決まっているそうだ(Addisonだったかな。もう出た頃か)。
私が会った人は(もう名前忘れちゃったけど、たぶんCEOのMichael Plushc)、 もう典型的なアメリカのベンチャー系ビジネスマンって印象で、 Rubyの開発者ってことでつかまっちゃったんだけど、 「うちの言語は素晴らしい」とか 「日本でビジネス展開したいから(NaClと)提携したい」とか、 「でなかったら、誰か紹介してくれ」とか、 押しが強くて勘弁してって感じ。
なんとなく「Xiとどこが違うの」などと思ったけど、なにも言わないでいた。
で、プログラミング言語としてのWaterについてだが、正直あまり関心が持てなかった。 理由は、なにより「XML文法の言語が正しいアプローチとは思えない」という点が大きい。
もちろん、eRubyの嬉しさから類推して、
言語が嬉しい局面はあるだろうなとは思うが、
ということで魅力を感じない。
あと、
というような点も私としては障害になる。
結局、LL2でのDan Sugalski(Parrot開発者)の発言、
フリーの処理系のない言語はだめ。 LL1で発表があったCurlのこと、今年は聞かないじゃないか。
に私も同意してしまう(Curlがどうなったかよくわからないんだけど)。
まあ、考えてみれば、言語関係のビジネスは死屍累々で、 生き残ってるのはマイクロソフトとボーランドだけ(いや、ボーランドはもう言語屋じゃないか)。 よっぽどのことがない限り、あるいはよっぽどのことがあっても、手を出すもんじゃない。
教訓: 言語はビジネスにならない
教訓2: 言語設計者の生活は厳しい
*1 しかし、Steamだからといって温泉マークってのはどうかと思う
ひさしぶりにCD-ROMを読もうと思ってドライブに入れるとディスクの回転が途中で止まってしまう。 どうやらドライブがおかしいらしい。故障か。
まだ1年はたっていないと思うのだが、保証書あったかな。
emacs lispでメールオーガナイザーのフロントエンドを作ろうと思ったが、 バックエンドのバグを見つけてしまい、そっちにかかりっきり。
Estraierのバージョンを1.2.17にあげる。 以前、要望していた属性も検索対象に含めるオプションが増えていてハッピー。
..が、重い。いや、風博士から起動されるestindexが重い。 私の非力なマシンが悲鳴を上げる。っていうか、Ｘ落ちちゃったし。
ソースを見るにg_idle_add()でestsearch_update_index()を登録しているのだが、 この頻度が高すぎるようだ。同時にいくつもいくつもestindex registerとestindex relateが動いている。
しょうがないので、estsearch_update_index()をちょっとハックして、 前回の起動から１時間たっていない場合にはestindexを起動しないようにした。
でも、本来なら風博士はキャッシュに新たに入ったファイルが分かっているのだから、 estindex register -list - にファイル名を渡すとかでもっと軽くできるんじゃないかなあ。
届いた。予約の関係でバンクーバー空港に9時間以上も滞在する必要がある。 格安チケットだから原則として便の変更ができないんだよなあ。 一応、空港で交渉してみるつもりだけど。
一昨年バンクーバー空港を利用した時には無料で無線LANが使えたけど、 2年経っていると状況が変化しているかもしれないよなあ。 ネット＋電源があればどこにいても大抵のことはできるのだけど。
こちらもそろそろ予約しないとな。 今回はRubyCentralが航空料金を負担してくれるそうだ。 自腹で行こうという人も多いのに、ちょっとだけ心苦しいところもある。
なお、David Alan Blackから依頼を受けたので以下のページを紹介しておく。
RubyCentralはRubyConfのスポンサーを募集しています。
今日は初校の修正。日経Linuxは書いた時が集中の直後で、 気が抜けて分量の計算が間違っていたせいか、 3/4ページ、75行も削る必要があった。せつない。
結局、図をふたつ削って説明を一部はしょってなんとか収めた。
もうひとつの原稿(技術評論社)もなんとか片付いた。
先日の記者会見ネタ。高橋さんはどこでこの内容を仕入れたんだろう。
ま、そんな感じです。こっちの方が先日の山陰中央新報よりも具体的な内容になっている。
しかし、「このインターネット全盛の時代に物理的な位置は関係ないだろう」という意見も あるだろう。しかし、逆に地理的な制約から解放されているからこそ、 そのままでは圧倒的に不利な田舎でもビジネスが成立できるとうことだと思う。
インターネットやオープンソースなど、新しい動き*1を使って、地方ならではの不利な状況を跳ね返すテコにしたい。
もちろん、この協議会をいろいろな形で「利用」してもらっても構わない。 すでに画策している人もいるようだ。
*1 実際にはインターネットもオープンソースもさほど新しくはないわけだが、一般の人が知るようになった、とか、ビジネスに成立するようになったのは最近である、というような意味
浮動小数点表現といえばIEEE754と言われるようになって久しいわけだが、 これが最良であるというわけではない。 というわけで、日本発の浮動小数点表現URRの紹介。
これをx86アセンブラで実装したものもある。
ただ、Rubyも含めて あまりにも多くの浮動小数点ハンドリングでInfやNaNが使われているので、 これが普及するための障壁は大きそうだ。
そういえば、VAXはIEEE754ではないので、 Rubyがときどき変な動きをすることがあるらしい。
Google Tech TalkでGuidoがPython 3000について語るビデオ。 1時間強の講演を英語で聞くのはヒアリングの練習になる。 元々かなり興味のある分野だし、 ほとんどすべてすでに知っていることだから、 聞き取りや語彙に問題はないし。
ま、全体的にはよりRubyに近づくような感じなのだが(Unicode以外)、 generatorの多用は我々よりさらに踏み込んでいる。
Rubyも、1.9(2.0)ではEnumerableの返すArrayをなにかLazyListのようなものに しようかなあ。そうするとその辺で遅延評価ができて嬉しいことがある、かもしれない。
あと、Ruby流のIOについてもいろいろ考えないといけないと思った。
GuidoはPythonのIOをByte入出力とテキスト入出力を分離して、 「Java風にする」と言ってたけど、私の知ってる範囲では JavaのIOはなんか繁雑で真似したいものではなかったんだけどなあ。
明日のイベントに備えて打ち合わせ。 正直、打ち合わせは面倒だが、まあ、重要なイベントなので。
ToDoリストのエントリの抽象度があまり高いと 実行できない。細かく分割し、部下への指示であるかのように書き下すと 達成率が上がるという話。
まあ、実際には私はそういうレベルにさえ届いていないのだが。 とりあえず今日の仕事は手元のA6ノートに書き出すことで達成できているのだが、 何日にも渡るような長めのissueは忘れてしまうこともしばしば。
なんかツールの支援が必要だと思うのだが、 Remember the Milkもどうも定着しないんだよなあ。 なにがいけないのかなあ(たぶん、意識の低さ)。
XMLのPythonっぽい表現。 ドキュメント表現としてのインデントはそんなに嫌いじゃない(YAMLとか)ので、 SLiPもなかなか良いんじゃないか、と思う。
ただねえ、こういうXMLの別表現はなかなか定着しないんだよねえ。 結局、
ということなんだろう。
こうして地球温暖化が進んでいく(いや、もちろん冗談だけど)。