メンロパークにある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だが、 それでもこうやって新しいものが出てくるような動きはあるようだ。
Matzにっき(2008-02-19)にあったプログラムは、一応glintでも問題を検出できます。 (define (test a b) (print (+ a b))) (define (main args) (if (< 3 (length args)) (test 1 test) (test 1 2)) 0) % glint hidden_dangers.scm hidden_dangers.scm:2: error: #<g
データベースの場合、関数型言語のほうが相性がいいような気がする(勘(^^;)のですがどうでしょう?
>動的型の言語では以下のようなプログラムの問題を検出できない、という指摘<br>動的型の言語でも、実行前にこの様な問題を、インタープリター自体がチェックするのは、原理的には不可能ではないと思いますが、そこまでする価値があるかどうかという事については、私は疑問に思います。<br>以降は冗談ですが、まつもとさんに文句があるならば、もっと迫力のある文句を言って貰わないと、全く面白くもなんとも無いですよね。まつもとさん。
>データベースの場合、関数型言語のほうが相性がいいような気がする(勘(^^;)のですがどうでしょう?<br>数学を基礎に置いているデータベースならば、私もそう思います。
> Rubyのような言語を使ってやったほうがよい<br>全く同じ構想で3年くらい前から暇を見てはDB作っています<br>#広げた風呂敷が大きすぎて一向に完成しないので匿名で(汗<br>その中でわかったのですが、<br>1.DMBSでは集合に対して内容を意識せずにまとめて操作が行えることが必要<br> 多数のオブジェクトをまとめて扱うのはRubyも得意なので問題なさそうに見えますが<br> 「空集合」を含めると話は違ってきます。OOの基本「Objectの振舞いはObjectに聞け」に従うと<br> 存在しないオブジェクトの振る舞いは定義できません。<br>2.DBMSでは問合せの高速化のために実行順序の入替えを含めた全体での最適化が必要<br> 手続き型の言語では処理の順序入替を含めた最適化が難しい。<br>といったあたりを解決する必要があります。<br>(一応上で取り組んでいる中では解決策は考えてある)<br>・・・どちらもHaskellなんかがものすごく得意とするところなので、関数型言語のほうが向いているというのは確かにその通りですね。
匿名希望さん、有難うございます。<br>ところで、大した話しではないのですが、また、間違っているかもしれませんが、Haskellの変数とDBMSのデータをうまくマッピングしてやって、モナドを適切に使うと、SQL言語を思わせるような、DBアクセス関数が出来、Haskellが「初心者」に受け入れやすくなるような気がしたのですが、いかがでしょうか?
HaskellDBというのがあります。<br>http://haskelldb.sourceforge.net/<br>DBアクセスについてある程度の静的検査:)が可能なのが利点です。初心者向けではないと思いますが、ある程度Haskellを触ればつかえるんじゃないでしょーか。あとHaskellDBでは、確かにモナドを使ってクエリを構成しています。<br>もれなく DBMSのテーブルからHaskellの型宣言を生成するツールもついてきます:)
Haskellerさん<br>HaskellDBをご紹介いただき、どうも有難うございました。ところで、<br>>DBアクセスについてある程度の静的検査:)が可能なのが利点です。<br>との事ですが、DBの操作時のエラー処理も、モナドを使って統一的、且つ、簡素に記述出来るような気がするのですが、いかがでしょうか?
http://www.okada.jp.org/WOWiki/index.php?plugin=attach&openfile=Intro_to_Intro_haskell.pdf&refer=WOMeeting200511<br>のP28〜30に、HaskellDBの極簡単な解説を見つけましたので、お知らせいたします。