[過去ﾛｸﾞ] スレ立てるまでもない質問はここで 152匹目 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
852(3): 2020/03/26(木)17:05 ID:e0+FyfEU(2/3) AAS
モナドについて調べてたんだけど
Maybeモナドでnullチェック無くせるらしいけど
try catchをちゃんと使えばnullチェック要らんでしょ。
というかMaybeモナドでもNothing返すわけだけど
Nothingを受け取ったところはどうするのっていう
「もしNothingだったらこの処理」みたいな条件分岐がどこかに入るんじゃないの？
なんか関数型はo.method1().method2().method3()みたいに
パイプラインっぽく書くことに拘ってる気がするんだけど
そのメリットはなんなの？
854: 2020/03/26(木)22:41 ID:5np4UAxw(1/2) AAS
>>852
>パイプラインっぽく書くことに拘ってる気がするんだけど
>そのメリットはなんなの？
関数の合成
プログラムの基本は入力 -> 処理 -> 出力
この処理が一つの関数だけど
それを複数の関数に分解して合成することでプログラムを作ってるよね？
関数の合成可能性(composability)が高ければ
再利用しやすい、パターン化しやすい、一つの関数をシンプルにしやすい、テストやメンテがしやすい等のメリットがある
855: 2020/03/26(木)22:52 ID:5np4UAxw(2/2) AAS
>>852
比較的馴染みのある言語で
関数型の考え方を取り入れてる機能を調べてみると
何がうれしいのか分かりやすいんじゃないかと思う
SwiftのOptional型とOptional Chaining
KotlinのNullable型とSafe Calls
C#のNullable型とNull Conditional Operator
など
856(1): 2020/03/27(金)05:25 ID:QZ/xTJoy(1/2) AAS
>>852
パイプラインや関数型言語の明確なメリットとして並列化のしやすさがある
ムーアの法則が崩れた今マルチコアCPUを活用せざるを得ないからな
古典的なforを書けばその順に逐次処理をするという意味にしかならない一方
関数でマッピングやフィルタリングを書いた場合は集合から集合への変換が欲しいという書き方になり
もし順序を問わない変換なら簡単に逐次処理から並列処理にできる
手続き指向からより目的指向の書き方になるとも言える
でも分岐やエラー処理だけは古典的な書き方が必要なんですとなるとそこで並列化の可能性が途切れるので一貫する必要がある
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.027s