「再代入なんて、あるわけない」~ふつうのプログラマが関数型言語を知るべき理由~                     There is no reassignment.     Present by ぱろっと(@parrot_studio) ...
ProfileTwitter : @parrot_studiohatena/github : parrot_studio
第1話「参照透明性も、遅延評価も、あるんだよ」   Referential transparency and Lazy evaluation is here.
関数型言語=数学の概念を実装したもの
関数型言語の代表的な特性を3つ  (´・ω・)っ
数学で     s=α+β  とか置いてから、後で     s=αβと置きなおすなんてことはしない   (s’=αβならある)
「s」は変数ではなく、「α+β」に名前を「定義」しただけ (関数型では「束縛」と表現する)
It’s   再代入不可
だから「i += 1」なんてできないCやJSのようなfor文は書けない     Σ(゚Д゚)ガーン=> 「再帰」「List処理」等を使う
逆に、こんなことは考えなくていい @a = 2 # 変数aに2を代入 def f(x) # 変数aに加算して返す関数  @a + x end puts f(2) #=> 2+2=4 # 何か長い処理 # 途中で @a=5 とかされるかも? pu...
再代入ができない=f(x)の値はxが決まれば一意に決まる   (関数の呼び出しに副作用がない)
じゃあ、f(2)=4なら、f(2)を4に全部置き換えていいよね?
It’s   参照透明性
“いつ”計算しても同じ値になるなら、「必要になったら」計算しても     同じだよね?
It’s   遅延評価
f(x) = (x-1)(なんか難しい式)    のとき、f(1) = 0 は後ろを計算しなくてもわかるよね?
でも・・・
俗に言う「関数型言語」が、この3つを「全部」もっているかというと、   そうでもないΣ(・ω・ノ)ノ
純関数型      全部「強制」          例:Haskell関数型       どれかが欠けているとか、オプション          例:Scala/Erlang/OCaml関数型風記述    関数型っぽく書ける          例...
なぜ「関数型風」に書けると嬉しいのか?「関数型言語」を使うとどんなことができるのか?
第2話「宣言的なのはとっても嬉しいなって」         It is very glad to declarative..
関数型(風)のコード=「定義(define)」の連鎖
関数型っぽく書いたRubyのコードdef room_blocks blocks.select(&:has_room?)enddef rooms room_blocks.collect(&:room)enddef start_point room...
「手続き」ではなく  「宣言・定義」=「これは~です」が並ぶ
def room_blocks blocks.select(&:has_room?)endroom_blocks とは blocksの中でroomを持っているものを選んだものである
def rooms room_blocks.collect(&:room)endrooms とは room_blocks のroomを集めたものである
def start_point rooms.sample(1).random_pointendstart_point とは roomsの中から一つサンプリングして、ランダムな座標を選んだものである
一つ一つの「定義」は小さいから、個別のテスト(spec)も書きやすい      (`・ω・´) b
あえて手続きで書くと・・・ def room_blocks  ret = []  for i in (0..blocks.size)    if blocks[i].has_room?      ret << blocks[i]    end ...
「やりたいこと」が埋もれるので、「読みやすい」というのは非常に重要
”名前重要” by matz 「97きのこ」:J10 / 「コードの世界」:P150
第3話「もうデッドロックは怖くない」        Deadlock not afraid anymore.
関数の値が入力だけで決まるなら、「いつ」「どこで」処理しても結果は同じ
なら、並列処理してもいいよね    (´・ω・)?
並列処理手法の一つ:アクターモデル
アクターモデルの話だけでLTどころではない時間を食うので、     簡単に説明
アクターモデルの場合    この処理を頼みたいんだが・・・        あーそこのBOXに入れておいてください        後でやっておきます...φ(・ω・`)   各自の処理            ...φ(・ω・`)         ...
「値」は「入力」によって決まり、   「状態」に依存しないから、アクター間で「状態」を共有する必要がない      =ロックが不要
詳しくは・・・ScalaのアクターモデルでMapReduce処理を書いてみる    d.hatena.ne.jp/parrot_studio/20110205/1296880522
第4話「本当の副作用と向き合えますか?」     Can it be opposite to a true side effect?
関数型の概念自体は60年代からあるが、   「時代」が関数型を求め始めた マルチコアCPU / サーバクラスタ(Hadoop等)
ほっといてもCPUは速くならないプログラマが工夫する時代へ  「フリーランチの終焉」     matz@日経Linux 2011/05
もはや、  「普通のプログラマ」と関数型は無関係ではないかもしれない
実は、関数型の概念は理想的なもの
「画面に表示する」  「DBやファイルからデータを読む」どれもリソースに依存して結果が変わる     =副作用がある
できるだけ副作用のある箇所を局所的にして、切り離すことが重要
「読みやすく」「副作用の少ない」関数型の概念を学んでみませんか     (´・ω・)?
ありがとうございました  (´・ω・)っ旦~
参考文献
【おまけ】
そもそも、Rubyは「綺麗に書くほど速い=最適化される」       言語
Rubyで先ほどのような   for文はまず使わない確実に「もっと美しい書き方」がある
Rubyを「知る」には実は関数型の概念がいる私がRubyのありがたさを実感したのは  「ふつうのHaskell」を読んだ後
実際、関数型として書いたRubyと元々関数型のScalaのコードは   非常によく似ている
コマ大数学科の問題をRubyとScalaで解いてみる    d.hatena.ne.jp/parrot_studio/20110302/1299051431
「再代入なんて、あるわけない」 ~ふつうのプログラマが関数型言語を知るべき理由~ (Gunma.web #5 2011/05/14)
Upcoming SlideShare
Loading in …5
×

「再代入なんて、あるわけない」 ~ふつうのプログラマが関数型言語を知るべき理由~ (Gunma.web #5 2011/05/14)

19,157 views
18,897 views

Published on

Gunma.web #5でやったLT資料
実際のLT時には非表示にしていたページを含む

Published in: Technology

「再代入なんて、あるわけない」 ~ふつうのプログラマが関数型言語を知るべき理由~ (Gunma.web #5 2011/05/14)

  1. 1. 「再代入なんて、あるわけない」~ふつうのプログラマが関数型言語を知るべき理由~ There is no reassignment. Present by ぱろっと(@parrot_studio) for Gunma.web #5 2011/05/14
  2. 2. ProfileTwitter : @parrot_studiohatena/github : parrot_studio
  3. 3. 第1話「参照透明性も、遅延評価も、あるんだよ」 Referential transparency and Lazy evaluation is here.
  4. 4. 関数型言語=数学の概念を実装したもの
  5. 5. 関数型言語の代表的な特性を3つ (´・ω・)っ
  6. 6. 数学で s=α+β とか置いてから、後で s=αβと置きなおすなんてことはしない (s’=αβならある)
  7. 7. 「s」は変数ではなく、「α+β」に名前を「定義」しただけ (関数型では「束縛」と表現する)
  8. 8. It’s 再代入不可
  9. 9. だから「i += 1」なんてできないCやJSのようなfor文は書けない Σ(゚Д゚)ガーン=> 「再帰」「List処理」等を使う
  10. 10. 逆に、こんなことは考えなくていい @a = 2 # 変数aに2を代入 def f(x) # 変数aに加算して返す関数 @a + x end puts f(2) #=> 2+2=4 # 何か長い処理 # 途中で @a=5 とかされるかも? puts f(2) # この値はいくつ(´・ω・)?
  11. 11. 再代入ができない=f(x)の値はxが決まれば一意に決まる (関数の呼び出しに副作用がない)
  12. 12. じゃあ、f(2)=4なら、f(2)を4に全部置き換えていいよね?
  13. 13. It’s 参照透明性
  14. 14. “いつ”計算しても同じ値になるなら、「必要になったら」計算しても 同じだよね?
  15. 15. It’s 遅延評価
  16. 16. f(x) = (x-1)(なんか難しい式) のとき、f(1) = 0 は後ろを計算しなくてもわかるよね?
  17. 17. でも・・・
  18. 18. 俗に言う「関数型言語」が、この3つを「全部」もっているかというと、 そうでもないΣ(・ω・ノ)ノ
  19. 19. 純関数型 全部「強制」 例:Haskell関数型 どれかが欠けているとか、オプション 例:Scala/Erlang/OCaml関数型風記述 関数型っぽく書ける 例:最近流行の言語(Ruby/JS/C#等)手続き型 関数型っぽく書くこと自体が難しい 例:C/Java/Perl ※分類方法は個人的に考えた適当なものです
  20. 20. なぜ「関数型風」に書けると嬉しいのか?「関数型言語」を使うとどんなことができるのか?
  21. 21. 第2話「宣言的なのはとっても嬉しいなって」 It is very glad to declarative..
  22. 22. 関数型(風)のコード=「定義(define)」の連鎖
  23. 23. 関数型っぽく書いたRubyのコードdef room_blocks blocks.select(&:has_room?)enddef rooms room_blocks.collect(&:room)enddef start_point rooms.sample(1).random_pointend
  24. 24. 「手続き」ではなく 「宣言・定義」=「これは~です」が並ぶ
  25. 25. def room_blocks blocks.select(&:has_room?)endroom_blocks とは blocksの中でroomを持っているものを選んだものである
  26. 26. def rooms room_blocks.collect(&:room)endrooms とは room_blocks のroomを集めたものである
  27. 27. def start_point rooms.sample(1).random_pointendstart_point とは roomsの中から一つサンプリングして、ランダムな座標を選んだものである
  28. 28. 一つ一つの「定義」は小さいから、個別のテスト(spec)も書きやすい (`・ω・´) b
  29. 29. あえて手続きで書くと・・・ def room_blocks ret = [] for i in (0..blocks.size) if blocks[i].has_room? ret << blocks[i] end end return ret end
  30. 30. 「やりたいこと」が埋もれるので、「読みやすい」というのは非常に重要
  31. 31. ”名前重要” by matz 「97きのこ」:J10 / 「コードの世界」:P150
  32. 32. 第3話「もうデッドロックは怖くない」 Deadlock not afraid anymore.
  33. 33. 関数の値が入力だけで決まるなら、「いつ」「どこで」処理しても結果は同じ
  34. 34. なら、並列処理してもいいよね (´・ω・)?
  35. 35. 並列処理手法の一つ:アクターモデル
  36. 36. アクターモデルの話だけでLTどころではない時間を食うので、 簡単に説明
  37. 37. アクターモデルの場合 この処理を頼みたいんだが・・・ あーそこのBOXに入れておいてください 後でやっておきます...φ(・ω・`) 各自の処理 ...φ(・ω・`) 頼まれた処理終わりましたよ じゃあ、私のBOXに入れておいてくれ 後で確認する...φ(・ω・`) 各自の処理 ...φ(・ω・`)
  38. 38. 「値」は「入力」によって決まり、 「状態」に依存しないから、アクター間で「状態」を共有する必要がない =ロックが不要
  39. 39. 詳しくは・・・ScalaのアクターモデルでMapReduce処理を書いてみる d.hatena.ne.jp/parrot_studio/20110205/1296880522
  40. 40. 第4話「本当の副作用と向き合えますか?」 Can it be opposite to a true side effect?
  41. 41. 関数型の概念自体は60年代からあるが、 「時代」が関数型を求め始めた マルチコアCPU / サーバクラスタ(Hadoop等)
  42. 42. ほっといてもCPUは速くならないプログラマが工夫する時代へ 「フリーランチの終焉」 matz@日経Linux 2011/05
  43. 43. もはや、 「普通のプログラマ」と関数型は無関係ではないかもしれない
  44. 44. 実は、関数型の概念は理想的なもの
  45. 45. 「画面に表示する」 「DBやファイルからデータを読む」どれもリソースに依存して結果が変わる =副作用がある
  46. 46. できるだけ副作用のある箇所を局所的にして、切り離すことが重要
  47. 47. 「読みやすく」「副作用の少ない」関数型の概念を学んでみませんか (´・ω・)?
  48. 48. ありがとうございました (´・ω・)っ旦~
  49. 49. 参考文献
  50. 50. 【おまけ】
  51. 51. そもそも、Rubyは「綺麗に書くほど速い=最適化される」 言語
  52. 52. Rubyで先ほどのような for文はまず使わない確実に「もっと美しい書き方」がある
  53. 53. Rubyを「知る」には実は関数型の概念がいる私がRubyのありがたさを実感したのは 「ふつうのHaskell」を読んだ後
  54. 54. 実際、関数型として書いたRubyと元々関数型のScalaのコードは 非常によく似ている
  55. 55. コマ大数学科の問題をRubyとScalaで解いてみる d.hatena.ne.jp/parrot_studio/20110302/1299051431

×