「モナド」を含む日記 RSS

はてなキーワード: モナドとは

2019-09-12

[] Haskell学習カリキュラム

  1. Haskell文法を学ぶ。
  2. 圏論を学ぶ。
  3. 圏論知識を基にして、再びHaskellを見直す。

Haskell文法書だけを読む

圏論Haskell対応関係

対象
関数

となっていることを、最初は知らなくてもOK

単にHaskell文法を学ぶだけで、背後にある考え方(圏論)は、まだ知らなくてもOK

圏論の基礎

圏論は元々数学で考案された考え方なので、直接的には代数やとトポロジー知識必要になるが、そこまでのレベルは求めていない。

とりあえず、プログラミングで使える程度の初歩的なレベル理解で十分。

圏論の具体的な応用例としてHaskellを見直す。

圏論知識を基にして、Haskell文法や仕組みを見直してみる。

注釈対象定義して、関数は射を定義していることが分かる。

ファンクター、アプリティブ、モナドで、手続き型の順次・反復・分岐表現できることが分かる。

2019-06-21

Javaをメインで書いているわけではないけど

別にJava良くないか

なんならRubyより静的言語だという点で優れているような。

最近Go流行っているが、それならJavaだって同様に良さそうな気がする。

Java批判すべき点ってなんなんだろう。

- 記述冗長

- nullがたまにうざい

- なんか重厚な感じがする

- 重厚アーキテクチャ流行りすぎた?

- ORMとかが重厚なのが多かった

- ビルドツールが洗練されていない時代があった

- 故に環境構築が大変だった

- tomcat + jar みたいなのがだるかった?

- strutsがしんどかった

- 未だにstruts脆弱性が見つかったりするところ

- xml地獄からアノテーション化したりいろいろと模索していた

- なんかJava案件地雷が多かったとか?

- ちょっと昔には「俺たちイケてるプログラマ」はみんなRailsに移っていった流れがあった?

- Effective Javaよいが、そもそもそういうtips意識せずにそう書けるような言語仕様になってほしかった気もする

- 非同期処理やスレッド処理がやや難しかたか、あるいは言語側でのサポートが薄かったか(?)

言語仕様的な批判と、エコシステム的な批判に分けられそうなきがするな。

関数型言語の関心はScalaClojureに全フリしてもらって、Javaシンプル機能を持つGo方向性なModan Javaになっていってくれれば良さそうな気も。

httpサーブレットとかそのへんが微妙だったかもしかしてGoみたいにnet/httpライブラリが標準であればそれをベースにすることでオレオレフレームワークの乱立を避けることができるか、と思ったけどJAX-RSとかがあるな。

Goだって冗長記述必要言語だが、好かれているし、Javaも悪くない言語な気がするんだよな。

まあ何でもいいが。

ロジカルに考えているようで結局なところ雰囲気的なところに左右されているエンジニア多い気がする。

まあわいも、人気な言語に乗っておいて高単価を得られたほうがいいのでそうするが。今の所Goが肌にあっているんだよな・・。3年ぐらい使って熟練度上がってきたし、さほど悩まずにコーディングすることができる。

PHPの人が好きな、あるいはRubyのmethod_missingなど活かしたテクコードは、書いているやつは気持ちいかもしれないがわいは明示的にinterfaceがわかるコードが書かれていたほうが好きだ。型で振る舞いがわかったり制御されていないと分かりづらくない?複数プロジェクトを掛け持ちするから、読むときに前提知識が少なく読めるコードがいい。

まあJavaもリフレクションでテクいことができる気がするな。

Goがいい。誰が書いてもだいたい同じコードになるから、誰かに作業を振ったとしてもレビューやすい。

まあこれからJavaを書く気はしないが、GoAPI書いているマンから見ると、JAX-RSとかでゴリゴリAPI書いていくの全然悪くないんじゃないかと思うのであった。

