ニコニコ大百科

マウスで適当にHaskellのマークを書いてみました。orz
記事内参照用URL :

副作用なしでここまでできるってのがすごい。本当に便利な言語。

最近始めたよ

>>2
副作用はありますよん。IOモナドさんが隠してくれているのです。

元々の問題は、純粋関数型言語であるがために既存の変数を変更できないのですよ。

でも入出力っていうのは入力/出力の状態を変更することにあたるわけで、どうしても変更は必要だったのです。

そこで、モナドの性質
・値をデータ型の中に入れてしまえばモナド則を満たしている以上中身を取り出せない
・入れたままならなんでもできる
っていうのを使って中身を隠蔽しているのです。

そうすれば、入力/出力だけの世界に変更を閉じ込めることができるので純粋な世界は侵されないってはなしですね。

>>4
HaskellがIOにモナドを使ってるのと再代入ができないのはあんまり関係ないと思う。
HaskellがIOについて抱えてる問題は
・プログラム全体で参照透過性を保たなきゃけない
・遅延評価のせいで式が評価されるタイミングが定まらない
のふたつで、それを解決するためにモナドを使ってるじゃないのかな。


あと、
＞・値をデータ型の中に入れてしまえばモナド則を満たしている以上中身を取り出せない
＞・入れたままならなんでもできる
この二つはモナドの性質としてはあまり適切じゃないかと。

中身を取り出せないのはモナドの性質じゃない。
実際、中身を取り出せるモナドもあるし。

それに、別にモナドに入ってるから出来ることが増えたりしないよ。
むしろ、モナドに包んだままでも中身に対して包んでない時と同じ操作を行えるのがモナドの重要な性質。

>>5

参照透明を保ったままIO(≒再代入)を行うために状態を持ちながら引っ張っていくのがIOモナドで、関係はまぁ無くもないとは思うのです
ちなみに評価の順番はArrow(関数合成)を使っても制御できまして、
これだと並列化もわりと簡単にできるのでモナドよりも楽しい気がするんですけど。

あーそうですね、たしかに別に操作可能ではあります
言いたかったのは、モナドは中身を取り出さずに中身をいじれるっていう話です、ごめんなさいｗ
意味上で持って来られないもの(MaybeとかListとか)は操作が認められてないだけで、Identityとかなら普通に取り出せますしね・・・

上の例，
factorial :: Int -> Int
factorial 0 = 1
factorial n = n*factorial (n-1)
も入れるのはどうだろうか

ピュアであろうとするのはいいが、簡単なことをわざと複雑にしてる感がC++に通じてあんまり好きになれない。
Ocamlあたりで妥協した方が良くね？と思う今日この頃。

Rubyで書いてみて、イラっとしたらHaskell
そんな感じの使い分けでで楽しく付き合えてる

lambdaがgotoだとよくわかる言語

一通り使ってみたけど、LISPの副作用も関数型でも何でもござれにどっぷり浸かった俺にはもはやHaskellは無理な体にされていた。

> 日本語でおk

これ昔の話?今は普通に日本語を文字列リテラルに入れられますよね.それともunicode syntaxの話?

>>12
http://foobardam.hatenablog.com/entry/2012/10/22/125452
こういったことは現在では起きないのでしょうか。もし言語仕様が変わっているのでしたら記述を改めたいのでお知らせ下さい。

>>8
>>ピュアであろうとするのはいいが、簡単なことをわざと複雑にしてる感がC++に通じてあんまり好きになれない。
これ本当に分かる
純粋さを取る代わりに分かりやすさを捨てる精神が好きじゃない

> 外部とのやりとりは、壁にあいたIOモナドという小さな窓から行う。
というか、「外の世界は我が家の中にありますけど?」と主張している電波少女なのでは……

>>15
そういう見方も出来ますが、擬人化には分かりやすく・親しみやすく伝えるという目的もあるかと思います。
記事では純粋関数型言語=状態変更の拒否=入出力すら制限=ひきこもりという巷でも見かける批判図式に乗っかってみました。
(IOモナドのRealWorldは取り出せないから、「家の中」にはないという議論を始めても不毛ですし。)

久々に読み直したら

「期限が来てからでないと仕事を始めない彼女のことを怠け者(Lazy)と評する(Evaluate)人もいるが、その評価は正格ではない。」

