関数型プログラミング言語Haskell Part30 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/01/15(日) 23:43:54.28

関数型プログラミング言語 Haskell について語るスレです。

haskell.org (公式サイト)
http://www.haskell.org/

前スレ
関数型プログラミング言語Haskell Part28
http://echo.2ch.net/test/read.cgi/tech/1428597032/

**デフォルトの名無しさん** · 2017/04/29(土) 15:22:04.96

デザパタみたいなの？
パターンって程実践で使われてないだろ。

んー。。。
使ってた感触だと、割と行き当たりばったりからの仕様変更でも何とかなるのが関数型言語の強み？と思わなくも無い。
ちょっとの変更にも関数経由するから、自然と既存の関数使い回せないか考えるし、関数型言語もそう言う風に進化して行ってるように感じる。

某スレで話題になったキャットドアクラスも、変な縛りがなければ究極的には機能の組み合わせでドアが開くかどうかの問題なのだから、タプルにBoolを並べれば良い。
ただ、同じBool値ばかりだと違う機能を付いてる(付いてない)と表現しやすいので、適当な型を作ってコンパイラが順番間違えたらエラー出すようにする。
cd = (False,型Aの値)
値が欲しかったら
getA t = snd t
または引数の時点で直接欲しい値にアクセス。
getA (_,x) = x
仕様の拡張に関してはタプルを入れ子にする事とする。
継承というよりは委譲に近い。
理屈では(以前の機能,拡張機能)の形でいくらでも入れ子に出来る。

cdEx = (cd,型Cの値,型Dの値)
cdFX = (cdEx,型Eの値)

基本機能だけなら基本のタプル取り出して使う。
getA $ fst cdEx
拡張機能だけまたは、拡張機能と基本機能の組み合わせは引数の時点で(以下略)
getC (_,x,_) = x
getAD ((_,x),_,y) = x + y

ただ、関数型言語は元々多くの状態を管理するのに向かない。
例の通り、構造が複雑になると扱い難い。
HTMLなりXMLなりXAMLなりに状態管理は任せた方がいい。
んじゃ、おいら夜勤明けなんで寝るわ。
お休みzzz...

**デフォルトの名無しさん** · 2017/04/29(土) 15:49:01.36

科学計算が日常じゃないってマジ？

**デフォルトの名無しさん** · 2017/04/29(土) 16:12:38.77

しかし多くの状態を楽に管理できなきゃ、
ゲームも商支援系ソフトもクリエイター系ソフトも何もまともに作れん
作れたとしても、後のメンテが辛くなるコードが出来上がる

向いているのは自身で状態を維持変化しなくてもいいような、
フィルターとしてモデリングできるものしかなくなる

たとえば linux の簡単なコマンドや web アプリ、FX自動取引システムくらいか

処理速度の問題は実用的にはほとんど気にならないレベルだと思うし、
メモリリークの問題はそれがHaskellだから諦めて、せいぜい気をつけろと言える

が、状態管理のしにくさは、これが解決すれば
爆発的にユーザーが増えそうなだけに、何か発明がほしいな

**デフォルトの名無しさん** · 2017/04/29(土) 20:54:16.08

抽象的な状態遷移はできるでしょ
ただ具体的な現実の状態を忠実に再現しろと言われるとよくわからない
忠実さを競う意味がわからない

**デフォルトの名無しさん** · 2017/04/29(土) 22:50:14.03

おはー。
そこよな。
IORefとかで状態管理出来るけど、それだとデフォルト引数とかある普通の言語の方が楽。
どっちかと言えばWebプログラミングみたいにHTMLやDBに状態持ってもらって、ここの項目をこう加工したいって時だけHaskell的なのが良いと思う。
奇しくもMVCとかMVVMのモデル。

キャットドア問題みたいなのは問題自体の使いどころが判らん。
おいらは問題を解決したいのであってクラスを作りたいんじゃ無い。

オブジェクト指向でなぜ作るのかって本のジャンケンを一対一から多人数に拡張みたいなのが問題として本質を突いてると思う。
本当の仕様変更って、一旦根本から考え直さないといけない事があって、解決したいのはそこだからね。