最悪別にGeneric入らなくてもいいかもな。別にそんなに困ってない。はいってくれるなら、はいってくれたほうがいいが。sliceに対してmap, each, filter, existsなどのメソッドが生えることになるイメージかな。まあそれは欲しくなるけどな・・・

Scalaもいいんだが、たまにイキったコードを書くと分かりづらくなる時がある。イケてるコードを書こうと思ったとき結構パワーを使う言語だ。なんかモナドってジェネリックを更に強くしたやつだとも捉えられるような気がするな。ゴリゴリ関数型で書こうと思った場合プロジェクト全体に影響がある話なのでアーキテクチャ設計に力がいる気がする。

年をとると大事にするポイントが変わってくるな。昔はスーパープログラマになりたくて関数型言語とかやっていたが、今はいかに効率よく仕事をする=金を稼ぎ自由を得るかを重視している。職業プログラマとなったわけだ。仕様固めたりリリースしたり不具合対応したり運用したり、フリーランスなら税金計算したり、金儲けの方法考えたり忙しいんじゃ。今は結局スーパープログラマとは何か悩ましいよ。「プログラマとして」キチガイレベルにすごい人間というのはまだ見たことがないかもしれない。コーディングが早い?バグ修正が早い?パフォーマンスやばいコードを書ける?設計が優れている?

わいのレベルが低くて、高い人間凄さに気づけていないのかもしれないな。

2019-05-28

適当発言

最近特定技術への拘りがなくなってきた。

最近レバレッジが効く言語フレームワークを好きになるようになってきた。

もう言語何でもいいわ。やっぱ静的言語がいいのと十分に熟練度がついてきたのでAPI開発ではGolang使って開発するのは良い。PHP(Laravel)、Ruby(Rails)はやはり生産性が高いので良い。ScalaMonad Transformerを使ってモナドスタック解決していく程度あれでやっていき、あまり悩まないような構成になっていればサクサクやっていけそう。

実はJavaが一番いいんじゃないか…。Springガッツリやったこと無いけど、トランザクションとかもいい感じに効いてくれそうだし、そこそこ生産性高そうだし。

知らんけど。

なんでもいいや。

2019-05-07

anond:20190507133050

アルゴリズムとかポインタとかモナドとか、「わかりづらい」と言われる要素を理解することに、快感を覚えたりはしないか

2019-03-02

anond:20190302153004

あなたが扱ってるそれ、実はモナドだよ」……みたいな。

2019-01-20

世の中しらんことが多いなと感じる

sin(x)の導関数cos(x)であることを証明できる日本人は何人いるであろうか。30%いるだろうか。

その中で、サティジムノペディと聞いてピンとくる人は何人いるであろうか。

その中で、確定申告のやり方を人に教えられる人は何人いるだろうか。

その中で、冷蔵庫ロードラインという言葉を正しく説明できる人は何人いるだろうか。

その中で、タイ語アルファベットを読める人は何人いるだろうか。

その中で、LD50説明できる人は何人いるだろうか。

その中で、エディプスコンプレックスという言葉が初耳でない人は何人いるだろうか。

その中で、ミクロ経済学での無差別曲線説明できる人は何人いるだろうか。

その中で、膠着語孤立語の違いについて説明できる人は何人いるだろうか。

その中で、圏論モナドを正しく理解している人は何人いるだろうか。

その中で、今月アフリカのどこでどのような経緯でテロが起こったか解説できる人は何人いるだろうか。

その中で、行書と草書の違いを説明できる人は何人いるだろうか。

その中で、黒澤明映画を知っている人は何人いるだろうか。

その中で、悪魔の喉笛がどこにあるか知っている人は何人いるだろうか。

その中で、中国で言われている世界三大美女をすべて言える人は何人いるだろうか。

その中で、ブリネル硬さ有用性を語れる人は何人いるだろうか。

その中で、ロールケーキレシピを知っている人は何人いるだろうか。

その中で、中央選挙管理会はどのように組織され何をしているのかわかる人は何人いるだろうか。

その中で、脳神経の12対を知っている人は何人いるだろうか。

