ボクが関数型言語に興味をもったわけ ~「ハッカーと画家」と出遭って夢みた、ボクが考えたプログラム言語のあるべき姿を語りたい~
- Okocha_Makocha
- 3293
- 0
- 2
- 1
プロだったら道具にはトコトンこだわるべきなんだけど、未来の大工がカンナやノミが重要じゃなくなるなんて、昔の職人は想像できていたか?ってこと。経験値の積上による現状分析(AsIs)とあるべき姿(ToBe)の視座は根本的に違うし、議論が取り扱うスコープも違う
2012-03-28 15:58:39ボクがToBeの視座で「隠蔽された道具は信用できないから制御させろ」という要件を取り扱うと、「将来、隠蔽されていない道具を使うような仕事なんて需要あるの?」っていう「仕事のスタイルの変化=あるべき姿」という別なスレッドを誘発するんだよね
2012-03-28 15:58:54日本の「伝統」=環境に最適な部品への興味は、ものづくりの心を養う、プロの心構えとしてはとても立派な文化だけど、例えば日本海軍が戦艦ごとにリベットの形状が違っていたため運用コストや効率が非常に悪かった原因の一端をとなったように、日本独自の問題点も合わせて発生させる
2012-03-28 15:59:11デザインの基本として、よい道具は常に目的に対してシンプルな形状を獲得してる。それは市場がプロ仕様だろうなんだろうが、だよ。取り扱い複雑な道具(プロセッサやメモリの状態を細かく制御できるような道具)へのこだわりは、将来淘汰されちゃう側の職人をうむかもだよ?
2012-03-28 15:59:30もちろん、人間の脳で環境を全て制御できる範囲、例えば「組み込み系」とかなら、難しい道具を駆使して職人芸的に全ての要素を制御しきれることが可能だと思うし、日本は箱庭の文化もあるから、一定数以上のプログラマが組み込み系に興味が向くのは、そういう日本人の特性にあってるからなんだろうけど
2012-03-28 16:00:13マルチコア時代なプログラミングのあるべき姿っていう主題においては、プロセッサもメモリも人間が取り扱うアーキテクチャとしては十分複雑で巨大すぎる環境だよ
2012-03-28 16:31:41ようは日本人プログラマの一定数以上が興味もちがちな、組み込み系みたいに自身が制御できる範囲での完璧性追求指向性は、ボクの視点からは神社仏閣市場とかぶるんだよね。 技術、思想を否定するものはないけど、技術トレンドじゃないでしょ
2012-03-28 19:53:34確かに全てを制御できてる感覚が楽しいことは理解できるし、否定したくないんだけど、それで得られた技術を汎化するとフレーム爆発を起こすからね。
2012-03-28 19:58:30日本は戦国時代、世界の銃の2/3を集めた国だけど、その後、パックス徳川ーナの時代には工芸品としての価値しか進化しなかった。 イスラムの細密画の文化もそうだけど、細密な職人的こだわりはスゴい結果だすけど本来の目的からはズレがちになる
2012-03-28 20:07:32この逸話は、職人がもつ審美眼が常に正しい進化を導いけるとは限らないことを意味してると思う。 大雑把とか綺麗じゃないとか職人的な審美眼が気になる点は二の次で、あるべき姿が示す先にしか羅針盤は未来を示さないって思ってるってこと
2012-03-28 20:13:32@KURUMA_Keizo との会話をまとめた『「ボクが関数型言語に興味をもったわけ ~「ハッカーと画家」と出遭ってみえた、ボクが考えたプログラム言語のあるべき姿~」』をトゥギャりました。 http://t.co/g7nhVPZL
2012-03-29 19:19:12言わんとすることが分かったかも。「参照透過性が保証されるとマルチコアで排他制御が減って有利」説って、1度作ったデータはもう上書きせず、波紋が広がるみたいに伝播していくってことか。確かに、もし それで計算が上手くいくなら 排他が減るし100コアあっても動くだろうね。
2012-03-30 02:50:11あと、最近の分散DB設計論で、CAP定理「分散DBでは一貫性、可用性、分断耐性を全て同時には満たせない」てのがあって、オイラは一貫性を少し弱めてDNSデータみたいにするのがいいと思ってる。 100オーダーのマルチ計算機では分散DBと同じ問題が出て、同じように解決が必要だね。
2012-03-30 02:58:23「参照透過性」て言葉で脊髄反射で思い出すのは「繰り返し書込透過性」パケロス等でリトライ時、前回既に書込完了してても結果的に同じならエラーとしないてこと。今の分散シスでも、HTTPみたいなセッション概念が弱い下回りに乗る場合は大切な話。書込一切不可でなくてもいいかもよ?ていう妄想ね
2012-03-30 03:05:38震えるぞハート!燃え尽きるほどヒート! 波紋が広がるようにデータが伝播する計算機ってのは、いつぞやの多変量解析の先生も「これからセル計算が熱いかも」って言ってたね。そのパクリ妄想が http://t.co/sRUrstLA ですがどこにも着地することできずじまい。
2012-03-30 03:13:46@KURUMA_Keizo は、たぶん知らないと思うんだけど、ボクは'96にリプライ元のDNSから連想したに近い発想経緯で、広域分散DBにて実現するユビキタス環境というアイデアを起想してて、とあるプロジェクトに参加したコトがある。現在の言葉だとクラウドの出来損ないみたいなアイデア
2012-03-30 13:43:16何が出来損ないだったのかというと、広域分散に格納されるデータに対して、例えばハッシュによって散らすことで一貫性を犠牲にしてでもスケールを得るというような、割り切ったアイデアには辿りつけなかったコト。 クラウドでいうところのMapReduceが思いつけなかったんだ
2012-03-30 13:43:39ブリュワーのCAP定理が'00だから、その遡ること4年前の話だし、まだ一貫性を犠牲にするという概念自体がボクの知る限り一般的じゃなかったからね。とはいえ、データを犠牲にしてもいいんだっていう発想自体が全くできなかったんだから、ショックはでかかったよ。
2012-03-30 13:43:53後にGoogleが実装したクラウドのアイデアを知った時に、自分がおしいところまで考えていたことがわかって非常に悔しい思いをしたと同時に、ハッシュで散らすアイデアを思いつけなかったことの惨敗感を味わった。と、同時に何故MapReduceというアイデアが出てきたのかが気になった
2012-03-30 13:44:08これは更に後に知ることになるんだけど、MapもReduceも、元は関数型言語の概念だ。Mapは関数型言語で最も有名で多用される高階関数の代表格で、データに対して例えばハッシュとかを適用する関数、ReduceはLispの時代からある関数型言語の得意技「畳み込み」にて集約する関数
2012-03-30 13:44:44詳しく調べたわけじゃないけど、名前からしてもMapReduceの起案者は関数型言語の素養がて、MapReduceのアイデアを起想できたのは間違いないと思う。ボクのおもちゃみたいなアイデアとGoogleの実装との差は、関数型言語の基礎素養だった、ともいえるかもね~
2012-03-30 13:45:08出来損ないクラウドが出来損ないで終わった反省でもあったんだけど、たぶんブレークスルーとなるアイデアは、関数型言語と進化するアーキテクチャという組み合わせの感覚から生まれてくるはずじゃないかと思った。これも関数型言語を修めてみようと思った当時のモチベーションのひとつなんだよ
2012-03-30 13:45:41@KURUMA_Keizo そういや、100コア超の環境のマルチコアに対して、MapReduceと似たような分散処理ができるのかもと思ったこともあった、あった。指摘されるまですっかり忘れてたけど。
2012-03-30 13:46:20あと、同じ理由で注目してるのは『Clojureの作者が作ったDatomic(デートミック).com が凄い』( http://t.co/c1pRNs3Y ) の変更不可なAppend-onlyデータベースも関数型言語の発想から得られている、アーキテクチャとの新しい関係だ
2012-03-30 13:46:35