«前の日記(2006年10月02日) 最新 次の日記(2006年10月04日)» 編集

Matzにっき

<< 2006/10/ 1 1. [教会] お休み
2. 実家
2 1. U-20プロコン表彰式
2. インタビュー
3. Job Trends: ruby programmer
3 1. インタビュー
2. [OSS] OSS コンサル会社が設立
3. [Ruby] Rubyの生産性の高さはどこまで本当か?
4. [Ruby] block parameter to be local variables
5. ジョブズ氏のいないアップルが来る日--IT企業が直面する「後継者選び」
4 1. 即興トーク
2. [OSS] ソフトエイジェンシー、MySQL 開発者が直接サポートするサービスを開始
3. [OSS] Seasarは鶏か卵か? - ひが氏、キャズム越え柔道ストラテジ語る
4. 『現代という時代は、どのようなプログラミングを求めているのか?
5 1. [Ruby] Ruby on Rails and More...
2. [Ruby] method_missing magic - emulating Groovy's "it" in Ruby
3. [言語] Code Golf
6 1. OSM休刊
2. 健康診断
7 1. [教会] 総大会...のはずが
2. [Ruby] RubySpec
3. [OO] OO is dead
8 1. 総大会
9 1. 松江フォーゲルパーク
2. RubyConf 2006 - Agenda
10 1. [原稿] OSM原稿「美しいコード」
2. [OSS] 2006年度の「日本OSS貢献者賞」の受賞者が発表
11 1. [Ruby] ActiveSupport::MultiByte
2. [OSS] OSS貢献者佐渡特別賞2006
12 1. 知らされなかったパスワード--ユーザーの死が封印するアカウントと遺族のアクセス
2. オープンソースプロジェクトを予期せぬ事態から守る方法
13 1. Multitasking is inefficient
2. データ圧縮の昔話
14 1. [原稿] 日経Linux2006年12月号
2. [Ruby] Rubyチュートリアル
3. [Ruby] JParsec - Ruby Parsec
15 1. [教会] 気分
2. [教会] バプテスマ会
16 1. [原稿] 日経Linux
2. [OSS] How to Protect Your Open Source Project From Poisonous People
17 1. 移動(自宅→出雲→羽田→成田→SFO→SLC→Provo)
2. 観光
18 1. [Ruby] BYU Colloquium
2. [原稿] 日経ソフトウェア2007年1月号
3. 通販の国
19 1. ユタ観光
20 1. [Ruby] RubyConf1日目
21 1. RubyConf 2日目
2. おみやげ
3. 乾燥注意報
4. [Ruby] implementers' summit
5. [Ruby] Keynote: Return of the Bikeshed -- or Nuclear Plant in the Backyard.
22 1. [教会] 礼拝
2. [Ruby] RubyConf3日目
3. 国家の損失?
4. [Ruby] デンバー合意
23 1. 帰国
24 1. 帰国・鼻炎
25 1. 睡眠
26 1. [Ruby] イテレータ
2. [OSS] OracleがLinux自体のサポートに乗り出す
27 1. [Ruby] ケイゾク
28 1. 末娘誕生日
2. [教会] ハロウィーン
3. [言語] Ralph Griswold 1934-2006
29 1. [教会] 安息日
30 1. 家庭の夕べ
2. [Ruby] Visualization of Ruby's Grammar
31 1. [Ruby] 【OSC2006 Tokyo/Fall】「日本Rubyの会」の高橋会長,会の現状を報告。活動メンバーが固定化しているのが問題に
2. タツノオトシゴ
>>

2006年10月03日 [長年日記]

_ インタビュー

大新聞社のインタビューを受ける。なんか取材なんて滅多に受けないのに ある時には重なるものだ。

OSSについて正直なところを話す。 が、あまりにも普通なので記者の人はちょっと不満げに見えた。 もしかしてなにか期待していらっしゃったことに応えられなかったかしら。

_ [OSS] OSS コンサル会社が設立

元ミラクルの小田切さんが会社をはじめたという話。

昨日の日経コンピュータとの取材で、自分でOSSをハックするわけにはいかない 情報システム部は「OSSを使ってなんとかできる」人たちをつかまえる必要がある(ソフトウェアはどんどんコモディティ化するから)とかいう話をして、 それの受け皿となるOSSサポート企業というのはこれからニーズの高まる分野で ビジネスチャンスがあるのではないか、という話をしたのだが、 この「オープンソース・ソリューション・テクノロジ」はそれに対応するものになる、のかもしれない。

_ [Ruby] Rubyの生産性の高さはどこまで本当か?

最近、Webで公開されたYuguiさんの記事「Rubyを仕事に使うべし!」に対して、それじゃ「使うべし」をちゃんと説明したことにならんだろう、という反応。

いや、まあ、その批判は当たっていないこともない。私自身は「Rubyを仕事に使うべし」とは必ずしも思ってなかったりするんだけど。

が、(たぶんワザとだと思うんだけど)この批判そのものが「なにができるか」ということを ベースに論が構成されている。が、正直な話、言語の比較で「なにができるか」を 比べるのは不毛なんだよね。だって、大抵のことは大抵の言語で「可能」なんだもの。

最初にはっきりさせておかなければならないのは、 仕事で使う言語(というかツール)を選択する時に、 「その言語になにができるか」という基準で選ばれることはマレである。

重要なのは、教科書があるかとか、プログラマが確保できるかとか、 必要なライブラリが入手できるかとか、IDEがあるかとか、 その言語を気に入ってる上司がいるかとか、 話題になっているかとか、そんなことであって、 ある言語がどのような機能をもっているかではない。

そういう意味では「Rubyを仕事に使うべし!」というタイトルの記事は、

  • Rails話題になってますよ
  • ライブラリも最近充実してきてます
  • RubyGemsも結構便利だし
  • IDEも揃ってきてます
  • 某最高学府の教育課程ではRubyが採用されました

とかいう話題を中心にした方が効果的だったと思う。

それはそれとして、「どこまで本当か」というエントリの方は 些細な文法の違いから来る記述力を無視しすぎだと思う。

Rubyなんかよりも、もっとずっと本格的なメタプログラミングのできるCLOSとかで書くべきでしょう。

とか

この程度のわずかなシンタックスシュガーで、それほど生産性に大きな違いがでるのでしょうか?

とはいえ、おそらく「計測できる生産性」での差は出ないだろうと思う。 しかし、「計測できない生産性」では大きな違いが出るのではないだろうか。 気分とか。

そして、(たぶん不幸なことに)ほとんどの場合生産性は計測不能なのだ。

ま、それもこれも仕事に使える言語を自分で選べて初めて言えることなのだが。

追記

このエントリについて、fromdusktildawnさんから批判されちゃいました。 「ありもしない錯誤をでっちあげて批判している」のだそうです。

そう指摘されてあらためて引用部を見返すと、確かに

RubyとCLOSでは、シンタックスの違いに起因する生産性の差なんて、少ししかないよ。

と読めるように引用してますね、私。これは私の落ち度です。 原文へのリンクが あるので前後はそちらで読んでいただけるだろうという甘えがありました。

引用の仕方がまずかったことについては謝罪します。

実際には、二つの引用部は独立して引用したつもりで、前者は

(書き込み系)メタプログラミングしたいならRubyよりもCLOSだよ

後者は

RubyとC#では、シンタックスの違いに起因する生産性の差なんて、少ししかないよ。

という主張が読み取れると言いたかったのでした。

で、その主張に対して

  • Rubyのように手軽に書き込み系メタプログラミングができることで(普通のソフトウェア開発でも)広がる世界があるよ。
  • RubyとC#でのシンタックスの違いに起因する(おそらくは計測できない)違いは大きいと思うよ

ということが言いたかったわけですね。要するに「Rubyは間口になれる」と。

間口をくぐった後は、Rubyにとどまるもよし、SchemeやCLOSに進むもよし、 あるいはHaskellのような関数型に進むもよし。 それはユーザの自由でしょう。

間口になるためにはCLOSやSmalltalkは本格的すぎ(多くのプログラマにとって日常とのギャップが大きすぎる)、PHPでは「上」とのつながりが薄すぎて「面白くない」。これがRubyが「ウケる」理由なんじゃないかと(Perlも確かに「上」とつながっているんだけど、そこはそれ。ねぇ)。「今そこにあること」という弾さんと同じような結論になっちゃいましたね。たぶん、PythonもRubyと似たようなポジションにあるのだと思います。

_ [Ruby] block parameter to be local variables

思い立って、とうとうブロックパラメータについて

  • ローカル変数のみ許す
  • スコープはブロックローカル

という修正を実現した。ずいぶん悩んでいたわりには 実際に手を動かしたら30分で実現できるというのはどうよ。

他の悩んでいることについてもそうなのかなあ。

_ ジョブズ氏のいないアップルが来る日--IT企業が直面する「後継者選び」

いずれ世代は交代する。企業でも家族でも。 それについてどれだけ備えることができるか。

時として、非常に長い(数十年とか数百年とか)スパンの視点に立つ必要があるのかもしれない。 ま、聖書とか見てると数百年が一行で過ぎたりして、新鮮な気持ちを味わうことがある。


«前の日記(2006年10月02日) 最新 次の日記(2006年10月04日)» 編集