ここに気づいて感心した

>>17
4年間日の目を見なかったネタに気づいてくださりありがとうございます。

目的が広くなって良さを失ったElm

Haskell自体は面白い言語だけどこれで実際のサービス書くのは無理
・IDE周りがほとんど整備されておらず、開発環境の構築からして既に厳しい(haskell-ide-engineもピーキーすぎてすぐ止まる)
・ビルドも工夫しないと平気で1h以上かかる
・名前衝突の問題などレコードフィールド周りが微妙(言語拡張もあるとはいえ限度がある)
エコシステムや言語としての使いやすさに興味のない、圏論オタクとアカデミアの民だけが細々と持ち上げてるイメージ

プログラミング初心者がHaskellを学ぶにはどうすればいいの？
すごいH本はあるけど読んでも意味が分からない

>>21
Haskellを投げ出した自分が答えるべきではないのかもしれないですが、どうしてHaskellを学びたいのかと、どれくらい労力を投入できるかによると思います。
プログラミング言語選択ガイドの記事にも持論を書きましたが>>21から推測されるレベルだと、大抵の場合はあきらめて他の言語にした方がいいです。

どうしてもHaskellが必要で、いくらでも(月〜年単位で)時間をかけられるなら、IOモナドとdo記法だらけの汚いコードでもいいからとりあえず書いてみて、それをきれいにするにはどうすればいいかを考えるという行為を繰り返すと慣れてくることがあるかもしれないとは思います。
どの程度のレベルまで到達できるかの上限は本人の(抽象論・証明系の)数学力に依存します。

とはいえHaskellを投げ出した人の発言なので、鵜呑みにはしないでください。大事なことなので(ry

>>22
ほかの言語を習得することが一番の近道みたいですね
どうもありがとうございました

数学を極めた実戦級プログラマーにはHaskellが最高に良いらしいね
理論通りにバグのないコードを組めて予測通りに動くからとか
しかし圏論の手法を手足のように使える人でないと黒魔術過ぎるから初心者が手を出す代物じゃないと思う

すごいH本がよく勧められるのは、ひとえに入門者向けの適切な本が他にない時代が長かったから
あの本は「細かい事は抜きにしてとりあえずHaskellの空気を浴びてみよう」みたいなテイストだし、言うほど易しくないし、そもそも今では内容古いし、
他言語の経験があるなら積極的にはオススメしない
今だったら『入門Haskellプログラミング』辺りがベターかと
正真正銘のプログラミング初心者なら多分すごいH本以外に適切な本はないと思う

すごいH本の説明だと今ひとつピンと来ないって人は結構いるんだけど、
Haskellのプロって大体すごいH本でHaskellに慣れるというルートを通っているから、
あれで理解できない人をどう教えたら良いのか分からないらしいんだよね

すごいHは初めてプログラミングを学ぶ人にはいいが、
既に経験があってHaskellを追加で学びたい人はHaskell入門がいいって意見を見たことがある

でも、すごいHはどう見てもオブジェクト指向をある程度習得していることが前提の言い回しが多いよな・・・

haskellでコーディングするのくっそ楽しい
コンパイル通ったあとの安心感は異常
（遅延評価が原因のパフォーマンスチューニングは地獄と聞く）
でも慣れるまでに比較的時間がかかってサクサク書けないのがつらい
てかごく普通の人で仕事で使ってる人殆どいないと思う（偏見）

仕事で使ってる人のブログのよるとhaskell以外の言語での仕事はあり得ないくらいにイイモノらしい
そのレベルで使いこなせる人は普通の人じゃないけどね

Haskellから受ける、ただでさえ陰キャの多いプログラミング界隈の中でひと際目立つキモオタがブヒつきながら触っていそうという印象は間違っていない。
その上で、別に数学を極めてなくても使えるし、Haskellコミュニティには優しく教えてくれるおじさんがたくさんいるのでもっと気軽に入門して欲しいということを宣伝しておきたい。
https://haskell.jp/

> 日本語でおk
ここおかしくね?
自分は文字列リテラル内部でもソースコードでも(日本語特有のの概念(ガ格とか)を使うので)日本語使ってるけど支障ないぞ。
Haskell 2010以前の話かな?