オブジェクト指向だと、結局一旦全部壊してクラスで表現して解決。
関数型言語だと一旦バラしてリストとか加えて使い回せるのは使い回す。

**デフォルトの名無しさん** · 2017/04/30(日) 00:00:51.50

関数型を選択することで、あるレベル以上の密結合を完全に禁止できる？？

**デフォルトの名無しさん** · 2017/04/30(日) 00:09:16.78

>>346
禁止と言うのが、言語仕様としてコンパイラに弾かれるという意味なら、禁止にはできない。

そもそも、結合度と関数型とは何も関係ない。

**デフォルトの名無しさん** · 2017/04/30(日) 00:24:21.53

そんな大規模なの作った事ないけど、少なくともクラスみたいにデータと手続きが密接に関係してるものよりは使い回しが効くよ。
ただ、それは関数型言語だからって訳じゃないと思う。
Cがグローバル変数の問題解決して、ジェネリック(テンプレート)導入すればそれで済む。
Goが一番それに近いのかな？(でもジェネリック無いんだよな。。。)
関数型言語はグローバル変数が読み込み専用で、問題になり難いから解決し易かっただけ。

私は文法の美しさでHaskellに惚れてるだけで、Haskellが絶対の解では無いと思ってる。
手続き型にはデフォルト引数とか、メッセージ引数と言う、引数の数や順番を減らしたり入れ替えても問題無い仕組みがある。
それぞれのメリット/デメリットをうまく組み合わせれば良い。

**デフォルトの名無しさん** · 2017/05/01(月) 08:17:07.40

正の整数が1万個格納されたリストAの中に偶数が2個以上あるか調べたいです
手続き型だとcount=0みたいな変数を用意してループを回してcountが2になったらループを打ち切るという形になると思うのですが、
haskellだとどう書けばいいでしょうか？
filterしてから数を数えることも考えたのですがそれだと2つ見つかってからも処理が続くので少し非効率的な気がしてます
初歩的な質問で申し訳ありませんがご教授いただければ幸いです

**デフォルトの名無しさん** · 2017/05/01(月) 09:22:52.54

>>349
haskellは遅延評価だからtakeとfilterで無駄なループしない

length . take 2 $ filter even [1..]

**デフォルトの名無しさん** · 2017/05/01(月) 09:38:09.96

その手続き型でのカウンタ変数を蓄積引数にするだけ

solve = solve' 0
　where
　　solve' 2 _ = True
　　solve' _ [] = False
　　solve' n (x:xs) = solve' (if even x then (n+1) else n) xs

main = print $ solve [1,3..1000001]

**デフォルトの名無しさん** · 2017/05/01(月) 11:06:48.65

>>350
>>351
なるほど…ありがとうございます
どうしても手続き型の考え方に引っ張られてしまってダメですね
精進します

**デフォルトの名無しさん** · 2017/05/01(月) 11:18:51.46

遅延評価が必ずループを打ち切る保証はない
length (repeat ()) >= length [] --> ⊥
longer (repeat ()) [] --> True

longer [] _ = False
longer (_:a) (_:b) = longer a b
longer _ _ = True

**デフォルトの名無しさん** · 2017/05/01(月) 11:46:14.32

遅延評価だからtake 2で必ず評価止まるわ

**デフォルトの名無しさん** · 2017/05/01(月) 11:52:30.52

入力が無限でその中にevenがなけりゃtakeでも止まんないっしょ

**デフォルトの名無しさん** · 2017/05/01(月) 12:35:32.98

さすがにその指摘は意味ないと思うけど

**デフォルトの名無しさん** · 2017/05/01(月) 13:23:37.16

でも人間にとって無意味な手をコツコツ打って勝つ戦略って最近の人工知能がやりそうだ

**デフォルトの名無しさん** · 2017/05/01(月) 14:06:36.95

>>355
そんな例だと遅延評価関係なく解決不可能だろう

