Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

メイキング オブ 関数型プログラミングマンガ - 関数プログラミング交流会 2015

1,755 views

Published on

#fpmeetup で話した内容です

Published in: Technology

メイキング オブ 関数型プログラミングマンガ - 関数プログラミング交流会 2015

  1. 1. メイキング オブ 関数型プログラミング マンガ esehara shigeo
  2. 2. 謝罪
  3. 3. サンプルコード全く 書けませんでした
  4. 4. 圧倒的 土下座
  5. 5. 気をとりなおして
  6. 6. お前 誰だ
  7. 7. esehara shigeo (31) twitter: @esehara Logbar Inc. Clojuren 最近の趣味: OCaml
  8. 8. 現在の画力 『マンガでわか『マンガでわかる!関数型 プログラミング』やめてほしいとしか思って ない『マンガでわかる!関数型プログラミ ング』やめてほしいとしか思ってないマン ガでわかる!関数型プログラミング』やめ てほしいとしか思ってない『マンガでわか る!関数型プログラミング』やめてほしい
  9. 9. 一応、こういう地道な練習はしているんですよ……
  10. 10. 圧倒的 現実
  11. 11. 進捗
  12. 12. 現段階で ボツネーム 4回目
  13. 13. 人間がゾンビ化した 世界
  14. 14. ネオナゴヤで 「食料」を奪取する為の 関数型プログラミング…
  15. 15. 締め切りまで あと11日
  16. 16. 無事、彼は 原稿を届けることが 出来るのだろうか
  17. 17. 続報を 待て
  18. 18. 結論: マンガを書くの は難しい
  19. 19. 宣伝 終了
  20. 20. 最高のIoTデバイス 買ってください!!
  21. 21. 宣伝 終了
  22. 22. ところで何処が 「関数型 プログラミング」 なんですか
  23. 23. 本題
  24. 24. なぜ 関数型プログラミングを 「説明」することが 難しいのか esehara shigeo
  25. 25. 問題
  26. 26. そもそも 「関数型プログラミング」 と定義される場合の 「関数型」の特徴とは?
  27. 27. 関数型プログラミングの特徴は「関数を第 一級の対象(first class-object)である」、 つまり関数を引数にしたり、関数を結果の 値とするようなもの。(by 『関数型プログラミング』R.ロ バート/P.ワドラーより) 現状、PythonやJavaScriptは「関数を第一級の対象」にできる といえるわけだから、ちょっとこれでは説明が足りない
  28. 28. 関数型プログラミングは、コマン ドの実行を強調するプログラミン グスタイルではなく、式の評価を 強調します。これらの言語での式 (expression)は、基本的な値を 結合するための関数を用いて形 成されています。関数型言語ファ ンクショナルなスタイルでプログ ラミングを推奨し、サポートする 言語です。 Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands. The expressions in these language are formed by using functions to combine basic values. A functional language is a language that supports and encourages programming in a functional style.
  29. 29. 代入を使わないうちは, 同じ引数での同じ手 続きの二回の評価は同じ結果を生じ,手続き は数学的関数を計算すると見ることが出来 た. 本書の初めの二章でやったように, 代入 を使わないプログラミングは, 従って 関数型 プログラミング(functional programming) という. (by SICP)
  30. 30. 「副作用をできるだけ(ある いは全く)用いず、式や関 数で計算を表すプログラミ ングスタイルのことです。」 (by Eijiro Sumii)
  31. 31. 筆者の関数プログラミングの定義,すなわちこの特集での定義 は,「永続データプログラミング」です。永続データとは,破壊でき ないデータ,つまり再代入できないデータのことです。そして,永 続データを駆使して問題を解くのが永続データプログラミングで す。 また関数型言語とは,永続データプログラミングを奨励し支援し ている言語のことです。関数型言語では,再代入の機能がない か,再代入の使用は限定されています。筆者の定義はかなり厳 しいほうだと言えます。(by 山本和彦)
  32. 32. 死ぬほど 定義出てくる 時点でムズい!!
  33. 33. 強引なまとめ ● 関数を第一級オブジェクト(=値と同一)のものと して取り扱う(これはそうではない言語もあるの で怪しい?) ● 副作用をできるだけ使わず、式や関数で表現す る ● イミュータブルな(不変のデータ構造)を重要視 する
  34. 34. 蛇足
  35. 35. 最近の本(『実践関数プログラミング』)だと、 いわゆる「Lisp」(正確にはCommon Lisp、 Scheme)という理由だけで関数型言語の仲 間には入れない感じ(Lispは”Lisp”というパ ラタイム) Common Lispはバリバリ、データ構造を変更しまくる。ただ、 Clojureは不変のデータ構造を意識させるために仲間にされること はある(いちおう、Racket langという処理系も、明示的にデータを Immutableにすることは可能)
  36. 36. 歴史
  37. 37. 「オブジェクト指向」 vs 「関数型プログラミング」
  38. 38. 「オブジェクト指向」 vs 「関数型プログラミング」
  39. 39. 前段階としての 構造化 プログラミング
  40. 40. 「順次、分岐、反復」の三種の神器
  41. 41. top-down program development + stepwise refinement
  42. 42. 批判
  43. 43. 構造化プログラミングは 制御の流れしか 捉えられておらん
  44. 44. そもそも 計算のパターンと 状態の変化 そのものを対応するのは 難しいやろが
  45. 45. 代入
  46. 46. そもそも 変化とは何か (哲学)
  47. 47. 参照透明性を一旦捨てると, 計算オブジェクトが「同じ」であるとは 何を意味するかの概念を形式的に捕らえるのは難しくなる. 実は われわれのプログラムがモデル化している実世界の「同じ」の意 味もあまりはっきりしない. 一般に二つの見かけ上同じなオブジェ クトが本当に「同じもの」であるかは, 一つのオブジェクトを変えて みて, もう一つのオブジェクトが同じように変っているかを見て決 める. しかし「同じ」オブジェクトを二度観測し, オブジェクトのある 性質が一回目と二回目の観測で違っているということ以外に, あ るオブジェクトが「変った」ことがどうして分るだろうか. つまり何か 先験的な 「同一」という概念なしに「変化」を決めることは出来ず, 変化の効果を観測することなしに同一性を決めることは出来な い.(SICPより)
  48. 48. 手続き型プログラムを学ぶ際の障壁の一つ が代入(assignment)の概念であることは随 所で指摘されている。これは計算過程と計 算状態という考え方が初心者にとっては新 奇なものでなじめないということにも理由が あろう。
  49. 49. 多くのプログラミング学習者が理解に苦しむ問題を調査した所、以 下のような結果が得られた。 ●代入とシーケンス実行 ●再帰と繰り返し実行 ●並列実行 再帰やループはたしかに難しい。並列実行はとても難しいが、多く の挫折者はそこまで到達しない。しかし、代入とシーケンス実行とい う、プログラミングの最も基本的である概念の理解に苦しむとはどう いうことか。 (60%の人間はプログラミングの素質がない - 本の虫)
  50. 50. 破壊的代入は 強すぎる
  51. 51. 強すぎる = ハイリスク ハイリターン
  52. 52. 逆に 関数型プログラミングの 理解のしにくさは 何処にある
  53. 53. 調査
  54. 54. 大体こんな感じ? ● インターネットがまだ無い時代に図書館で読み漁った本で、 まず、関数っていう物の意味が分からなかったんですよね。 ● 「実行順序の無いプログラム」というのがよく分かりません。 「SQLもループ処理の一部を書いているだけだ」と理解して いる私にとっては、ループを使わずにプログラムを書くという ことが既に分かりません。 ● 競技プログラミングの問題をたまに解いたりする程度です が、最初は変数が書き換えられないということに大きな衝撃 を受けました。
  55. 55. 大体こんな感じ? ● インターネットがまだ無い時代に図書館で読み漁った本で、 まず、関数っていう物の意味が分からなかったんですよね。 ● 「実行順序の無いプログラム」というのがよく分かりません。 「SQLもループ処理の一部を書いているだけだ」と理解して いる私にとっては、ループを使わずにプログラムを書くという ことが既に分かりません。 ● 競技プログラミングの問題をたまに解いたりする程度です が、最初は変数が書き換えられないということに大きな衝撃 を受けました。
  56. 56. 多くのプログラミング学習者が理解に苦しむ問題を調査した所、以 下のような結果が得られた。 ●代入とシーケンス実行 ●再帰と繰り返し実行 ●並列実行 再帰やループはたしかに難しい。並列実行はとても難しいが、多く の挫折者はそこまで到達しない。しかし、代入とシーケンス実行とい う、プログラミングの最も基本的である概念の理解に苦しむとはどう いうことか。 (60%の人間はプログラミングの素質がない - 本の虫)
  57. 57. 再帰 関数 副作用
  58. 58. 関数
  59. 59. 関数型プログラミングにおける関 数とは「与えられた入力の値のみ から出力となる値をただ1つ決め る規則」という数学的な意味での 関数です(『実践関数プログラミング入 門』)
  60. 60. ちょっと まてや
  61. 61. プログラミングの用語として、関数のような 「(類似の)一連の処理をまとめた単位」をサ ブルーチン(subroutine)、もしくは手続き (procedure)とも呼ぶ.これらの概念の境界 は必ずしも明確ではないが、手続きは処理 だけを行い返り値を持たないもの、関数は返 り値があるもの、と区別される傾向がある。
  62. 62. 問題は 値を得ること
  63. 63. テストが素早く済めば,もっと頻繁にテストができる. Lispでは(他 のどのプログラミング言語でもそうだが),ソフトウェア開発はコード 書きとテストのサイクルから成る. しかしLispではサイクルがとても 短い: 関数1個毎,いや関数の部分毎でもいい. あらゆる部分を書 くにつれてテストすれば, エラーが起きたときにどこを見ればいい か分かるだろう: 最後に書いた部分だ.単純に聞こえるが,この原 則はボトムアップ・プログラミングを堅固なものにしている要因の 大 きな割合を占めている.それは更なる自信をもたらし,Lispプログラ マは(少なくともある一時) 古い「計画−実装」スタイルのソフトウェ ア開発からフリーになれるのだ.(『On Lisp』より)
  64. 64. 問題は、このような ボトムアップな コーディングに あまり慣れない
  65. 65. 部分を 寄せ合わせる という発想
  66. 66. 再帰
  67. 67. 再帰は数学から生まれた 有用な技法である。再帰 コードは一般に、反復コー ドよりも短くて書きやすい。
  68. 68. ちょっと まてや
  69. 69. whileにおける反復のポイント ● 変数を初期化 ● 条件を満たしているならwhile のブロックの最初に戻る ● 変数に新しい値を代入する
  70. 70. PythonにおけるWhile a = 0 while a < 100: a += 1 print(a)
  71. 71. あれ? ブロックを関数で まとめちゃえば いいんじゃないの?
  72. 72. 再帰からわかること ● 「ブロック」としてまとめること ができる、ということはその 「ブロック」自体を関数にする ことが可能である
  73. 73. Schemeにおける再帰 (define (ref-loop i j) (if (<= i j) (begin (print i) (ref-loop (+ i 1) j)))) (ref-loop 1 100)
  74. 74. ソフトウェア開発はコード書きと テストのサイクルから成る.しか しLispではサイクルがとても短 い: 関数1個毎,いや関数の部 分毎でもいい.
  75. 75. 一気にロジックを 書き上げよう とすると死ぬ
  76. 76. 部分を寄せ合わせるとき に 型チェックがあると便利 (テストのサイクルに 組み込まれる)
  77. 77. 注意
  78. 78. 再帰は強すぎる
  79. 79. だいたいの再帰を 利用したループは mapなどの高階関数で 表現することが可能
  80. 80. 結論
  81. 81. なぜ 関数型プログラミングを 「説明」することが 難しいのか
  82. 82. トップレベルで 書き下すことから ボトムアップで 繋ぎ合わせていくという 発想の転換が難しい
  83. 83. ブロックで処理を 数十行書くのではなく 細かく関数を切り分けて 作り上げて繋げる というのが難しい
  84. 84. 逆に代入による計算過程 と計算状態という考え方に 慣れすぎているために難 しい。
  85. 85. 泥団子のように 関数を小さく 始めてみよう

×