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

1. 「再代入なんて、あるわけない」
～ふつうのプログラマが関数型言語を知るべき理由～
There is no reassignment.
Present by ぱろっと(@parrot_studio)
for Gunma.web #5
2011/05/14

2. Profile
Twitter : @parrot_studio
hatena/github : parrot_studio

3. 第1話
「参照透明性も、遅延評価も、あるんだよ」
Referential transparency and Lazy evaluation is here.

4. 関数型言語
＝数学の概念を実装したもの

5. 関数型言語の
代表的な特性を3つ
(´･ω･)っ

6. 数学で
s=α+β
とか置いてから、後で
s=αβ
と置きなおすなんてことはしない
（s’=αβならある）

7. 「s」は変数ではなく、
「α+β」に名前を「定義」しただけ
（関数型では「束縛」と表現する）

8. It’s 再代入不可

9. だから「i += 1」なんてできない
CやJSのようなfor文は書けない
Σ(ﾟДﾟ)ｶﾞｰﾝ
=> 「再帰」「List処理」等を使う

10. 逆に、こんなことは考えなくていい
@a = 2 # 変数aに2を代入
def f(x) # 変数aに加算して返す関数
@a + x
end
puts f(2) #=> 2+2=4
# 何か長い処理
# 途中で @a=5 とかされるかも？
puts f(2) # この値はいくつ(´･ω･)？

11. 再代入ができない
＝f(x)の値はxが決まれば一意に決まる
（関数の呼び出しに副作用がない）

12. じゃあ、f(2)=4なら、
f(2)を4に全部置き換えていいよね？

13. It’s 参照透明性

14. “いつ”計算しても同じ値になるなら、
「必要になったら」計算しても
同じだよね？

15. It’s 遅延評価

16. f(x) = (x-1)(なんか難しい式)
のとき、f(1) = 0 は
後ろを計算しなくてもわかるよね？

17. でも・・・

18. 俗に言う「関数型言語」が、
この3つを「全部」もっているかというと、
そうでもないΣ(・ω・ノ)ノ

19. 純関数型 全部「強制」
例：Haskell
関数型 どれかが欠けているとか、オプション
例：Scala/Erlang/OCaml
関数型風記述 関数型っぽく書ける
例：最近流行の言語（Ruby/JS/C#等）
手続き型 関数型っぽく書くこと自体が難しい
例：C/Java/Perl
※分類方法は個人的に考えた適当なものです

20. なぜ「関数型風」に書けると嬉しいのか？
「関数型言語」を使うとどんなことができるのか？

21. 第2話
「宣言的なのはとっても嬉しいなって」
It is very glad to declarative..

22. 関数型（風）のコード
＝「定義(define)」の連鎖

23. 関数型っぽく書いたRubyのコード
def room_blocks
blocks.select(&:has_room?)
end
def rooms
room_blocks.collect(&:room)
end
def start_point
rooms.sample(1).random_point
end

24. 「手続き」ではなく
「宣言・定義」
＝「これは～です」が並ぶ

25. def room_blocks
blocks.select(&:has_room?)
end
room_blocks とは blocksの中で
roomを持っているものを選んだものである

26. def rooms
room_blocks.collect(&:room)
end
rooms とは room_blocks のroomを
集めたものである

27. def start_point
rooms.sample(1).random_point
end
start_point とは roomsの中から
一つサンプリングして、
ランダムな座標を選んだものである

28. 一つ一つの「定義」は小さいから、
個別のテスト（spec）も書きやすい
(｀･ω･´) ｂ

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. 「やりたいこと」が埋もれるので、
「読みやすい」というのは非常に重要

31. ”名前重要” by matz
「97きのこ」：J10 / 「コードの世界」：P150

32. 第3話
「もうデッドロックは怖くない」
Deadlock not afraid anymore.

33. 関数の値が入力だけで決まるなら、
「いつ」「どこで」処理しても結果は同じ

34. なら、並列処理してもいいよね
(´･ω･)？

35. 並列処理手法の一つ：アクターモデル

36. アクターモデルの話だけで
LTどころではない時間を食うので、
簡単に説明

38. アクターモデルの場合
この処理を頼みたいんだが・・・
あーそこのBOXに入れておいてください
後でやっておきます
...φ(･ω･｀) 各自の処理 ...φ(･ω･｀)
頼まれた処理終わりましたよ
じゃあ、私のBOXに入れておいてくれ
後で確認する
...φ(･ω･｀) 各自の処理 ...φ(･ω･｀)

39. 「値」は「入力」によって決まり、
「状態」に依存しないから、
アクター間で「状態」を共有する必要がない
＝ロックが不要

40. 詳しくは・・・
ScalaのアクターモデルでMapReduce処理を書いてみる
d.hatena.ne.jp/parrot_studio/20110205/1296880522

41. 第4話
「本当の副作用と向き合えますか?」
Can it be opposite to a true side effect?

42. 関数型の概念自体は60年代からあるが、
「時代」が関数型を求め始めた
マルチコアCPU / サーバクラスタ（Hadoop等）

43. ほっといてもCPUは速くならない
プログラマが工夫する時代へ
「フリーランチの終焉」
matz@日経Linux 2011/05

44. もはや、
「普通のプログラマ」と
関数型は無関係ではないかもしれない

45. 実は、関数型の概念は理想的なもの

46. 「画面に表示する」
「DBやファイルからデータを読む」
どれもリソースに依存して結果が変わる
＝副作用がある

47. できるだけ副作用のある箇所を
局所的にして、切り離すことが重要

48. 「読みやすく」「副作用の少ない」
関数型の概念を学んでみませんか
(´･ω･)？

49. ありがとうございました
(´･ω･)っ旦~

50. 参考文献

51. 【おまけ】

52. そもそも、Rubyは
「綺麗に書くほど速い＝最適化される」
言語

53. Rubyで先ほどのような
for文はまず使わない
確実に「もっと美しい書き方」がある

54. Rubyを「知る」には
実は関数型の概念がいる
私がRubyのありがたさを実感したのは
「ふつうのHaskell」を読んだ後

55. 実際、関数型として書いたRubyと
元々関数型のScalaのコードは
非常によく似ている

56. コマ大数学科の問題をRubyとScalaで解いてみる
d.hatena.ne.jp/parrot_studio/20110302/1299051431