PFIセミナー 2013/02/28 「プログラミング言語の今」

17,060 views

Published on

PFIセミナー 2013/02/28 田中英行「プログラミング言語の今」

Published in: Technology
0 Comments
70 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
17,060
On SlideShare
0
From Embeds
0
Number of Embeds
2,950
Actions
Shares
0
Downloads
115
Comments
0
Likes
70
Embeds 0
No embeds

No notes for slide

PFIセミナー 2013/02/28 「プログラミング言語の今」

  1. 1. プログラミング言語の今PFIセミナー 2013/02/28田中英行<tanakh@preferred.jp>
  2. 2. 自己紹介 田中英行 (@ tanakh, http://tanakh.jp/ ) (株)Preferred Infrastructure 研究開発部門 Haskell愛好家 拙訳「すごいHaskell楽しく学ぼう!」好評発売中!
  3. 3. 本日の概要 プログラミング言語って?  みんな書いてるものだけど  研究ってどんなことするの? プログラミング言語研究の最前線  どういうことやってるの?  面白さとか
  4. 4. プログラミング言語の学会
  5. 5. プログラミング言語学会四天王(Impact Factorに基づく) POPL PLDI ICFP OOPSLA
  6. 6. プログラミング言語学会四天王 POPL PLDI ICFP OOPSLA SPLASH
  7. 7. :::::::: ┌─────────────── ┐:::::::: | OOPSLAがやられたようだな… │::::: ┌───└───────────v───┬┘::::: |フフフ…奴はSIGPLAN四天王の中でも最弱 … │┌──└────────v─┬────────┘| たった24回でリニューアルとは│| OOPの面汚しよ… │└────v────────┘ |ミ, / `ヽ /! ,.──、 |彡/二Oニニ|ノ /三三三!, |! `,‘ \、、_,|/-ャ ト `=j r=レ /ミ !彡T 爪| / / ̄|/´__,ャ |`三三‐/ |`=、|,=’|/人 ヽ ミ=‘/|`:::::::/イ__ ト`ー く__,-, 、 _!_ // `ー─’“ |_,.イ、 | |/、 Y /| | | j / ミ`┴‘彡\ POPL PLDI ICFP
  8. 8. POPL ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages 今年で40周年を迎える、 プログラミング言語のトップカンファレンス プログラミング言語全般に関する話題  Parallel, Concurrent  Semantics  Type Systems  Formal Verifications, Proof, etc…  近年はテーマが発散気味
  9. 9. 豊富な併設イベント
  10. 10. どんなことやってるの? プログラミング言語全般の研究 「Principles」 of Programming Languages… 特に人気のあるジャンルは、細分化されてワークショップに  Verification Model-Checking Abstract-Interpretation  Practical Aspects of Declarative Languages  Partial Evaluation and Program Manipulation  Data-Driven Functional Programming  etc…
  11. 11. DDFP(Data-Driven Functional Programming) 乗るしかない、このBigDataに! という感じの今年出来たワークショップ とにかくナウい
  12. 12. tryF#http://www.tryfsharp.org/ 来るべきBigData時代を見据えて(?) プログラミング言語はどうあるべきなのか? F# 3.0では Information Rich プログラミングというものを標榜していた tryF# では、Webで Information Rich プログラミングを体験できる Webの開発環境が恐ろしい完成度
  13. 13. プログラミング言語って何ですか?研究するものなんですか?
  14. 14. あなたにとってのプログラミング言語とは? 科学? 数学? 魔法? 宗教? 文学? 哲学?
  15. 15. 科学的立場:研究と現場の乖離 (´・_・`)実際問題意識ある
  16. 16. 研究と、実用までの隔たり 20 ・GC 技 ・型推論 術 20 ・ラムダ式 ・etc…
  17. 17. 魔術としてのプログラミング
  18. 18. 文芸としてのプログラミング
  19. 19. 宗教としてのプログラミング言語http://www.bugbearr.jp/?プログラミング言語%2F宗教論争
  20. 20. 謎の喩えの数々 ユーザ 嫁 刃物
  21. 21. プログラミング言語とは何なのか? コンパイラはどこに入る? アプリケーション ミドルウェア OS (´・_・`)どこに入るとも言い難い… ハードウェア
  22. 22. プログラミング言語が、ほかの計算機科学の分野と異なる点 プログラミング言語処理系、それ自身がプログラムである プログラミング言語は、本質的に自己言及を伴う分野である (かつ、本質的にすべてのプログラマに影響を与える) 油断すると、あらゆる矛盾、パラドクスがやってくる (´・_・`)「そしてパラドクスは、哲学、オカルト、最終的には宗教まで介入させる」 (`・д・´)「宗教て!」
  23. 23. 自己言及のパラドックス(嘘つきのパラドックス) 「この文は偽である」← は真か偽か? (´・_・`)「真だとすると、「この文は偽である」というのが偽になって矛盾する し、偽だとすると、「この文は偽である」が真になってしまうし……」 (`・д・´)「どっちやねん!」
  24. 24. ラッセルのパラドックス(素朴集合論) 自分自身をそれに含まないものの集合をA、含むものの集合をBとする 「Aの要素全てからなる集合」は、A、Bどちらに含まれるのだろうか? (´・_・`)「Aに含まれるとすると、その集合は自分自身を含まないことになるけ ど、そうすると、その集合がAに含まれるのはおかしいし、Bに含まれるとして も、逆の理由でおかしくなるし…」 (`・д・´)「どないやねん!」
  25. 25. ラッセルの型理論(階型理論) 素朴集合論の問題を解決するために、構築される  自己言及的な命題を記述できないようにすればいい  (詳細は略)要するに、式を型で分類するという発想  「プリンキピア・マテマティカ」にて定義 現代のプログラミング言語における、型理論、型システムの礎
  26. 26. ゲーデルの不完全性定理 「プリンキピア・マテマティカと関連体系における決定不能な命題についてI」 第1不完全性定理  自然数論を含む帰納的に記述できる公理系が、ω無矛盾であれば、証明も反証もできな い命題が存在する。 第2不完全性定理  自然数論を含む帰納的に記述できる公理系が、無矛盾であれば、自身の無矛盾性を証明 できない。
  27. 27. どういうこと? ゲーデルの定理では、ゲーデル数というものを持ち出すことにより、巧妙に型の 間をすり抜け、不完全性を導く…… (´・_・`)「なるほど、わからん!」 (`・д・´)「という人には、『数学ガール ゲーデルの不完全性定理』がお勧めだ」
  28. 28. 時に数学は、数学の世界の外で語られる フェルマーの最終定理が話題に 最近だとペレルマンによるポアンカレ予想の解決 ゲーデルの定理は、昔から根強く、最も人気のあるコンテンツの一つ (´・_・`)「数学以外でも、シュレディンガーの猫やら、相対性理論やら、ヴィトゲ ンシュタインやらはよく出てくるね」 (`・д・´)「ライトなSFがお手軽にインテリ風になるらしいぞ!」
  29. 29. 数学の世界の外で起こること 「なんかすごい定理が証明されたらしいぞ!」 「えー、それってどんなことなのー?」 「詳しいことはよくわからんけど、こういうことらしいぞ」 (めいめいが、自分の言葉で自分の理解を語り始める) (´・_・`)「まあ、僕も数学の世界の中のことはよく知らないんで」 (´-_-`) …「そんな時代もありました」
  30. 30. ゲーデルの不完全性定理? (´・_・`)「公理系が無矛盾であれば、それは自身の無矛盾性を証明できない」 ( ˘⊖˘) 。O(待てよ……!?) | \ __ / _ (m) _ピコーン |ミ| / .`´ \ ∧_∧ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ (´・_・`∩< 数学の証明なんて全部間違いやったんや!! (つ 丿 \_________ ⊂_ ノ (_)
  31. 31. ゲーデルの定理の濫用例 「ゲーデルの不完全性定理は、客観的現実の存在は証明できないことを示してい る」 「ゲーデルの不完全定理によって、全ての情報は本質的に不完全で、自己言及的 である」 「存在と意識を同等に考えることによって、私たちはゲーデルの不完全性定理を 進化論に応用できる」 「ゲーデルの定理こそ汲めども尽きぬ知識濫用の泉である」(アラン・ソーカ ル、ジャンブリクモン) トルケル・フランセーン「ゲーデルの定理 利用と誤用の不完全性ガイド」より
  32. 32. そして一人歩きし始める 「ゲーデルの不完全性定理は、数学的なアプローチや証明なしにも直感的に理解 しうるものである。実際、禅仏教思想の中にも明瞭にそれとわかる形で不完全性 定理の概念が出現しているからだ。」 トルケル・フランセーン「ゲーデルの定理 利用と誤用の不完全性ガイド」より
  33. 33. 濫用の背景 定理に出てくる専門用語が、日常で使われている言葉  「矛盾」「無矛盾」  「完全」「不完全」  「体系(システム)」 インフォーマルな意味で解釈すると  とても破天荒なことを言っている  面白いし、いろいろなアイデアと結び付けられてしまう(けど大抵は意味を成さない) ゲーデルの定理の応用は、多くの人が期待するようなものではなく、 正しく数学的な定義に従ったものに限られる
  34. 34. (チューリングマシンの)停止性問題 プログラム(チューリングマシン)が(有限時間で)停止するかどうかを 判定する問題 停止性問題を解くプログラム(チューリングマシン)は存在しない (チューリングマシンの停止性問題は決定不能) 対角線論法による証明が有名で、よく例として出てくる
  35. 35. 停止性問題の濫用http://d.hatena.ne.jp/sumii/20090310/p2 http://d.hatena.ne.jp/noopable/20090528/1243503981
  36. 36. “ 語りえぬものについては、 沈黙しなければならない ルートヴィヒ・ウィトゲンシュタイン「論理哲学論考」命題 7 ”※誤用です
  37. 37. さて、プログラミング言語を語るにあたって プログラミング言語、及びそれにまつわる研究を語るにあたっての “ここでの”前提  プログラミング言語研究は科学である  プログラミング言語に関する定理、証明、その他全てのものについて、  好む好まざる  哲学的  宗教的  魔術的  あるいはその他  の立場に基づく、あらゆる誤用、自由連想を控えなければならない (´・_・`)「プログラミング言語?ただのテクノロジーですよ」
  38. 38. POPLに見る、プログラミング言語研究の今
  39. 39. プログラミング言語研究の潮流 Verification Concurrency, Memory Model Formal Semantics Types etc…
  40. 40. Verificationが大人気 今、プログラムの静的形式的検証がアツい!!  どのぐらいアツいかというと、Verificationと書くだけで、採択率大幅アップ! さらに、ワークショップも充実
  41. 41. 併設ワークショップ
  42. 42. 併設ワークショップ verification
  43. 43. Verification関連の研究 “Cache and I/O efficient functional algorithms.”  メモリヒエラルキを考慮した、アルゴリズムのI/Oコストの静的解析 “On the linear ranking problem for integer linear-constraint loops. ”  ある種のプログラムに対する、停止性判定 “The power of parameterization in coinductive proof.”  Coqにおける、coinductionを用いた証明の改善 Microsoft Research Verified Software Milestone Award  CompCert(証明付きコンパイラ)プロジェクトが受賞
  44. 44. なんでそんなにVerification? バグを取るのは難しい、という大前提  簡単だ、と主張する人も、いるようですが… 検証は、テストより強し  バグの不在の証明なので (なにより、形式的検証は、プログラムの性質を知ろうとすることなので、難し い) (難しいことは研究になる)
  45. 45. バグのない世界を想像してみる( ˘⊖˘)。o(待てよ、プログラムにバグがないのなら…)  デバッグする必要がない  テスト書く必要がない  テストする必要がない  デグレードの心配がないので、プログラムのリファクタリングが自由自在  バグ修正のためのメンテが必要ない  プログラミングのコスト大幅減!|POPL|┗(☋` )┓三 ( ◠‿◠ )☛そんなうまい話があるか▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわああああああああ
  46. 46. 現実:バグのないプログラムを書くのは、それなりに大変 型ベースの証明を書く  Coq, Agda, etc …  ソフトウェアの基礎  プログラミング Coq 〜 絶対にバグのないプログラムの書き方 〜 Symbolic Execution + SAT/SMT Solver  sbv(Haskell), vcc(C言語), … モデル検査  いろいろ (´・_・`)「コスト的に見合わんかもだぽよ……」
  47. 47. デバッグしづらいものに向いてる ハードウェア  昔からモデル検査がよく行われてきた  (ハードウェアに対するモデル検査は決定不能じゃないケースもある) 並行・並列プログラム  大体のバグが、忘れた頃にやってくる  再現が難しい  静的に安全だと判明した部分の、同期処理を省いてパフォーマンス向上目指すなども
  48. 48. でも、証明じゃなくてプログラムを書きたいんです! (´・_・`)「僕証明とか嫌いなんで……」 証明お好きですか(脳内調べ)? 嫌い どちらかというと嫌い わからない 考えたこともない
  49. 49. Curry-Howard isomorphism 「プログラム=証明」「型=命題」との間の同型対応 (`・д・´)「この事実が示すことは……」 (´・_・`)「つまり…どういうことだってばよ?」 (`・д・´)「プログラムを書く事は、証明を書く事と同じってことだよ」 (´・_・`)「な、なんだってーー(棒」
  50. 50. 穴駆動開発(youtube: hole driven haskell)
  51. 51. 2012 Verified Software MilestoneAward: ConpCert project 検証されたコンパイラを作ろうというプロジェクト  Coqにより(大部分を)証明されたコード 現在、ISO-C-90と ANSI-C といくつかのGCC拡張をサポート 2005年スタート、2012年に浮動小数点演算の完全な形式化と検証が完了
  52. 52. なぜ、コンパイラの正しさが重要なのか? コンパイラは、もっとも複雑なソフトウェアの一つである コンパイラの正しさは、すべてのソフトウェアに影響を与える 正しいコンパイラを作るのは難しい  最適化が行うコードの変更によって、コードの意味が変わらないか  メモリモデルに違反する最適化を行わないかなど  最適化フェーズの組み合わせによって、コードの意味が変わらないか
  53. 53. Coq自身の正しさは? (´・_・`)「あれ、Coq自身の正しさは…」 (`・д・´)「証明されてないな」 (´・_・`)「CoqでCoqを書けば…?」 (`・д・´)「”証明されてないCoq”で証明されたCoqは、正しいと言えるのか?」 (´・_・`)「あ、これゲーデルの定理でやったところだ!!(濫用)」
  54. 54. 停止性問題再び Formal Verificationには、プログラムの停止性が必要なことも多い (´・_・`)「停止性問題から、プログラムの停止性はわからないんじゃないの?」 (`・д・´)「そんなことはないよ!」  完全性を考えなければ何とでもなる  停止する・停止しない・わからん!の3択を返す関数ならいくらでも書ける  チューリング完全じゃないプログラミング言語を使う  停止性問題は、チューリングマシンに対する定理なので、 チューリング完全じゃなければ当然当てはまるとは限らない
  55. 55. 不完全な停止性判定アルゴリズム 特定の性質を満たすプログラムに対するもの  integer linear-constraint loops など Abstract Interpretation + SMTソルバ  ∀input. ∃time. cycles(f, input) < time なる充足可能性問題  もちろん決定不能(だけど、解けるときは解ける) Idrisとかの部分的停止性判定  再帰の引数が短調減少になってるかだけ調べる
  56. 56. チューリング完全を捨てる (´・_・`)「そんな言語でまともなコード書けるんですか?Brain F*ckですらチュー リング完全なのに…」 (`・д・´)「かけるぞ」 Coq:チューリング完全にならないように、慎重に設計した、非常に記述力の高 い言語(語弊有り)
  57. 57. 検証にまつわる現在の状況 証明方面  今現在のCoqでは、証明書くのが大変すぎるので、どげんかせんといかん  たくさんの手法が提案されてきている  将来的には息をするように証明が書ける世界を目指している(のかな?) モデル検査方面  バックエンドのSAT/SMTソルバがここ10年ほどで驚きの爆速に  やれることが増えてきているもよう
  58. 58. メモリモデルの話 ここ10年ですっかりCPUがマルチコアになってしまった 今時スレッドを使わないプログラムを書いてる男の人って… しかし、並行・並列プログラムはとっても難しい! 難しいので当然研究されている POPLでもよく扱われている
  59. 59. double-checked lockingとSingletonパターン 比較的最近破綻した、有名なデザインパターン Singletonオブジェクトを作るときに、 2回チェックすると、ロックの回数が減らせる(はずだった)
  60. 60. Javaのメモリモデルの問題 コンパイラの最適化、あるいはCPU内のアウトオブオーダで、メモリアクセスの 順序が入れ替わってしまう メモリモデルとして、形式的に定義せねばならない JVMのメモリモデルをSequential Consistencyとして定義(POPL2005) その後Counter-exampleが二度にわたりPOPLで指摘される 今年、Buffered Memory Model による形式化(POPL2013)
  61. 61. C11/C++11のメモリモデル問題(POPL2013) もともとC/C++はメモリモデルの規定がなかった  みんな、volatile asm mfence! C11/C+11で Relaxed Memory Consistency が導入される  これはこれで、いろいろ厄介な問題! このメモリモデル上での、ライブラリの安全な抽象化方法を考える研究
  62. 62. ちなみにCompCertでは x86とPPCのメモリモデルに準拠したTSOを形式的に定義  CompCert TSO 最適化などが、これを違反しないことを証明済み
  63. 63. JavaScriptのFormal Definition JavaScript and Web Tools  executable semantics for JavaScript  executable model of event dispatch in Web browsers  (Coqで証明済み) Rhino, SpiderMonkey, V8などの違いが浮き彫りに  そもそもどれが正しいのか  Rhinoをリファレンス動作として採用した
  64. 64. まとめ
  65. 65. まとめ プログラミング言語研究の最前線の紹介 プログラミング言語研究は、本質的にHigher-orderで自己言及的 だからこそ、変な方向に話がそれがち でも、だからこそ、面白い! m(´・_・`)m「ご清聴、ありがとうございました!」

×