@naka_aki_spl なるほど、多分理解できました。どもです。

posted at 11:31:39

RT @ichiro_satoh: ご要望に従い、今日の勤務先大学院授業「分散システム」のスライドをアップします。ひたすらデータ複製の話。講義が前提だから肝心な説明が一部欠けてますが、それと授業は英語だからスライドも英語ね。 http://homepage.mac.com/ichiro_satoh/download/presentation/...

posted at 22:29:54

RT @shimizukawa: 【急募】錦糸町駅近辺で静かに会食できる和食の店。お義母さんが上京してくるんやー

posted at 22:02:11

@naka_aki_spl q=q.parent() のところって、q == q.parent() ですか？それとも代入？

posted at 20:57:19

@naka_aki_spl むぅ、ちょっとわかりません。考えてみます。

posted at 20:21:03

@naka_aki_spl 枝分かれというのは、複数のクエリーに分割するとかそこらへんの話であってますか？

posted at 23:04:29

@naka_aki_spl 調べてみましたがよくできていると思います。ただlistやsetに対するfilter相当なので、名前を付けたり合成できたりするのはおっしゃるとおり本来は当たり前ですね。

posted at 15:37:15

Python本ってこれか。 "Python for Data Analysis" タイムリーだな。（何が？ http://www.amazon.com/dp/1449319793

posted at 21:50:00

RT @yosuke__: Python本の著者のブログ / “Quant Pythonista - A blog about scientific Python, quant finance, statistics, data analysis, and ha…” http://htn.to/JyKj2

posted at 21:43:54

"とよぞう氏になにか意図していた悪意があったとは思いません。ただ、..技術者としての未熟故にいろいろな人に言ってみせた大言壮語は、結果として「騙した」と言われても弁明するのが難しい..のは事実だと思います。" http://d.hatena.ne.jp/shi3z/20120525/1337933070

posted at 21:30:23

"CEREVOを立ち上げた岩佐さんがすごく立派に思えるのは、まさしくそういう「技術者としての夢」を夢に終わらせず、曲がりなりにも事業として軌道に乗せているところです" http://d.hatena.ne.jp/shi3z/20120525/1337933070

posted at 21:26:58

RT @ikeike443: シャノンのプロダクトエンジニア（Scala） | 求人/転職サイトGreen(グリーン) http://www.green-japan.com/job/19586 via @green_japan

posted at 18:26:15

ポール・グレアム風に言うとこんな感じ？

posted at 18:21:30

"overrideっていちいち書かないとバグだらけになるようなら、それはOOPの設計自体に何かまずいところがある証拠なんだ。"

posted at 18:20:46

それをまとめるものがないんですよね。 RT @naka_aki_spl: 少なくともフツーの業務アプリとかだと「どの結合をしたいか」はクエリごとに決まることじゃなくテーブルごとに決まる。テーブルと結合のしかた（１テーブルあたり数通りかな）「を指定する」のが合理的。

posted at 18:11:14

じゃあどうすればいいかというと、クエリーの結果を使って何をしたいかまでを宣言的に記述して、それをコンパイルした結果としてSQLが生成されるようなDSLがあれば良いはず。

posted at 18:03:15

汎用言語に混ざったSQL発行をまるごとコンパイルしてSQLの最適化をするのは直感的にかなり困難なはずで現実的でない。

posted at 18:01:13

RT @tomooda: 再帰を生で使わずにmapやreduceを使うような工夫が継承に対しても必要な気がしますね。つーか、最低限、subtype関係とメソッド探索は混ぜるな危険。 RT @naka_aki_spl 継承が悪いとは思わないんだけど、たぶん「継承は働き過ぎ」なんだろうと思う。

posted at 17:50:29

ORMの問題のひとつは、クエリー発行を含む不純な関数を合成したときに、含まれるクエリーを合成して最適化することが自動では困難なこと。クエリー発行は典型的な副作用で関数の命であるcomposabirityを悪化させる。その悪臭はラップしても隠せない。

posted at 17:50:16

やっぱり外部結合のNULLは人気無いみたいだな。

posted at 17:43:43

@nouvellelune なるほど、そういう考え方もできますね。

posted at 17:43:11

@naka_aki_spl あ、「辻褄」がかぶりましたねｗ

posted at 17:41:24

@naka_aki_spl つじつま合わせ的な匂いがしますよね。

posted at 17:40:30

RT @Money4Lude: 来週6月1,2,3日(金土日)に筑波大学でするオムニバス『圏論Ⅲ』のアブストラクト完成しました。これを読んでモチベーションを上げたり下げたり微調整して是非参加して下さい‼https://sites.google.com/site/kota3takeuchi/announcement/ca...