その中で、CIAOちゅ〜るが何か知っている人は何人いるだろうか。

その中で、特別送達がどうすればできるか知っている人は何人いるだろうか。

その中で、パレットとは何に使うものか知っている人は何人いるだろうか。

その中で、アーガイル柄とは何を指すか知っている人は何人いるだろうか。

その中で、外傷性刺青とは何か知っている人は何人いるだろうか。

その中で、廿日市市がどこにあるか知っている人は何人いるだろうか。

その中で、日本専売公社がどのような経緯で設立されたか知っている人は何人いるだろうか。

その中で、三心四修とは何か説明できる人は何人いるだろうか。

その中で、フォッコ英語名を言える人は何人いるだろうか。

ひとつひとつは知ればググることができる。しかひとつひとつは平易である。ただすべてを知っている人は多くない。

こうした言葉1つで知らない世界があったことを知れる。これらの知識雑学と似ているが、少し趣が違っていて、その言葉の裏に膨大な情報があることを知って圧倒されるというものだ。たとえばアーガイル柄をひとつとってもそうで、その言葉からは服飾の世界には膨大な情報があり、ミシンや染料があり繊維があり生地があり針がありファッションがありモデルがあり流通があり……そういうことについて何の疑問もなく「服を買っていた」ということに戦慄を覚えた。それで世の中頭のいい人が多いなとすごく感じている。自分の知らない言葉観念論理が世の中にあふれているというのはおそろしいことだ。

2018-10-21

普通プログラマ関数型プログラミング絶対理解できない

実を言うと、普通プログラマオブジェクト指向以前のプログラミング理解できないんだけど、あれらはまだ手続き的な要素を内在してるから、そっちだけを受け取ることはできる。

それまで手続き的な要素+宣言的な要素だったプログラミングが、関数型プログラミングへと移行する時に手続き的な要素を切り捨てたのね。より純粋手法進化するために。

から、それまで手続き部分だけを受け取って喜んでた普通プログラマは急にわからなくなりヒステリーを起こした。

だけど、プログラミング上級者はオブジェクト指向以前にも宣言的な部分しか見てないか普通プログラマが何を騒いでるのかわからない。

普通プログラマって、部品化の凄いやつが関数型プログラミングになるとか勘違いしがちだけど(staticおじさんもその変奏)、全く質の違うもの

部品化って、重複コードをひすたらサブルーチンに括り出すようなもの副作用がある。

日本SIer(日立NEC富士通とか)って教養がない極東田舎者から副作用理解できない。すぐに「部品化」を持ち上げる。怖いんだろう。自分理解できないプログラミングが。モナドですら大多数は理解できないんだものあん教科書的なものですら。

とにかくアジアってIT後進国なのね。トップ日本ですらこうなのだから。"NTT"データHaskellレガシーシステム脈絡なく解析してホルホルしてるレベルもの

まず日本に生まれた時点で、関数型プログラミング理解するには圧倒的に不利。こんなこと言うと、「普通プログラマにもわかやす説明できるのが一流ダー」みたいな恥ずかしい駄々っ子が沸いてくるけど、プログラミングって歴史上一度も大衆相手にしてないので。

昔は研究機関IBMで、今はMSGAFA

OSS恩恵で、普通プログラマコンパイラ無料で使えるようにになっただけで泣いて喜ぶべき。

そしてあれは、将来のスポンサーコミッタ入り口としてやってるの。1000人に1人、将来コミュニティに貢献する人材いるかもしれないと信じて。

シリコンバレー住人にもOSSコミッタにもなれない普通プログラマはまあ、おこぼれで"文化的"コスプレしてQiitaでもやればいいんだと思うよ。

anond:20181021093430

2018-08-12

https://anond.hatelabo.jp/20180810011214

落合陽一、最近全然ダメだね。

メディアアーティストとして落合陽一が出てきた時は、凄いのがきたと思った

アリス時間とかモナドジーあたり

