読者です 読者をやめる 読者になる 読者になる

「実用期を迎えた関数プログラミング」懇親会での会話忘却録

イベント

実用期を迎えた関数プログラミング : ATND

「実用期を迎えた関数プログラミング」というイベントが福岡で開催されたので参加してきたのですが、その懇親会で山本さんと小笠原さんとお話することができたので会話したことをメモしておきます。
かなりうろ覚えでの記述なので、間違っていたら指摘お願いします。

テストの話

  • Q. Haskell Day 2012の資料拝見したのですが、Haskellって実際どの程度テスト書かれているのか?
    • (名前失念)に登録されているもの23個のうち8個くらい
    • カバレッジは調べてないからわからないけど若干低めではあるかも?
    • 動的型付けでのテストの何割かはHaskellではいらない
      • 「hogehogeにタグが含まれていることのテストとか書いてあるけどHaskellだったら型で検査できるじゃん」
    • Haskell後方互換性のないライブラリが多い
      • 型チェックでエラーがでるのでどこを修正すればいいのかはわかる
      • テストは重い(表現失念)から書かれないのかも
  • 純粋な関数と副作用を含む関数を合成することでプログラムを組み立てる
    • 純粋な関数の性質はわかる(訓練すればわかるようになる)
    • 性質がわかっているならQuickCheckで性質書いてランダムテストできるよね
  • 副作用を含む関数は性質というよりシナリオ
    • シナリオにはランダム性は含まれない
    • こういうのはHSpecとかでテスト書こう
  • 型に関する間違いはなくても値に関する間違いはある可能性があるのでQuickCheckでチェック
  • (MVVMの)VMは独立にテストできる(だったかな?)
    • RxとFRP
      • データを差し替えることでイベント駆動型のテストもやりやすくなるのでは
  • exampleとpropertyを使い分ければいいと思うよ
    • 具体値でテストをどんどん書き、性質がわかった時点でpropertyに差し替える
    • 性質がわかっているものはpropertyでいきなり書く
  • QuickCHeckのようなものが浸透するかどうかは各言語コミュミティの雰囲気次第?
  • SmallCheckというのもある

先に書くか、後から書くか

  • Q. シグネチャを先に書く場合と後に書く場合とあると思いますが…
    • 基本は後から書くほうが多い
    • Type Driven Designする場合は先に書く
    • 型はモデル図
  • 割と複雑な関数は先に型を書いておく
    • 道をはずれかけたとき、型が間違いを教えてくれる
    • 型が実装を導いてくれる
  • 公開しない関数はシグネチャ書かずに型推論に任せる
  • OCamlシグネチャファイル分離しないといけないよね
  • シグネチャを先に書いたときはTDDしづらい
    • 駆動できていない感?
    • アルゴリズム系のテストも似たような感じがする
    • シグネチャを先に書いた場合はREPLを使いながら実装していくといいよ
      • REPLは履歴残らないが、でもその場で確認したのだから安心感は得られる
  • 関数型言語での開発はREPLよく使う
    • REPLでの実行結果を利用例としてdocに張り付けたりとかも

OCamlぽい話とか

  • フロントエンドとは切り離されていたりするバックエンド部分などはOcamlでいい場合も多い
    • そんな言うほど導入ハードル高いかなぁ(プロダクト的な意味で)
    • Ocamlは知名度の問題もあるかも
  • Q. チーム開発する際、どの程度の習熟度なら関数型言語を導入できると思う?
    • 値を示せるわけではないから難しい質問
    • 高階関数やOptionを使いこなせる必要はあるかも
    • でも実践だと、Optionだけではエラーでの情報量が足りないので、例えばOCamlの場合だとError型も必要になってくることも
  • Q. Windowsプラットフォーム対象のときにOCamlは?
    • OCaml標準で収まる範囲ならまぁありなのでは。テキスト処理とか。
  • oasisの話
  • Ocaml 4.0:replのcwoロードの依存関係の解消、GADTS
  • Js_of_OCaml
    • OCamljsは開発が止まっている(でもオブジェクトはこちらのほうがよかった)
  • TaPLの話とか
  • λ計算 → η-変換
  • Relaxed value restriction
  • OCamlerはみんな何かしら自作ライブラリをもっている
  • 他の言語を使っているときに(言語によっては使えない場合)Continuous Monadが使いたくて心が痛むときがある
  • Lazy.t.list
  • F#のType Provider
  • Haskell,OCaml,Scala,F#…独自の進化を始めている機能もある。だけど根底にあるものは似ているので、1つの言語を使えるようになれば、後は慣れの問題(文法学んで3日ほど書き続ければ慣れる)。

本編の感想は後日改めて書きますが、懇親会で聞いたお話もかなり勉強になりました。ありがとうございました。