posted at 17:39:01

あとは外部結合で発生するNULLですよ。あれ気持ち悪いと思いませんか。なんか型がおかしい気がしてならない。あのNULLは素直に考えれば空集合みたいなもんで、となると空でない集合はどこにあるのかという。

posted at 17:36:54

あ、いつの間にか話がそれてた。SQLの話だった。

posted at 17:35:29

overrideを明示することやそれを強制することが良いとされているのは、それがなければバグを生みやすいからであって、それはメソッドの名前の使い方が元来孕んでいる暗黙さに起因するのではと疑っている。

posted at 17:31:06

同意。 RT @naka_aki_spl: 継承が悪いとは思わないんだけど、たぶん「継承は働き過ぎ」なんだろうと思う。色んな要素をまとめて扱ってしまい、そのうちの幾つかの要素が悪手なんじゃないだろうか。便利な面も有る。現行の継承ではなく何かそれを分割した手法が欲しいってとこか。

posted at 17:22:26

自然結合のような名前の使い方は、OOPの継承と同じで悪手。一見シンプルになるように見えても、全体の複雑さは減らないどころか増加し得る。

posted at 17:16:07

あれはアウトですね。 RT @naka_aki_spl: @pokarim SQL自体の仕様としては、たしか（滅多に使わないんで忘れたw＞自然結合だっけ）同名のカラムだったら合わせるという奴がありましたよね。気持ちは判るけどそれって半端なので実用性が低いと感じるです。..

posted at 17:13:29

ここらへんは、使いやすさや考えやすさなど感覚的なものを含むので、なかなか理屈だけで説得力のある説明が組み立てられないのが苦しいところ。

posted at 17:11:12

ですよねー。 RT @naka_aki_spl: @pokarim　名前を決めるだけなら名前付き引数程度かなとも思うけど、SQLの結合って、なんというか「名前を二度指定してる」というか、そういうかんじの鈍重さを感じるです。手間二倍二倍！みたいな。

posted at 17:08:38

RT @naka_aki_spl: @pokarim　名前を決めるだけなら名前付き引数程度かなとも思うけど、SQLの結合って、なんというか「名前を二度指定してる」というか、そういうかんじの鈍重さを感じるです。手間二倍二倍！みたいな。

posted at 17:07:06

どのカラムを使って結合するのかが明白な場合は省略可にするのは簡単だが、省略できない場合が残る限り、メンタルモデル的にはなかなかすっきりしない。

posted at 17:06:55

関数合成は順番を決めるだけだけど、SQLの結合は、どのカラムを使うか指定する必要がある。記述が冗長になりがちだし、メンタルモデル的にも非効率だと思う。

posted at 17:02:58

@naka_aki_spl ですです。

posted at 16:48:33

@naka_aki_spl なるほどなるほどよくわかります。ORM使ってるコードをまるごと解析してクエリを割り出す必要があるってことですよね。一方パフォーマンス的に問題でない範囲であれば、わりと便利と。

posted at 16:44:58

@naka_aki_spl わかります。ORMは僕も目の前の仕事では便利に使わせてもらってます。ただORMが満点かといわれるとそうではないはず。たとえばORMアクセスを関数に包んで合成すると、バラバラにクエリーがとんで非効率で困るってことないですか。

posted at 16:37:56

@naka_aki_spl joinのカラム指定の面倒さに同意もらえたのは嬉しいです。たぶん初めてです。別に面倒じゃないよと言われると、面倒さの説明が難しくてｗ

posted at 16:32:35

@naka_aki_spl SQL迂回がゴールだとは思ってます。ただSQLは標準の口として便利ではあるので、SQLを迂回可能で依存はしないけどあえて使う、というのはありかなと思ってます。

posted at 16:26:43

@naka_aki_spl たとえば、関数結合では順序(f.g or g.f)の指定だけで済むのに、joinは使うカラムの指定が必要なとこって結構面倒だと思いませんか。

posted at 16:20:54

@naka_aki_spl そのラッパーを担うのが、現状ORMくらいしかないけど、それも微妙ということでしょうか。

posted at 16:19:30

@naka_aki_spl 同感です。＞ぬるぽより生SQL..　SQLのデザインパターンというのは考えたことなかったですけど面白い見方ですね。ありそうな気がします。

posted at 16:18:45

@naka_aki_spl ほんとに必要になるのは複合キーからの射影くらいだと思います。それ以外は封印するとして、たぶんjoinがたくさん必要になるので、そこをSQLの文法やDBMSの実装の改良とか必要になりそうですね。