やっと藤幡正樹に対抗できるファインアート教養と、テクノロジースキルを持ったメディアアーティストが現れたと思った

そこから三次元空中浮遊にいったのも、まあありかと思った

でも最近活動を見てると、広告代理店的なメディア戦略の悪いとこばかり目立つ

twitter発言も気が狂ってるような妄言ばかりになってきてるし、行動しろ手を動かせと言ってる割に、肝心のアウトプット猿まね

頭の空っぽ信者ばかりに囲まれて裸の王様状態

かに才能はあると思う。

日本を変えるとか誇大妄想を捨てて、専門外のことに口出すのもやめて、地に足ついた地道な努力を取り戻して欲しい。

2018-07-07

Haskell を書いてるわけではないんだけど Haskellメモ化したい関数ってどうするんだろう

OOP言語で書いてて

 

 

という条件なので、キャッシュを取って、キャッシュになければ計算して返すクラスを作った

純粋関数型でこれをやろうとするとモナドになったりして面倒臭そう

 

しかしながら

 

  1. メモ化は単なる最適化なので無限計算リソースがあれば不要。IOと違い、副作用自体を扱いたいわけではない。最適化の結果として副作用になるだけ。
  2. コンパイラに任せて低レイヤー隠蔽できるならその方がよい。上層レイヤー関数を書く人間が直接扱うようなものではない。
  3. メモ化できるのは参照透過性ゆえなのでむしろ関数純粋性が保証されてる Haskell とかの方が標準の言語機能として当然のごとく提供できるのでは。

 

と思ったのですがどうなんでしょう。

2018-02-16

モナドとかチョマドとかトマドとかもうわけわかんねえな

2017-11-08

モナド理解してるやつは説明がへたくそ

モナドさっぱりわからん

記事という記事を読み漁ってもモナドはわからなかったが、分かったことが一つある。

モナド理解してるやつは説明がへたくそ

どれも 用語 と 概念 と 数学 と 使い方 と 歴史 と 関数言語 を織り交ぜて同時に説明してきやがる。

モナドが分かった実感は0。

例えば住所圏でいうと→わからん

もっと詳しく具体的にHaskellScalaで書くと→わからんモナドが分からないのにHaskellScala を使いこなしてるわけが無い。

ここまでくればあとは簡単ですよね→わからん

大体モナドを知りたいやつは、理解とか概念はどうでもよくて、少しでもわかった実感がほしいだけなんだよ。へたくそ

2017-10-14

図書館でなに借りたら良いか

気になってる本はこれ

読む優先度高い本とおすすめの本教えて

ラウィーニア、風の十二方位、闇の左手

ファウンデーション地球

八月の砲声 上・下 第一次世界大戦の起原

引き潮のとき四巻 

戦争の変遷 

革命群衆  都市革命 

ハイ・ライズ、沈んだ世界夢幻会社

自由からの逃走

都市都市

月曜日土曜日に始まる、収容所惑星

紙の動物園もののあはれ

からの帰還、スタニスワフ・レム コレクション高い城・文学エッセイ

ラヴローフのナロードニキ主義歴史哲学 ロシア革命先駆者たち ナロードニキ/ 旭 季彦 

モナド領域宇宙衞生博覽會、東海道戦争、旅のラゴス

流れよわが涙、と警官は言った、宇宙の眼

鏡像の敵、Uの世界時間

マッキンダー地政学デモクラシー理想現実

2017-02-16

ノマド」は「ノーマッド」と書いて欲しい

スタバ仕事をすることもプログラミングすることもない身としては、「ノマド」も「モナド」も「はてなでたまに見るよく分からない概念」でしかなく、ごっちゃになってはググっての繰り返しだった。

しかノマドロマサガ2ノーマッドが同じ由来だと気付いた瞬間混乱は消え去った。

これは特殊パターンだとしても字面が似すぎているから改称した方がいいと思う。

2016-05-25

http://anond.hatelabo.jp/20160525213232

バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ?

