  |
はてなキーワード: Haskellとは
たとえばC#など.NET系のリファレンスはMSDNで読むことができる。
RubyだってHaskellだってScalaだって、公式サイトにガイドぐらい置いてある。
Oracle、DB2、MySQL、PostgreSQL、SQLite、AccessなどSQLが実装されたDBMSは様々にあるが、どれを取っても仕様が違う。
皆が標準SQLに従っていてその上で適当に増設している程度ならよいが、もはや誰も標準SQLに従う気が無い。
根幹的に必要な機能があったりなかったりするから、あるDBMSで書けるようになったからと言ってSQLを覚えたとは言えない。
これと上記１とのせいで、何かググった時に特定のDBMSでしか解決法にならないものが大量に出てくる。
最近のプログラミング言語は大抵、雑に書いたってコンパイラが適当に最適化してくれる。
同じ結果を生むような二つのコードは、よほど下手くそに書かない限りは同じような実行速度になる。
SQLもオプティマイザが最適化はするが、ほぼ同じような二つのコードで速度が全く変わったりする。
そのため実行計画というオプティマイザの中間言語のようなものを読んであげて、
より速い中間言語が生成されるようSQLをチューニングし直さなければならない。
これでは何をやっているのかわからない。
有名なサイトでは、初心者が必死で書いたような可愛らしいSQLを「それでは遅すぎるんじゃ」とけちょんけちょんにけなし、
なんかシンプルなのだけれどよくわからない文法を一杯使って実行速度を高めたのを「正解」としていたりする。
しかもその文法、ググってもろくな解説が無かったり、特定のDBMSに依存してたりと使えないオチ。
上手い人はSQLを綺麗に書く。だけど、その綺麗さの基準が人によって違う。
エディタが単なるメモ帳でしかないようなDBMSも多いから、インデントの文字数さえ個々人に任される。
インデントは2文字か4文字か。SELECTで改行するかしないか。カンマは列の後ろか、前か。
いろいろなサイトに色々なことが書いてあったけれど、全部違うこと言ってた。
つまり各々綺麗に書ければいいやということであり、読むほうも宗教が違ってもまあ綺麗なら読めるから困りはしない。
何かの解決法をググるたびに違うスタイルだからどう書いていいのかわからない。
結局なんかいろいろな上手い人のスタイルをツギハギした新たなスタイルが世に誕生してしまうのだ。
Haskell を書いてるわけではないんだけど Haskell でメモ化したい関数ってどうするんだろう
という条件なので、キャッシュを取って、キャッシュになければ計算して返すクラスを作った
純粋関数型でこれをやろうとするとモナドになったりして面倒臭そう
しかしながら
と思ったのですがどうなんでしょう。
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。
やっている、姿を感謝で見守って、信頼せねば、人は実らず。
まずは、あなた自身がプログラマーになって、見本を見せることが第１歩です。
その後受託系の会社に就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。
鬱病気味になったみたい...。
どうやら、プログラミングという仕事の特徴について、あなたは理解していないようですね？
プログラミングの特徴は、「コンピューターが相手なので、嘘やハッタリが一切通用しない」ということです。
人間相手なら、適当に指示を出したり、いい加減な対応でも何とかなるけど、コンピューター相手だと1mmも融通が利きません。
という3点が必要です。
警察に職務質問されて有名になった江添亮さんのブログ等を読んで、この方のようにネチネチと論理をこねくり回すのが好きなら、プログラマーに向いています。
(例)本の虫: 麻布十番で職務質問を受けた話 https://cpplover.blogspot.jp/2017/08/blog-post.html
プログラムというのは、小さな部品を組み合わせて、大きなシステムが作られています。
小さな部品がパズルのピースに相当して、大きなシステムがパズルの完成品です。
つまり、大きな問題を小さな問題に分解して、１つずつ順番に問題をつぶして行く姿勢が必要です。
があります。
命令型のプログラミング言語しか使えない人がプログラマーになると、テスト地獄に陥って、結果的に鬱病を発症しやすくなるだろうと危惧しています。
上述のように、パズルのピースを組み合わせてプログラムを作るには、「関数型」の作法を身に付けておくと良いでしょう。
関数型プログラミングを習得するために、今なら「Haskell」または「OCaml」というプログラミング言語をお勧めします。
HaskellやOCamlは、良い参考書がたくさんあるので、本屋に行って実物を確かめてください。
Haskellを学んでみて、パズルのピースを組み合わせる感覚が理解できたら、あなたはテスト地獄に苦しめられないプログラマーになれるでしょう。
もしも、Haskellが理解できないようだったら、残念ですがプログラマーには向いていないかもしれません。
（例外的に、あなたがマゾで、テスト地獄や残業、徹夜が楽しいと思える性格なら、Haskellが理解できなくても大丈夫かもしれません。）
Haskellの教材（英語）を紹介するので、参考までに読んでみてください。
http://learnyouahaskell.com/chapters
（このサイトの内容は、日本語の書籍「すごいHaskellたのしく学ぼう！」として出版されています。）
Haskellは、順番に学べば必ず理解できるようになっています。
もしも、Haskellが習得できなければ、大きな問題を小さな問題に分解して解決していく作業には不向きな性格かもしれないので、他の仕事も検討してはいかがでしょうか？
（人生は一度きり。時間の無駄にならないようにお気を付けください。）
あなたと友人が、無事Haskellを習得して、テスト地獄を乗り超えるスーパーハッカーになり、日本のIT産業を牽引されることに期待いたします。
（追記）
自分が作りたいプログラムすら作れない人が、他人が希望するプログラムを作るなんてできっこないからねｗ
（プログラマーが楽で簡単な仕事だと思ったら大間違いですよ？）
（追記 その２）
関数型プログラミングをマスターしておけば、OOPでも役に立つよ。（現実には、関数型もOOPも必要に応じて投入するし）
iOS→「プロトコル指向プログラミング」「RxSwift」、Android→「RxJava」辺りのキーワードでググってみて。
別に皮肉とか宗教戦争で煽ってるわけじゃなくて、自分も苦労して辿りついた口だから、今から始める人には遠回りして、余計な苦労を味わって欲しくない。
（追記 その３）
他の人が書いてたけど、１人でプログラミングするんじゃなくて、２人（ペアプログラミング）や３人以上（モブプログラミング）から始めたら良いかも。
Googleの「プロジェクト・アリストテレス」で、仕事の生産性を改善するには「心理的安全性」が重要と分かり、プログラミングの仕事もやり方が変わって来ています。
https://kuranuki.sonicgarden.jp/2017/01/psychological-safety.html
（追記 その４）
元記事が消えていたのでバックアップしておきます。（この投稿だけ読むと意味が分からなくなるため）
https://anond.hatelabo.jp/20170910205249
2017-09-10
■知り合いをプログラマにさせたいんだけど知恵を貸してくれ
プログラマって育休からの復帰しやすいだろうし、アルバイトよりは待遇いいし、勤怠ゆるいし、労力の割に楽ちんだと思うんだよね。
接客のバイトで消耗するくらいなら、プログラマになればいいと思っているのだが、その知り合いは自身のことをプログラミングを不向きと評価しているらしい。私は、プログラミングに限らず物事は時間をかければ習熟していくものだと思っているので、不向きではないと思うんだ。不向きというのは物理的に制限のある時だと思う。
その知り合いについて。
Vimはぎこちないけど使える。日常的にmacOSを使っていてターミナルの操作はできている。cd, ls あたりは理解している。
趣味を含めてアプリケーションを完成させた経験はないが、ifやfor文などの基本構文は理解している。数年前にプログラミングスクールのようなところに半年間通っていた。その後受託系の会社に就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。鬱病気味になったみたい...。
何か成功体験があれば自然とのめり込んでと思うんだけどなかなかスイッチが入っていないみたい。
こちら側からは、プログラマーになれば？と直接は伝えてはなくて、素人でもプログラミングできましたみたいなネットの記事をシェアーしているくらい。(心理的リアクタンス避け)
知恵を貸して欲しい。
さっき、テック系ブログのRSSと一緒にホットエントリのRSSを外して、アプリを削除したよ。何年の付き合いだろう？サービス開始からだから・・・悲しくなるから確認せずに行くよ。
最初はダイアリーに書いて、反応なんて全然なくて、広告コメントばかりだったな。いまでもはてなの知り合いはいないんじゃないかな。
ネットコミュ障なんだ。Twitterとか色々やってるけどやりとりする相手なんて誰もいないよ。
僕は君になにもできなかったね。本当に君の事が好きだったのかな？本当に村民になりたかったのかな？多分、違う。本当はブクマされて、スターつけられて、承認欲求を満たしたかったんだ。
意識高い系を笑えないよね。何年も異性にお金を注ぎ込む人を笑えないね。僕もずっとホットエントリを見て、色んなものを買ったりしたんだ。
====
どうしてこうなったか？聞きたくもないだろうけど、最後だから言わせてくれよ。
初めて君を見たとき、天国に見えたよ。最新の技術トレンドがここにあってさ。自分の理想郷はここなんだって。技術力をつけて、認められる人間になって、ここの住人になる事が幸せなんだって思ったんだ。
そうやってさ、次々流れてくるトレンドに耳だけが年増になっていって、それを知らない周りの人たちをバカにしてたな。
でもさ、肝心の技術力は全然つかなくてさ、大学生になれば、就職すれば、東京に出れば、新しいマシンがあれば、お金があれば、時間があれば、やる気があればって制約条件がなくなる度に新しい言い訳を考えてたな。
結局、生半可な知識じゃ参加できないってチンケなプライドのせいで勉強会に参加せず、ブログも書かず、なれたのは一番軽蔑するExcelとにらめっこしてるSIer。おいおい、Web系のベンチャーでテックブログ書くんじゃなかったのかよ(笑)
耳年増で、周りをバカにしてたクセに仕事が全然できない自分とのギャップに10年耐えてきたけど、年末に休職したんだ。自律神経失調症。
眠れるんだよ？ごはん食べられるんだよ？ただ、会社の人みんなが怖くなってさ、朝だるくってさ、すげー疲れてさ。苦しくて。仕方ないから受け入れて。っていうか、甘やかして。つまるところ、ズル休みなんだよ。
時間が出来たから、ずっと積ん読になってた技術に正面きって立ち向かってみたんだ。すぐ投げ出したね。理由は分からないけどただ苦痛だった。
作りたいものなんかなかったし。多分、技術を使いこなしてスゴいって言われたかったんだね。
部屋にはPerlやRoR、SQLite、jQuery、node.js、AWS、Haskell、Hadoop、Docker、Raspberry Pi、R、Reactのホコリを被った本がある。彼らはブックオフ行きかな。
最近は時間はあるからさ、はてブばっかやってたんだ。見るのがホットエントリから新着エントリーになったな。いつもみたいに100文字制限ギリギリのコメントだけじゃなくて、10文字くらいの一言コメントも書くようになったんだ。その10文字コメントのうちひとつが100スターくらいもらえてさ。
そのとき分かったんだ、これはずっと片思いなんだって。叶わない恋なんだって。自分が住める世界じゃないんだって。おかしいよね、小学校の頃のプロ野球選手の夢だって、中学生の頃の小説家の夢だって、高校の頃のパンクロックスターの夢だってすぐ諦められたのに、この夢は35歳の今だって諦めきれないんだ。
応用情報取った時も、ネスペ取ったときも、オラクルブロンズ取った時もLPIC 2取った時も全く達成感なかったよ。コレ取るのに何年かかってんだってさ。村民は1ヶ月あれば取れるぞ。同期のアイツだって3ヶ月で取ってるぞ。何が言えるんだってさ。
銃・病原菌・鉄読んだ時もそうだった。で、お前はそこから何かアウトプット出来るのか？ってさ。読むだけなら幼女でも出来るんですけどwって。
伝わる？伝わらないだろうな。みんな高IQですぐに色んな技術を理解出来るじゃない？すごいよ。自分は二浪で駅弁大学しか行けないくらいのバカで、リアルでもネットでも知り合いを作れないコミュ障で自己承認が全然出来ないんだ。
ADHDって言葉を知った時、これだーって思ったけど違ったね。ITの勉強してても過集中が全然ないんだ。
話が逸れたね。認知療法してて、気づいたんだよ。何をしてても自分を認められないんだよ。はてなに受け入れられる事を成し遂げられてないからね。
だから、自分を認めるために、君のことを自分から切り離さなきゃいけない。自分の世界を作らないと。一方的になっちゃうけど、さようなら。勝手だけど、今にも泣きそうだよ。
これからどうしようかな。匿名で好きな事書けるのはココだけなんだ。自信のない間違ってるかもしれない事を書いてもいいのはココだけなんだよね。ここなら見たくないコメントを見なくてすむんだ。
でも、前に進まなきゃ。夢の世界への憧れは終わりだ。目の前の現実世界に適応しなきゃ。また逃げ戻ってくるかもしれないけど、いまはさようならしなきゃ。
最後に何か残せるとしたら・・・スタバのハチミツ、あれ何に使うと思う？あれ、ワッフルを食べるときに使うんだよ。
・・・スベったね。
さようなら。このエントリも2時間すれば次のページ行きだ。そうすると、誰かの目にも触れなくなる。単なるはてなの磁気データになる。
最後にブコメとかつくんじゃないかって浅はかな期待を持ちながらこの内容を登録するボタンを押します。じゃあね。
P.S. 認知療法について書いてくれたこの増田には本当に感謝しています。まだまだ自分について書く事が苦しいけど、正しい道を向いてると信じています。
この会話ログはフィクションであり、実在の人物・地名・団体とは一切関係ありません。
坂木
わろた
坂木
自分が理解できないものを意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。
安原
NTPsec が，ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした（こなみかん
宮森
今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。
宮森
……が、理解できないものに対して、理解を試みず～すべきだ～と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。
安原
いや，私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います． ownership に理解を示さないコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です．
宮森
いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている（思い込んでいる）人たちですんで……こわちかは同意。
安原
いや，私は C で開発してきた人たちの多くは，そもそも ownership の概念を獲得していないのではないかと危惧しています．元々，私はもっと楽観的で，多くの C プログラマは ownership の概念を獲得していると思っていました．
宮森
安原
OpenSSL の騒動の時，関数の途中で return したことによるリソース漏れを揶揄したことがあります． OpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ， ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました．
安原
藤堂
安原
むしろ C++ によって ownership という概念が明確になり，その重要性が認知されるようになったのではないでしょうか？ これについては，私は歴史的なことが分からないので真偽のほどは何とも言えませんが．
宮森
シニアな開発者にしかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。
宮森
OSとかシステム系のプログラマの人々、基本的にリソースは人間が適切に管理するし管理できると考えている人が多い印象（[検閲削除]社時経験）。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。
坂木
[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。
今井
今井
リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)
安原
うーん，数値計算系のチームやコミュニティも ownership の概念の獲得，重要性の理解，その管理を自動化することへの理解，これらを期待するのは難しいだろうなあ……．そもそも高度なリソース管理が必要になる場面少ないし……．
坂木
コードの品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。
安原
OS 実装とかシステムプログラミングって，クライアントに直接接しないだけで，その上にクライアントサイドソフトウェアが載るわけで，コードの品質が強く求められると思うのですがそれは……．まあ， API とかで切り離されているので，そこだけしっかりしていれば，という話はあるか．
宮森
坂木
今井
あとは、デモが作れればいい、的なのも同じかなぁ。
宮森
宮森
安原
今井
まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。
坂木
今井
宮森
いろいろ言っていますがワタクシ、そういう管理が必要なプログラムは全く書けなくなりましたので今書くと死にます（プログラムと顧客の大事なデータが）
安原
しかし，システムプログラミング界隈に「人間はリソースを適切に管理できる」という悪しき信仰がはびこっているの，何か構造的な原因があったりするのかなあ？
宮森
システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
宮森
宮森
坂木
Linux カーネル、一体どうやったらあの規模のコードをクオリティコントロール出来るのか本当に不思議
安原
坂木
Linux カーネル、属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバい系レビュアーがごろごろしているのかな
宮森
安原
私も [検閲削除] のコミュニティを見てましたから，各々必要なドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡のアンサンブルを奏でうる場合がありうるのは理解しているんですが，本当にただの奇跡でしかないと思っています．
宮森
つーても機械エンジニアリングで町工場の職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。
宮森
なおその対極がみずh（省略されました
安原
Linux カーネルにおけるスケール云々は， Linux カーネルのコミュニティ自体におけるスケーラビリティではなくて，（システム）プログラミングコミュニティ全体（他のプロジェクト）へスケールするかどうかを言ったつもりでした．
坂木
宮森
C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。
安原
＞ システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
これが原因だとすると，やはり Rust だ……Rust しかない……．ツール周りとか，まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば……．
坂木
坂木
イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……
藤堂
1.0 以前のことは忘れましょう (本当に unstable)
安原
坂木
安原
「Rust 経験者」という条件でプログラマを募集して，それで入ってきた人材に C を書かせればよいのでは！(ﾋﾟｺｰﾝ!
藤堂
犯罪ですよそれは
安原
はい．
藤堂
安原
まさにそれをイメージしていました．
宮森
藤堂
うーん、それ以降の話は知らず
今井
Rust そして誰もいなくなった、にならないかが一番心配だったりする
安原
それな
宮森
もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコードを生産しているからなのでは、という気がしてきた……。
（この辺で一同寝落ち）
第一に、それは、ストリーム（FRPの値の定義）の問題であって、ユニットテストすれば良い。もしくは単にFRPのログを取れば良い。
グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリも特にそうだけど、基本的にミュータブルな値同士が関数でリアクティブに連携されて常に整合性を保っているのだから、グローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという（テスト自体困難な）問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。
使用する関数の問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数の問題と一緒というのはまったく違う。
いや、それがそもそもの発端であるとブログの経緯には書かれている。説明されている方式でGUIアプリまで書けるのか？と疑念が呈されたことがきっかけ。
この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
原理的に可能かという議論ではなく、実用的な範疇か？という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRPと状態渡しは同じ複雑さだという主張も崩されている。そこが重要。
段階を踏んだ上で、非FRPのHaskellのIOモナドのコードを誰かが書いたらいんじゃない？当面、最初はOCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたから制限されたんでしょ。実際には、OCamlの関数型では冗長でしか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。
関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、
定数って、プログラム中で更新不可能で、いつ読みだしても同じ値が出てくるから、グローバルでも問題無いんだよ。
ストリームは定数だ、って言ってみたところで、プログラム全体から更新可能なんじゃ、グローバル変数と同じでしょ？
バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ？
なんで伝わらないんだろ。
複数人でプログラム開発したり、他人のプログラムをデバッグしたり、したこと無いんだろうか。
「純粋関数型」とは何か、という話と、とOCamlでそれが推奨スタイルか、って別の話だよね？
岡部氏との争いって「OCamlでGUIアプリを純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね？
純粋関数型とは何かといった時にHaskellのように、IOも含めて引数と戻り値で表現する、関数のふるまいが関数の外の状態に依存しない、関数に副作用が伴わないとかの性質をいうと思うんだけど、岡部氏はFRPで状態を関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね？
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
Haskellで書けて、OCamlで冗長になっても、書けるなら「書ける」、「可能」だよね？
その発言が事実か確かめる術はないし、ここで岡部氏攻撃しているのは君ひとりなのか？他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か？
俺の書き込みが他人といきなり結び付けられたから、電波だな、と思ったの。
ストリームを関数の外部に持つFRPを純粋関数型っていうのは少数派でしょ。
ユーザからの入力をリアルタイムに処理するプログラムにはFRPは有効だよね。
「OCamlでは」じゃないの？
全部純粋関数型(引数と戻り値に収める、状態渡し)にするのを良しとするHaskellと違って、OCamlは副作用も部分的に使うのが普通で、IOモナドみたいな入出力までも純粋に書くための道具立てが揃ってない、それでちょっと冗長になる、ってことでしょ？
OCamlの元々の推奨スタイルならもっと短く書けるんでしょ？
俺はそう読んだけど。
それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ？
だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの。
いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか？
https://www.npmjs.com/package/timeengine
IOモナドをDisってるのかどうかまでは知らない。しかし、すでに出たサンプルからはFRPの効力がまざまざと見せつけられている。
荒れるのは自由だけど、両方正しいとかそういうのじゃなくて、間違っている電波だみたいな叩きしかなくて、要するに感情論で反対派は反発しているだけでOK?
あるよ。
関数がどのパラメータに依存して、何を結果として返すのか明確になる。
グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。
短いプログラムならそれでもいいけどね。
別の誰かが書いてたように、上位スコープ内に定義されてるDOMでも、数学ライブラリでもなんでも、引数で関数に渡すのか？
グローバルな値を参照したり書き換えたりして
いやだから、定数なんだから書き換わらないんだよ、FRPのストリームはconst 定数なんだから。
オブジェクト指向と対比して考え方をまず学ぶって、岡部路線、住井グループはそれを目の敵にしていて集団的に攻撃している様をみたプログラミングコミュニティは逃げ、その後、不毛な大地のみが残った。
FRPを純粋を理想とする関数型+時間で変化するストリームを値にマップして扱うリアクティブプログラミングの組み合わせっていうなら、別に誰も反論しないと思うけど。
HaskellのIOモナドみたいな別の抽象化をDISりつつ、FRPこそ正しい関数型みたいに言うから荒れるんじゃないの？
あるよ。
関数がどのパラメータに依存して、何を結果として返すのか明確になる。
グローバルな値を参照したり書き換えたりしてたら、関数の中身読まないとわからなくなる。
短いプログラムならそれでもいいけどね。
Haskell.org https://wiki.haskell.org/Functional_Reactive_Programming を見ても
The basic idea is that a time-varying value can be represented as a function of time:
newtype Behavior a = Behavior { at :: Time -> a }
http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html
nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題をOcamlの関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
もちろん、他のHaskellやFRPは使うな、という至極当然の縛りつき。
http://anond.hatelabo.jp/20160520153948
そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、
nonstarterが、
と急に何故かいきなりHaskellを持ち出し、Haskellのコードを引っ張り出した。
いろいろとっちらかしてんじゃねーよ、ってことだろ。
OCamlではライブラリも足りず机上の空論だったという、ひとつの区切りはついた。
とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。