posted at 23:02:20

そうして議論は深まりつつ、夜は更けていくのであった

posted at 01:15:04

アノテーションとかでlazyかどうかを指示するくらいだよね？

posted at 23:40:04

O/R Mapperで統計情報使って実行計画、というかクエリー計画云々やっているものってあるのかな？

posted at 23:38:38

RT @syamino: 『ラムダ計算で代数的データ型を表現する方法 - Meta reifier @syamino』 http://d.hatena.ne.jp/syamino/20120524/p1

posted at 23:36:21

RT @ikeike443: Scalaを使ったプロジェクトが始まるので、Scalaを業務で使いたい人募集してます。興味ある人はDMでいいので教えて下さい。業務での利用経験なくても、ヤル気あればいいです。

posted at 21:06:47

もうちょっと領域を限定するか土台を決めないと議論にならないかな。

posted at 13:31:27

テーブルの射影のようにカタマリの一部を切り出すよりも、独立したより細かい部品を組み合わせていくことを中心としたほうがモジュール性が向上すると思ってるんだけど、そういう認識は一般的ではないんだろうか。

posted at 12:45:38

ひとつのライブラリから関数を幾つか選んでimportするのと、RDBのテーブルから属性を選んで射影するのとでは意味が違う。前者ではimportした関数はそれぞれ独立かもしれないが、後者では選んだ属性の独立性は低く、それらの組み合わせとして持つ意味が強い。

posted at 12:31:13

モジュール性を考えるとき、RDBの射影のように情報を隠したり削ったりする操作は実は筋が悪く、基本となる部品の粒度が荒すぎることを暗に示してると考えてる。オブジェクト指向でも同様の問題がある。

posted at 12:24:28

@PG_kura @naka_aki_spl たぶん、部品をつないでいくだけではだめで、部品の一部を隠したり削ったりする必要があるっていうのは、単位部品が大きすぎるってことなんだと思います。

posted at 11:11:17

@PG_kura @naka_aki_spl 余談ですが、RDBの射影も同様に筋が悪いと考えています。不要なものを隠すより、必要な物だけつなげていくほうがいいと思うんです。いまのところ根拠は上手く示せませんが。

posted at 10:53:37

@PG_kura @naka_aki_spl つまり、RDBだったらまずはテーブルごとに分割されていて、見たい時に適当に結合すればいいのですが、オブジェクトっていうのは実は最初からだらだら〜と繋がってしまっているわけです。なので見るときには打ち切る必要がある。それが微妙。

posted at 10:49:35

@PG_kura @naka_aki_spl オブジェクトからHTMLを自動生成がまずいのは、オブジェクト側にも問題があると思います。オブジェクトの属性を辿って行くときりがないので、どこかで打ち切らなければいけない。どこでを打ち切るのは見た目の問題になる場合もあるわけです

posted at 10:47:44

@PG_kura @naka_aki_spl デバッガなかったときは、自前で作ったconsole.logもどきとか、こういうので http://mochi.github.com/mochikit/examples/interpreter/index... がんばってたわけですよ。

posted at 10:45:15

@PG_kura @naka_aki_spl それですね。問題の根っこはそれで、あとはHTMLをサーバーでレンダリングしたりクライアント側でレンダリングしたり、というのがその問題を大きくしている気がします。

posted at 10:12:37

@finalfusion ですね。

posted at 10:08:34

@PG_kura @naka_aki_spl 実際は、ベタにそれをやるとCSSでテンプレート的なことをやる羽目になってしまうと思うので、うまい抽象化を見つける必要があると思いますが。

posted at 10:03:39

@PG_kura @naka_aki_spl JSONくらいの情報を渡して、CSSで宣言的に見た目を作れたらちょっとはましになると思います。

posted at 09:57:03

@PG_kura @naka_aki_spl 例えば、表か箇条書きかというのも表面的な問題なので、そこら辺までHTMLから抜き取ったら、たぶんJSONみたいなものしか残らないはずなんですよね。

posted at 09:54:52

@PG_kura @naka_aki_spl HTMLの手書きがどうしても必要になるのは、見た目に関する情報をCSSに任せるのが中途半端にしかできないというのが大きいと思います。

posted at 09:51:49

@finalfusion 持ってます。読書会やりますか！？

posted at 09:28:47

RT @PG_kura: フレームワークはいろんなモノを省略してくれるんだけど、進化しすぎたせいで、プログラマからは異常系の対応とか帳尻合わせの小細工ばかりが見える状態になる。僕はそれが何か好きになれないんですよ。

posted at 09:25:57