第一に、それは、ストリームFRPの値の定義)の問題であって、ユニットテストすれば良い。もしくは単にFRPログを取れば良い。

グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリ特にそうだけど、基本的ミュータブルな値同士が関数リアクティブ連携されて常に整合性を保っているのだからグローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという(テスト自体困難な)問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。

使用する関数問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数問題と一緒というのはまったく違う。

岡部氏との争いって「OCamlGUIアプリ純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね?

いや、それがそもそもの発端であるブログの経緯には書かれている。説明されている方式GUIアプリまで書けるのか?と疑念が呈されたことがきっかけ。

岡部氏はFRP状態関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね?

この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。

あと、OCamlGUI状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね?

原理的に可能かという議論ではなく、実用的な範疇か?という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRP状態渡しは同じ複雑さだという主張も崩されている。そこが重要

Haskellで書けて、OCaml冗長になっても、書けるなら「書ける」、「可能」だよね?

段階を踏んだ上で、非FRPHaskellのIOモナドコードを誰かが書いたらいんじゃない?当面、最初OCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたか制限されたんでしょ。実際には、OCaml関数型では冗長しか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。

俺の書き込み他人といきなり結び付けられたから、電波だな、と思ったの。

俺1人か、とか、らくだや住井が含まれてない根拠とか、関係無いよね。

関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、

書き込みをみれば、君以外の書き込みもすべて、その一派ではない、とでも言いたそうだ。

http://anond.hatelabo.jp/20160524164501

関数型という枠組みの中にミュータブルな時間要素が純粋に収まるようにしているのがFRPだろ。

ストリーム関数の外部に持つFRP純粋関数型っていうのは少数派でしょ。

関数の結果が引数以外で決まるわけだからさ。

多分、純粋とかの定義もまた違うんだろうね。

関数型の拡張」で全部丸く収まると思うんだけど。

いやそもそも岡部氏が複雑なアプリになるとFRP必要

これはGUIアプリ(対話的なアプリ)ってことでいいのかな。

コンパイラだとかをFRPで書かないでしょ。

ユーザから入力リアルタイムに処理するプログラムにはFRP有効だよね。

事実、「駱駝」は「状態渡しはむしろ異常」って書いた上に、

OCamlでは」じゃないの?

全部純粋関数型(引数戻り値に収める、状態渡し)にするのを良しとするHaskellと違って、OCaml副作用部分的に使うのが普通で、IOモナドみたいな入出力までも純粋に書くための道具立てが揃ってない、それでちょっと冗長になる、ってことでしょ?

OCamlの元々の推奨スタイルならもっと短く書けるんでしょ?

俺はそう読んだけど。

それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ?

だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの

いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。

いやだからグローバル変数使ってるプログラム欠点をそのまま持ってるじゃん

グローバル変数使ってるプログラム欠点説明する必要ある?

2016-05-24

http://anond.hatelabo.jp/20160524145224

よーわからんw 岡部氏は、自作ライブラリHPで、

FRP純粋理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせ

まり関数型の拡張っていうなら誰も反対無いと思うんだけど。

FRPライブラリサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか?

https://www.npmjs.com/package/timeengine

HaskellのIOモナドみたいな別の抽象化DISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの?

IOモナドDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからFRPの効力がまざまざと見せつけられている。

荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?

あるよ。

関数がどのパラメータ依存して、何を結果として返すのか明確になる。

グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。

短いプログラムならそれでもいいけどね。

別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数関数に渡すのか?

グローバルな値を参照したり書き換えたりして

いやだから、定数なんだから書き換わらないんだよ、FRPストリームconst 定数なんだから

関数型のわかりやす説明であって、住井派に反対してるとか、岡部路線とかじゃないよね、と。

オブジェクト指向と対比して考え方をまず学ぶって岡部路線、住井グループはそれを目の敵にしていて集団的攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。

http://anond.hatelabo.jp/20160524142313

FRP純粋理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせっていうなら、別に誰も反論しないと思うけど。