**デフォルトの名無しさん** · 2017/05/01(月) 15:43:00.00

むしろ止まらないのが正常な振る舞いだと思うの

**デフォルトの名無しさん** · 2017/05/01(月) 17:46:12.38

>>355
ちゃんと1万個って言ってるのに、どうして自分の都合の良いように前提条件変えちゃうの？
人の話聞こうよ！ゾイゾイ言ってないでさあ！

**デフォルトの名無しさん** · 2017/05/01(月) 23:03:54.91

１まんこ

**デフォルトの名無しさん** · 2017/05/02(火) 01:06:52.67

型でガッチガチに固めてコンパイルエラーで危険なコード通すの阻止してくる関数型言語の姿勢ってフールプルーフ？

**デフォルトの名無しさん** · 2017/05/02(火) 07:41:56.01

>>360
草ァ！

**デフォルトの名無しさん** · 2017/05/02(火) 10:12:37.54

>>360
ゾイ！！！！！！！！！

**デフォルトの名無しさん** · 2017/05/03(水) 16:56:36.78

ハスケルの発音はどこにイントネーションを置けばいいですか？

**デフォルトの名無しさん** · 2017/05/03(水) 17:08:16.15

はぁすくぅ

**デフォルトの名無しさん** · 2017/05/03(水) 17:25:56.12

ハースニールと呼んであげて

**デフォルトの名無しさん** · 2017/05/03(水) 17:34:41.80

>>366
「haskell pronounce」でググれば簡単に
https://wiki.haskell.org/Pronunciation
に行き着く。

そうすれば、
https://mail.haskell.org/pipermail/haskell-cafe/2008-January/038756.html
に案内され、疑問が解消されるはずだ。

**デフォルトの名無しさん** · 2017/05/03(水) 19:23:38.05

はあすこぅ

**デフォルトの名無しさん** · 2017/05/03(水) 23:04:12.27

Cabal ケバール

**デフォルトの名無しさん** · 2017/05/03(水) 23:21:41.48

ghcよりcabalより先にstackを入れる。

**デフォルトの名無しさん** · 2017/05/04(木) 00:29:46.99

YouTubeをhaskellで検索かけりゃいくらでも聞けるだろ

**デフォルトの名無しさん** · 2017/05/04(木) 03:31:51.49

haskellでキーボードから入力した値をそのまま出力する場合、必ず
n <- getLine
putStrLn n
のように一旦変数に束縛する必要がありますか？
一行では書けないのでしょうか

**デフォルトの名無しさん** · 2017/05/04(木) 03:52:33.18

main = getLine >>= putStrLn

**デフォルトの名無しさん** · 2017/05/04(木) 03:55:26.58

>>374
ありがとうございます

**デフォルトの名無しさん** · 2017/05/04(木) 04:12:42.09

ちなみに

main = do
____n <- getLine
____puStrLn n

と

main = getLine >>= \n -> putStrLn n

と

main = getLine >>= putStrLn

は、等価。
do形式はモナド形式を手続き型っぽく見せる糖衣構文に過ぎない。
最後のはモナド形式とカリー化を利用した部分的用で見た目の変数を無くしただけ。
モナド形式だとプログラム全体が一つの式だと言うのが良く分かる。

**デフォルトの名無しさん** · 2017/05/04(木) 05:28:10.40

___n は誤解を招く

_korehaTsukaimasen

**デフォルトの名無しさん** · 2017/05/04(木) 06:57:02.33

getLine >>= putStrLn じゃなくて interact はダメなん？

**デフォルトの名無しさん** · 2017/05/04(木) 12:19:44.49

そもそも、getLineは1行しか読まないしな

**デフォルトの名無しさん** · 2017/05/04(木) 14:29:46.30

>>378
interactは変数に束縛してごにょごにょする処理を隠蔽してるだけだから
「必ず一旦変数に束縛する必要がありますか？」の答えとしては若干嘘かも

**デフォルトの名無しさん** · 2017/05/04(木) 16:34:00.03

束縛ってコード（人間の視認性）レベルの話で、コンパイラが吐くバイナリではキャンセルされてるんじゃないの？
バインドで（ポイントフリーみたいに）やったのと変わらないようになってんじゃないの

**デフォルトの名無しさん** · 2017/05/05(金) 21:55:20.21

Haskell 教養としての関数型プログラミング単行本 ? 2017/4/15
重城良国 (著)
https://www.amazon.co.jp/dp/4798048062/

824ページって超大作だな
Haskell本の決定版か？

**デフォルトの名無しさん** · 2017/05/05(金) 21:56:45.82

Haskellによる関数プログラミングの思考法単行本 ? 2017/2/28
Richard Bird (著), 山下伸夫 (翻訳)

https://www.amazon.co.jp/dp/4048930532/

こっちはどうなのだろう？
感想求む

**デフォルトの名無しさん** · 2017/05/05(金) 23:25:45.93

>>383
>>201

数独ができるようになるけど、ワイはすごい本の方が好きや

**デフォルトの名無しさん** · 2017/05/05(金) 23:34:27.84

すごい本やない。
すごい「H」本や。

**デフォルトの名無しさん** · 2017/05/05(金) 23:53:12.22

初めてのCっぽくて好き

**デフォルトの名無しさん** · 2017/05/06(土) 00:17:40.31

getLineでコンソールから手動入力する時、バックスペースとかで修正出来ないのってhaskeline使う以外に何か方法無いのかな？

**デフォルトの名無しさん** · 2017/05/06(土) 00:28:11.74

rlwrapとか？

**デフォルトの名無しさん** · 2017/05/06(土) 02:13:17.67

うーん、そういうのじゃないな

**デフォルトの名無しさん** · 2017/05/06(土) 18:51:05.79

Comonadでオブジェクト指向を実現できるって聞いたけどほんと？

**デフォルトの名無しさん** · 2017/05/06(土) 23:14:55.28

スレ違いかもしれませんが、２つのリストに一致する項目だけ抜き出したリストを作るみたいな問題があったとき、
集合論だと集合Aと集合Bの積集合A∩Bを求めるような解き方をすると思うのですが、Haskellのようにラムダ計算が
基になっている関数型言語だとそもそもの考え方や物の見方が違ったりするのでしょうか？

Haskellを学び始めたはいいんですが、結局他言語のパラダイムを無理やりHaskellに適用させているだけのような気がして不安です

**デフォルトの名無しさん** · 2017/05/07(日) 01:09:26.23

>>391
質問に答えるだけの知識を持ち合わせていないので一応コードだけ

intersect :: Eq a => [a] -> [a] -> [a]
intersect xs = filter (`elem` xs)

リスト内包表現でも書けるけど関数型っぽいのはこういう書き方なのかも

**デフォルトの名無しさん** · 2017/05/07(日) 01:46:15.37

>>391
チューリング完全という意味で、他言語とHaskellは等価というのが数学的な見方だな
もし言語が複数存在する原因を知りたいなら、数学的な見方はほとんど役に立たないな

**デフォルトの名無しさん** · 2017/05/07(日) 02:07:21.95

>>392
>>393
ありがとうございます
チューリング完全でさえあればそれ以上は計算モデルより言語仕様に合わせた方が良さそうですね
いろいろ試してみて、一番スマートに書けるように精進します
今のところHaskellが一番面白いです

**デフォルトの名無しさん** · 2017/05/07(日) 13:16:11.57

>>392
ちなみに、mapやfilterとリスト内包表記は内部的にはここが違うとか、パフォーマンスが
違うとか、あるいはこういうときはこっちの方がいいとかはあるのでしょうか？

**デフォルトの名無しさん** · 2017/05/07(日) 16:32:45.84

リスト内包表記はconcatMapを使うからネストできる
[f x y | x <- xs, y <- ys, p x y]
== concatMap (\x -> concatMap (\y -> if p x y then [f x y] else []) ys) xs
パフォーマンスは実際にghcがどういうコードを吐くかだけど
そのままconcatMapでもmapやfilterと同じような最適化が行われるし
必要なければリストの結合も行われない

**デフォルトの名無しさん** · 2017/05/07(日) 16:37:16.65

リスト内包のほうがパフォーマンスでるらしいけどHaskellのパフォーマンスチューンングは難しいから当分気にしないほうがいい
待ってる間に線形型で楽々チューニングできるようになるかもしれないし

**デフォルトの名無しさん** · 2017/05/07(日) 16:58:43.74

>>396
>>397
ありがとうございます
ネストの有無などで自分なりに考えながら使ってみます

**デフォルトの名無しさん** · 2017/05/07(日) 17:18:00.54

内包表記と再帰を組み合わせることも可能。
夢が広がりング。

**デフォルトの名無しさん** · 2017/05/07(日) 22:35:33.72

Web系でもいいのですが、フリーウェア（できればオープンソース）のアプリケーションで、
Haskellで作られたものって何かありますか？
Haskellプログラマだけでなく、一般の人も使っているもので。

もしくは、みなさんならHaskellでどんなアプリケーションを作ってみたいですか？

**デフォルトの名無しさん** · 2017/05/07(日) 22:48:03.22

Pandocあたりは比較的広く使われている印象

**デフォルトの名無しさん** · 2017/05/07(日) 23:26:23.39

あとはShellCheckだな。bash初心者はとにかくこれ使えって話題のシェルスクリプト更正ツールだ。

**デフォルトの名無しさん** · 2017/05/08(月) 00:31:05.17

オーケーグーグル
Haskellで日本語文字列（Shift-JISやEUC-JP）のファイルを正しく処理する方法

**デフォルトの名無しさん** · 2017/05/08(月) 17:26:21.06

みんな夢がないね。
ぼくなんてHaskellプログラム一つでお城のような家が建てれたよ。

**デフォルトの名無しさん** · 2017/05/08(月) 22:42:37.72

>>400です。
ありがとうございます。

Haskellで作られたアプリケーションの方は2、3個紹介されるかなと思ってましたので、
まぁ予想通りです。

ですが、作りたいアプリケーションのレスが1日経っても皆無なのは驚きました。
(>>403 がいまいち分からない。これは私へのレスですか？)

私は年賀状の宛名をデザインするWebアプリを作りたいと思い、
「Beginning Haskell」を読んでWebアプリの勉強中です。

皆さん、作りたいものは何もないんですか？
ゲームとかオーサリング系とか、マストドンをhackするツール(crackではなく)とか...

**デフォルトの名無しさん** · 2017/05/08(月) 22:56:09.94

GitHubとかでHaskellで検索かけりゃ何か出てくるんじゃねーの？

**デフォルトの名無しさん** · 2017/05/08(月) 23:03:23.31

論理に基づく人工知能を作るならHaskellがぴったりじゃないかと思うんだけど、プログラミングの技能も論理学の知識もないから作れない

細々と勉強はしてるけど

**デフォルトの名無しさん** · 2017/05/08(月) 23:31:16.69

自動イタ電器とか作れや

**デフォルトの名無しさん** · 2017/05/08(月) 23:32:41.17

達人プログラマーになりたい欲求はあるけど何かを作りたいっていう欲求は薄いわ

**デフォルトの名無しさん** · 2017/05/08(月) 23:43:37.38

やはりゲームだな。あとはGUIアプリ。なにかのエディタのようなものがいいな。
Haskellで複雑な状態を扱うのは困難、と言ってる人らに反論したい。
実際のところはどうなのか想像する前に、まずはそういう状況に直面する必要がある。

**デフォルトの名無しさん** · 2017/05/08(月) 23:49:55.75

EmacsのプラグインもHaskellで書きたい。正格データと遅延データを色分けして表示できたら嬉しそうだ。
GHC API を使えばできるかもしれない。

なんにしてもHaskellでやりたい。俺はもうLispは嫌だ…

**デフォルトの名無しさん** · 2017/05/08(月) 23:59:34.03

>>409
どういうことですか？
私が知っている達人プログラマ、要するにハッカーですが、
彼らはみな何かを作ってました(ます)。
なので、作ることに関心が無い達人プログラマというのが想像しにくいのですが。

あ、競技プログラミングのトッププレーヤーとかですか？

**デフォルトの名無しさん** · 2017/05/09(火) 00:07:55.03

>>411
Haskellでエディタ書いてくれ
common lispで書いたエディタもあることだし

**デフォルトの名無しさん** · 2017/05/09(火) 00:12:52.22

作る以外に改造とかに気合入れる人とかもいるんじゃね？

**デフォルトの名無しさん** · 2017/05/09(火) 00:50:22.97

>>413
今は外部言語でかけるしくみがあるから、エディタそのものを置き換えなくてもいいんだ。
それが現実的だと思う。Emacsのような巨大なものは厳しい。見上げるだけで首が疲れるよ。先人は偉大だね。

**デフォルトの名無しさん** · 2017/05/09(火) 10:12:37.98

>>400
写真が趣味だから、Jpegのカラー画像をモノクロやセピアに変換するツール作りたくてHackage漁ったら使い易そうなのがCライブラリ使ってるんで、そう言うの入れやすいLinux導入。
暇があったらチマチマ作りたいけど、暇がない。。。

**デフォルトの名無しさん** · 2017/05/09(火) 11:12:04.61

itchynyﾀｿがcamを作った時、一部の画像ファイルが(ライブラリのせいで)読めないのに腹を立てて
だったらhaskellで書いてやると一念発起したのがcamh。いまでも活躍してます。
lesspipeに組み込むとか。ちなこれはimlib2を使ってるので大抵の画像は読める。

**デフォルトの名無しさん** · 2017/05/09(火) 22:12:03.59

haskellを業務でつかうような仕事に転職すればＯＫ

**デフォルトの名無しさん** · 2017/05/09(火) 22:21:49.15

仕事では使わんが、概念というかエッセンスはめっちゃ役に立ってるな
興味本位で触っといて良かったとマジ思う

**デフォルトの名無しさん** · 2017/05/09(火) 22:47:25.87

>>419
その手の話ここで時々聞くけど、Haskellの何が何にどう役だったのか、
具体的な話を聞いたことが一度もない。
$$$な状況でHaskell未経験のヤツは***だったけど、経験者の俺は###できた、とか。

そういう事を具体的に語ったブログとか無いんかな？
英語でも構わないんだけど。

**デフォルトの名無しさん** · 2017/05/09(火) 23:13:21.51

比較するなら同一のものに対して、Haskell でのアプローチと
その他のアプローチをする必要があるので、
そんな贅沢な時間の使い方するやつはユーザ数が多くないと現れないんじゃないかな？

**デフォルトの名無しさん** · 2017/05/09(火) 23:21:27.66

tanakhにhaskellやっててよかった話を要求するか

**デフォルトの名無しさん** · 2017/05/09(火) 23:24:21.68

C++やC99以降みたいな「どこでも変数宣言」を嫌うようになった
宣言した位置と使う位置が離れるのは書き方が悪いからだ、というかなんか

**デフォルトの名無しさん** · 2017/05/10(水) 00:12:52.35

高階関数を多用する様になったとか、関数の純粋さを気にして関数分割する様になったとか
設計やコードが以前より分かりやすくなってテストもしやすくなったと思う
カリー化や部分適用がもっと簡単に出来たらってモヤモヤする事も多いけど

**デフォルトの名無しさん** · 2017/05/10(水) 02:17:13.25

別に関数型プログラミングって今まで出来なかったことが出来るようになる手法じゃないしな
コードを直感的に書けるようにすることでプログラムの全体的な質を高める手助けをしてくれるような感じ
メリットを語れと言われたら一晩中でも絡めちゃ語れる

**デフォルトの名無しさん** · 2017/05/10(水) 07:52:30.59

関数型とは月極、定礎に匹敵する巨大グループだがそれが存在する証拠はない
統計学的には母集団が実在する証拠を出す義務はない

**デフォルトの名無しさん** · 2017/05/10(水) 18:59:47.60

私は、Windowsで大きなランタイムとか必要なく
実行形式のバイナリを作れるのが助かってる。
小さいバッチプログラムとか。

**デフォルトの名無しさん** · 2017/05/11(木) 05:52:26.63

ghcmod-vimってstack環境で動かないのな

**デフォルトの名無しさん** · 2017/05/12(金) 14:16:42.66

haskelは使わないけど関数型の勉強はすごいためになる
ライブラリが提供する地雷メソッド見抜けるようになった

**デフォルトの名無しさん** · 2017/05/12(金) 20:57:00.05

意識的にオブジェクトをモノイドにしたりするようになった

**デフォルトの名無しさん** · 2017/05/12(金) 21:47:41.07

皆の言う関数型の経験が生きた事をアドバイスしてるオブジェクト指向の本が出ないのは何故か

**デフォルトの名無しさん** · 2017/05/12(金) 22:37:15.98

本を書くのが楽な作業だとでも思ってるの？

**デフォルトの名無しさん** · 2017/05/12(金) 22:41:48.24

その内容で一冊書きたいならそれをテーマにした小説にしてページを埋めないとだな
いいものはみんな本になるはずという前提がそもそも間違ってる

**デフォルトの名無しさん** · 2017/05/12(金) 22:48:49.78

>>432
楽かどうかの話じゃなくて、皆の言ってる事はここ数年の関数型の特長じゃないじゃん
ずいぶん昔から変わらない関数型の特長でしょ

関数型のいいところを手続き型(オブジェクト指向)にも取り入れようとし出したのもかなり昔の話だし

なのに、ここ数日このスレで挙げられた事が本になっていないのが不思議なんだよ
和書はともかく洋書でも無いじゃん

**デフォルトの名無しさん** · 2017/05/13(土) 00:09:37.73

ハスケル環境整えやすいのって

**デフォルトの名無しさん** · 2017/05/13(土) 00:10:00.54

Windows debian?

**デフォルトの名無しさん** · 2017/05/13(土) 00:14:42.17

>>431
うーん。。。
関数型言語じゃなくても気を付ければ出来るし、それがデザパタとかMVC/MVVMになってるからじゃないかな。
だから関数型言語はエッセンスを触接理解するのに使って、実用は普通の言語。
特にHaskellはIOと純粋関数が分かれてるからコマンドアプリでさえファイル=M、コマンドアプリ=VM、コンソール(ターミナル)や出力するGUI部品=Vって非常に明確。
使ってて、ああ、MVVMってこう言うことかって思った。
何つーか、MVCよりもMVVMはもっとCを広く解釈してるからVMなんだなぁとか。

**デフォルトの名無しさん** · 2017/05/13(土) 00:22:55.11

Ｃ＋＋でわからんでJAVAで半分誤解して
ruby使ったときにオブジェクト指向理解したのとよく似てるな

**デフォルトの名無しさん** · 2017/05/13(土) 00:27:18.79

経験上思ったのはオブジェクト指向は先手先手で先を読んだ設計が重要。
(だからオブジェクト指向設計とかがプログラミング以外にも必要)

関数型言語はわりと行き当たりばったりでもどうにかなるし、それはオブジェクト指向じゃない普通の言語(CとかPascal)でも活かせる。

だから、メソッドチェーン使った宣言的なオブジェクト指向よりも泥臭い手続き的なプログラミングに新たな視点(設計の幅)を与えてくれる感じ。
(要するにメソッドの中身を書くときに役立つ)

**デフォルトの名無しさん** · 2017/05/13(土) 00:33:36.39

OOPはプロパティの値を書き換えてなんぼ、インスタンスの振る舞いをメソッド内で完結させて
なんぼだからまぁそりゃメソッド内くらいにしか関数型のパラダイムは取り入れられないよね

**デフォルトの名無しさん** · 2017/05/13(土) 00:50:28.11

>>439
プログラム組む前に紙と鉛筆でじっくり図書いたことないかえ？
ライブラリ使うだけの時も恐怖でそうしてた。