[ruby-core:01564]では9月30日に出すと宣言した1.8.1 preview1ですが、 10月3日現在まだ出ていません。 これはいくつか直したいバグがあったからです。
現時点で残っているものは
くらいでしょうか。[ruby-dev:21336]と[ruby-dev:21406]については、 なかださんからパッチが出ているので、当てるかどうか判断するだけなんですが。
あと、[ruby-list:38434](ブロック引数の評価順が左から順でない)については、 現在の実装では直すのは難しいですね。[ruby-list:38435]もそんな感じ。
Rubyカテゴリでよいのかな。
明日からのRuby温泉ミーティングにむけて、高橋さんが、わがNaClを訪問なさる。
午後は、わたし、高橋さん、前田くんで、与太話に終始したのだが、 付き合わせてしまってもうしわけなかったか。
それぞれが誰の台詞かは自由に想像してください。
息子が久々に具合が悪いので、夕食はご一緒せずに帰る。明日に備えよう。 って、なにを備えるんだ？
断食安息日。ひさしぶりの松江のような気がするが、実際はそんなでもない。
日曜学校は山上の垂訓について。短い部分を丁寧に扱う教師のやり方に非常に共感を覚える。
午後からは訓練集会のため岡山に移動。山陰から2時間の訓練集会のため、片道3時間書けるのは辛いわ。 私が運転したが、結構体力削られた気がする。
内容は充実していた。が、自分のやり方を変えることを求められる時に、 人は思わず反発を感じるものだな。自分の感情を制御することが必要とされたのも事実だ。
これは海外のデータだから日本の状況はだいぶマシだと思うけど、 それでも2011年のアナログ放送終了時にはかなりもめるだろうなあ。 しかも(一部見直しの動きはあるとはいえ)原則コピーワンスなんだよね。
再生機器もないし、HDは要らない、SDでいいから以前の自由度をくれって人は多そうなんだけど。 日本にはフェアユースという概念はないらしいし。
1.8.2相当の仕様を持つRubyインタプリタ。私のコードは一切入っていない(文法はparse.yをベースに変換したらしい)。私は使ったことないんだけど*1、使い勝手はどんなもんなんだろうか。
*1 そういえばLarry WallもPugsを使ったこともソースを読んだこともないと言ってたなあ
大新聞社のインタビューを受ける。なんか取材なんて滅多に受けないのに ある時には重なるものだ。
OSSについて正直なところを話す。 が、あまりにも普通なので記者の人はちょっと不満げに見えた。 もしかしてなにか期待していらっしゃったことに応えられなかったかしら。
元ミラクルの小田切さんが会社をはじめたという話。
昨日の日経コンピュータとの取材で、自分でOSSをハックするわけにはいかない 情報システム部は「OSSを使ってなんとかできる」人たちをつかまえる必要がある(ソフトウェアはどんどんコモディティ化するから)とかいう話をして、 それの受け皿となるOSSサポート企業というのはこれからニーズの高まる分野で ビジネスチャンスがあるのではないか、という話をしたのだが、 この「オープンソース・ソリューション・テクノロジ」はそれに対応するものになる、のかもしれない。
最近、Webで公開されたYuguiさんの記事「Rubyを仕事に使うべし！」に対して、それじゃ「使うべし」をちゃんと説明したことにならんだろう、という反応。
いや、まあ、その批判は当たっていないこともない。私自身は「Rubyを仕事に使うべし」とは必ずしも思ってなかったりするんだけど。
が、(たぶんワザとだと思うんだけど)この批判そのものが「なにができるか」ということを ベースに論が構成されている。が、正直な話、言語の比較で「なにができるか」を 比べるのは不毛なんだよね。だって、大抵のことは大抵の言語で「可能」なんだもの。
最初にはっきりさせておかなければならないのは、 仕事で使う言語(というかツール)を選択する時に、 「その言語になにができるか」という基準で選ばれることはマレである。
重要なのは、教科書があるかとか、プログラマが確保できるかとか、 必要なライブラリが入手できるかとか、IDEがあるかとか、 その言語を気に入ってる上司がいるかとか、 話題になっているかとか、そんなことであって、 ある言語がどのような機能をもっているかではない。
そういう意味では「Rubyを仕事に使うべし！」というタイトルの記事は、
とかいう話題を中心にした方が効果的だったと思う。
それはそれとして、「どこまで本当か」というエントリの方は 些細な文法の違いから来る記述力を無視しすぎだと思う。
Rubyなんかよりも、もっとずっと本格的なメタプログラミングのできるCLOSとかで書くべきでしょう。
とか
この程度のわずかなシンタックスシュガーで、それほど生産性に大きな違いがでるのでしょうか？
とはいえ、おそらく「計測できる生産性」での差は出ないだろうと思う。 しかし、「計測できない生産性」では大きな違いが出るのではないだろうか。 気分とか。
そして、(たぶん不幸なことに)ほとんどの場合生産性は計測不能なのだ。
ま、それもこれも仕事に使える言語を自分で選べて初めて言えることなのだが。
追記
このエントリについて、fromdusktildawnさんから批判されちゃいました。 「ありもしない錯誤をでっちあげて批判している」のだそうです。
そう指摘されてあらためて引用部を見返すと、確かに
RubyとCLOSでは、シンタックスの違いに起因する生産性の差なんて、少ししかないよ。
と読めるように引用してますね、私。これは私の落ち度です。 原文へのリンクが あるので前後はそちらで読んでいただけるだろうという甘えがありました。
引用の仕方がまずかったことについては謝罪します。
実際には、二つの引用部は独立して引用したつもりで、前者は
(書き込み系)メタプログラミングしたいならRubyよりもCLOSだよ
後者は
RubyとC#では、シンタックスの違いに起因する生産性の差なんて、少ししかないよ。
という主張が読み取れると言いたかったのでした。
で、その主張に対して
ということが言いたかったわけですね。要するに「Rubyは間口になれる」と。
間口をくぐった後は、Rubyにとどまるもよし、SchemeやCLOSに進むもよし、 あるいはHaskellのような関数型に進むもよし。 それはユーザの自由でしょう。
間口になるためにはCLOSやSmalltalkは本格的すぎ(多くのプログラマにとって日常とのギャップが大きすぎる)、PHPでは「上」とのつながりが薄すぎて「面白くない」。これがRubyが「ウケる」理由なんじゃないかと(Perlも確かに「上」とつながっているんだけど、そこはそれ。ねぇ)。「今そこにあること」という弾さんと同じような結論になっちゃいましたね。たぶん、PythonもRubyと似たようなポジションにあるのだと思います。
思い立って、とうとうブロックパラメータについて
という修正を実現した。ずいぶん悩んでいたわりには 実際に手を動かしたら30分で実現できるというのはどうよ。
他の悩んでいることについてもそうなのかなあ。
いずれ世代は交代する。企業でも家族でも。 それについてどれだけ備えることができるか。
時として、非常に長い(数十年とか数百年とか)スパンの視点に立つ必要があるのかもしれない。 ま、聖書とか見てると数百年が一行で過ぎたりして、新鮮な気持ちを味わうことがある。
昔、並列性を重視したコンピュータtransputerというものが存在していて、 Occumという標準プログラミング言語を採用したりして いろいろと注目されていたのだが、いつの間にかあまり話題にならなくなってしまった。 技術的にはいろいろ面白かった(らしい)のだが。
で、今回紹介するTransterpreterは、並列を意識したインタプリタ、
ということらしい。「The Transterpreter is a small, portable, open-source runtime for exploring concurrency」というキャッチフレーズ。
要するにフットプリントの小さいOccumOccamインタプリタということなんだろうか。
Windows, Mac OSX, Linuxで動作し、 LEGO mindstormのプログラミングもできるということだ。
ソースコードも公開されている。ライセンスはGPLv2。
うーむ、このところ睡眠時間はだいたい4,5時間だものなあ。 早死にするかも。
休日はけっこう寝てばかりで取り返してはいるのだが、 一説によると寝溜めはできないらしいし、 家族には不評ではある。
もう少し暇になりたい。
ISO-8859-1とUTF-8の混同により、ニュースリーダー(slrn)で文字化けが発生して怒っている、という話。
我々がここ30年苦しんできたことが、西洋では今、再現されている。
Ruby on Railsの採用を正当化する(ボスに説明する)ための 参考になるリンク集。ぜんぶ英語だけど。
「だって気分がいいんだもの」とか、 「話題の技術だから」という以上の理由付けが必要な時のために。
あらゆることに使える完璧な言語(the one true language)が存在しないことは明らかである。
たとえば、Rubyがどんなにすばらしい言語でも、Ruby自身はRubyでは記述されていない。 また、OSなどRubyで記述するには向かない分野はいくらでもある。 そもそもRubyが向かないプログラマーもいるようだが、その点には今回は触れない。
しかし、100%を考えるから、完璧な言語は存在しないわけだが、 仮に80:20則にしたがって「80%の領域をカバーする言語」について 考えると、そのような言語はどのような性質を持つのが望ましいだろうか。
100%(=one)でなくて、80%(=0.8)だから、名づけて「the 0.8 true language」。
今回は言語そのものの性質を考えるために、 「コンピュータは十分な性能を持つ」ことを仮定する。 つまり、「この機能がないと性能が...」とかは考えないということだ。 世の中がどんなに進んでもコンピュータが十分な性質を持つことはないわけで(性能が向上するほど仕事が増えるので)、ある意味、現実的仮定ではないわけだが、あくまでも思考実験であると考える。
一方、人間の性質はそんなに変化しないので、現代の人間がもつ特性は考慮に入れる。 たとえば、100年後の人間はもしかしたら誰でも「物事を宣言的にとらえてプログラミングする」ことが なんでもないことになってるかもしれないけど、現代ではそのような人は少数派だ。
まず、80%の領域をカバーするためには、 その言語は汎用言語でなければならないだろう。 特定目的言語(DSL)や特殊なモデルを持つ言語(論理型言語とか、一部の関数型言語とか)では、 80%の領域をカバーできないからだ。 いや、PrologでOSまで書いた人たちがいるのはもちろん知ってるけど、 やっぱ普通のプログラマには難しいよねえ。
一方、広い領域で十分な生産性を提供するためには、 高度な抽象化能力を持つ必要がある。 現代のプログラマにはBASICや(古い)FORTRAN程度の抽象化能力では不十分だろう。 現在までに知られている抽象化機能で有効なものは、 オブジェクト指向プログラミングと、関数型プログラミングがある。 the 0.8 true languageはその両方を何らかの形で持つ必要があるだろう。 具体的には「オブジェクトとメッセージ(or 動的結合)」と 「高階関数(とクロージャ)」が必要だ。
また、言語の簡潔さも重要になる。 詳しくは『簡潔さは力なり---Succinctness is Power---』を参照のこと。
それから言語の動的性質も。 これは、Java業界でDIが注目されていることからもわかる。 DIやXMLを使った設定ファイルってのは、結局硬直したJavaアプリケーションを なんとかして柔軟に、動的にしようという試みにしか見えない。 最初から動的な言語を使っていれば、両者ともほとんど必要になることはない。
私は一時DIについて関心を持って、いろいろ調べてみたし、 自分でDIコンテナを実装してみたりもした。 でも、RubyでならDIコンテナがわずか20行で記述できる上、 よく考えてみたら、その20行も、なくてもほぼ同じことが簡単に実現できることに気がついた時、 DIってのは硬直した言語のための技術なんだと気がついた。
ここまでは当たり前の話。ここから未来予想が入ってくる。
個人的に将来性のある技術トレンドのひとつとして考えているのが、 「内部DSLの台頭」である。特定目的の言語であるDSLを 既存言語の拡張として実現することにより、
などを一度に実現できる、一粒で何度もおいしい技術だ。 で、その内部DSLを実現するために、言語が備えるべき性質は、 「柔軟で拡張性がある」ことと「乱用しやすい文法」とであると考える。
ここで意見が分かれると思うのだが、 私はLispは「内部DSLには向いていない」と思う。 より正確に表現するならば、「LispのS式とマクロはDSLを実装するのに最適だが、 拡張性がありすぎて、すぐに外部DSLの領域に到達してしまう」という意味だ。
ま、「そんなことたいしたことじゃない」と思う人も多いかもしれないけど。
いずれにしても、the 0.8 true languageはなんらかの形で内部DSLを支援するべきだと思う。 その解決策は一つではなくて、ちょっと考えただけでも
などが考えられる。最後のはちょっと違う気がするけど。
最後の要素はスケーラビリティ。
「スケーラビリティ」と言ってもいろいろなことを意味するけど、 ここで考えている重要なことは、以下のもの。
いずれも、現在から近い将来にかけてのコンピュータ事情を反映しているので、 最初の「マシンのことは考慮しない」という前提には反しているな。でも、大事なことなので。
ここはRubyがちょっと(いや、だいぶ)弱いところなので、今後力を入れないといけないだろう。
というわけで、the 0.8 true languageを備えるべき特質について考えてみた。 私の見解だとLispやRubyはけっこういい線行ってると思う。 Pythonはいい言語だけど、ちょっと文法が融通きかないので、内部DSLには向かないかな。 ここは違うアプローチを使うのだろう。
この考察から考えると、今後Java方面では、ますますのXMLの活用とJVM上のJavaでない言語の台頭が予想される。 というか、もうかなり出てきてるよね。JRubyとかGroovyとかScalaとかClojureとか。
あまり有効な結論もないまま終わる。