まり関数型の拡張っていうなら誰も反対無いと思うんだけど。

HaskellのIOモナドみたいな別の抽象化DISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの?

全部の時間依存関数にそういうことをする意味はない

あるよ。

関数がどのパラメータ依存して、何を結果として返すのか明確になる。

グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。

短いプログラムならそれでもいいけどね。

初心者からFRPのことまで考えてないんだろう。

関数型のわかりやす説明であって、住井派に反対してるとか、岡部路線とかじゃないよね、と。

2016-05-22

http://anond.hatelabo.jp/20160520083417

「滅多なことが言えなくなった」としたら、nonstarter氏のブログのように

岡部氏に反する意見を言うと激しく荒らされるからですね。

迷惑がかかるといけないのでリンクしませんが、

住井氏は関数型言語に関する世界最高峰の国際会議委員長ですね。

エリオット氏のブログは、岡部氏が引用していない部分を読むと、

C言語の「プリプロセッサが」Cプログラムを「生成する」ので、

HaskellのIOモナドがIOアクションを生成するのと同様に

純粋関数型言語とみなせる、という主旨のことが書かれていますね。

岡部氏は「プリプロセッサ」という部分を引用していないようですが。

2016-05-20

http://anond.hatelabo.jp/20160520153456

OCamlでは」普通に副作用を使うライブラリしかいかスケールしない、って書いてあるのに

なんで勝手一般化して、Haskellとかでもスケールしないことにしたいの? 本当に牽強付会オンパレードですね。

http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158

OCaml の全ての GUI ライブラリ状態副作用を使うことを前提にメインループ設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体自分で書く事になり、一般的にはスケールしません。HaskellGUI ライブラリでは普通状態State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリOCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用意味があるとは思えませんが。

http://anond.hatelabo.jp/20160520135548

一応説明すると、Elliottの元記事

HaskellのIOモナドが「IOアクションを生成する純粋関数プログラム」なのと同様、

Cのプリプロセッサは「Cプログラムを生成する純粋関数プログラム」って言ってるのね。

から「cpp + C言語処理系」は「Haskell + 処理系」と同じく純粋関数型だと:-)

http://anond.hatelabo.jp/20160520052648

http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158

いずれにせよ、状態機械数学構成では状態遷移が状態入力から状態への関数として表現されるというだけのことではあり(状態渡し)、

状態遷移が複雑になれば状態遷移を純粋関数として表現する作業も複雑になり困難になるので(そしてそれはしばしば綺麗な関数合成では上手くいかないようなものになることが多いので)

って自分で(状態渡し)は困難になる、「状態渡しはスケールしない」って認めちゃってるんだが、

モナドと一緒ってことにして、Haskellモナドの話にすり替えたいってことなのかな?

状態渡しはスケールしない」とこの人物が自分で認めてることは消えないよね?

http://anond.hatelabo.jp/20160518170332

これのどこをどう読んだら「状態渡しはスケールしない」になるんだ……

ひょっとして状態渡しをモナド化したのがStateとか、基本的なことを全く理解していない?

http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-d9a8cdf2efc67044c158

OCaml の全ての GUI ライブラリ状態副作用を使うことを前提にメインループ設計されているからです。これを乗り越えるとすると @Lambada さんのようにメインループ自体自分で書く事になり、一般的にはスケールしません。HaskellGUI ライブラリでは普通状態State なり IO を含む GUI モナドを使って書く事になりますが、そのような GUI ライブラリOCaml 上で作れば同じような事が出来るはずです。OCaml でそこまで純粋関数型のコードを書く事に実用意味があるとは思えませんが。」

2016-05-17

http://anond.hatelabo.jp/20160517022608

>それをユーザから見て命令変数への破壊的代入ではなく参照透明な関数インターフェースで実現するのがいわゆるモナドや(誰かの独自解釈ではない本来の)FRP

はい、戯れ言への反論がkenokabeよりBlogでされました。

http://kenokabe-techwriting.blogspot.jp/2016/05/frp.html

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん