メンロパークにあるSunの本社へ。
オープンソース担当VCやらいろんな人の話を聞く。
今日会った有名人。
Ianに「Debian使ってるよ」と声をかけると、 返事は「ありがとう。私はUbuntuっていうバージョンのDebianを使ってるよ」というものだった。 って、Ubuntuかよっ。
情報交換をしたり、いろいろ。
私からもRuby Associationについてプレゼンを行ったのだが、 なぜか私のプレゼンの直前に通訳の人が帰ってしまい、 予期せず英語でプレゼンすることに。
つらい。
まあ、がんばりました。
昨年は寿司であったが、今回はアメリカ的な食事をとのリクエストが (Charlesから?)あったらしいので、McAuther Parkというレストランで 肉食。BBQがおいしかった。手がべとべとになっちゃったけど。
おなか一杯。
動的型の言語では以下のようなプログラムの問題を検出できない、という指摘
def test(a, b)
  a + b
end
def main()
  if ARGV.length > 3
    test(1, test)
  else
    test(1, 2)
  end
end
Process.exit(main())
まあ、それについては否定しないけれども、 だからといってこんな不自然な型不整合を検出できないという理由で 動的型が危険というのはかなりアンフェアな印象がある。
ただ、将来的にはカバレージツールやソフトタイピングの応用で 動的型言語でもより多くの問題を検出できるようになればいいなと思う。
プログラム言語に詳しい人あたりに感想を聞いてみたいなぁ。
Matzさんとか、派手にDISってくれないだろうか。
えーと、「言語をDISる人」としての認知が広がってきたのでしょうか。 本人としては「あらゆる言語ラブ」な人だと自任しているので、 ただ単にけなすことをイメージさせる「DISる」というのはちょっと辛いのだけど。
で、Curlについてはこの日記でも過去にいろいろ語っているのだけど(左上のボックスでCurlで検索)、 言語についてはあまり語っていなかったような気がする。
まず、Curlが関数型かどうかだが、 一昔前だと「関数」呼び出しがベースになっている言語はすべて関数型と呼ばれていた(Lispとか) ので、そういう観点からは関数型と呼べないこともないと思う。
しかし、現代で関数型といえば、副作用がない(少ない)、とか高階関数を基本にするとか のようなHaskellやOCamlのような言語をさすと思うので、 そういう意味ではCurlはあんまり関数型ではないと思う。
どうにもTclに近いんだけど、リストベースという点ではLispに近い。
Ingresの設立者であるStonbraker教授によるコメント。
SQLデータベースというのは過去の前提に基づいており、 現代においては時代遅れ。現代では別のやり方を考えた方がよいというもの。
Data manipulation, they said, can be performed with other tasks using languages such as Ruby. They describe a prototype DBMS called H-Store that embodies these ideas.
SQLのような完全に別の言語を使うよりもRubyのような言語を使ってやったほうがよいという主張のようだ。こんな文脈でRubyを見るのはうれしいことだ。
Rubyによるコミュニティサイト構築ツールEl Dorado。
Railsで作るのがあまりにも簡単なので、 なんでも自作しちゃう傾向があるのか、 PHPのXoopsとかDrupalのような「定番」に欠ける印象があるRubyだが、 それでもこうやって新しいものが出てくるような動きはあるようだ。
データベースの場合、関数型言語のほうが相性がいいような気がする(勘(^^;)のですがどうでしょう?
>動的型の言語では以下のようなプログラムの問題を検出できない、という指摘
動的型の言語でも、実行前にこの様な問題を、インタープリター自体がチェックするのは、原理的には不可能ではないと思いますが、そこまでする価値があるかどうかという事については、私は疑問に思います。
以降は冗談ですが、まつもとさんに文句があるならば、もっと迫力のある文句を言って貰わないと、全く面白くもなんとも無いですよね。まつもとさん。
>データベースの場合、関数型言語のほうが相性がいいような気がする(勘(^^;)のですがどうでしょう?
数学を基礎に置いているデータベースならば、私もそう思います。
> Rubyのような言語を使ってやったほうがよい
全く同じ構想で3年くらい前から暇を見てはDB作っています
#広げた風呂敷が大きすぎて一向に完成しないので匿名で(汗
その中でわかったのですが、
1.DMBSでは集合に対して内容を意識せずにまとめて操作が行えることが必要
多数のオブジェクトをまとめて扱うのはRubyも得意なので問題なさそうに見えますが
「空集合」を含めると話は違ってきます。OOの基本「Objectの振舞いはObjectに聞け」に従うと
存在しないオブジェクトの振る舞いは定義できません。
2.DBMSでは問合せの高速化のために実行順序の入替えを含めた全体での最適化が必要
手続き型の言語では処理の順序入替を含めた最適化が難しい。
といったあたりを解決する必要があります。
(一応上で取り組んでいる中では解決策は考えてある)
・・・どちらもHaskellなんかがものすごく得意とするところなので、関数型言語のほうが向いているというのは確かにその通りですね。