トップページ⇒tech
981コメント333KB

【数学者】Haskellはクソ言語【オナニー】

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん2005/09/30(金) 01:34:05
C/C++＞＞＞＞(越えられない壁)＞＞＞Haskell
0809デフォルトの名無しさん2008/02/16(土) 23:16:48
>>802,804
まずはこれを読んでみてくれ。
http://d.hatena.ne.jp/w_o/20061008#p1

これが面白いのは、参照透明は程度問題に過ぎないという
視点を得られる所なんだと思っている。
0810デフォルトの名無しさん2008/02/16(土) 23:18:09
参照透明性なんて飾りだよ
Haskellの魅力は、副作用が禁じられていることじゃなくて、
副作用なんていう扱いにくいものに頼らなくても自然にプログラムを書けることだ

遅延評価は大いに使う
「ほぼ使わない」なんて思えるのはHaskellに慣れてないだけだ
例えば、C言語の典型的なfor文の使い方
for(T i = init; cont(i); i = next(i)) use(i);
を、Haskellで自然に書き直すと
mapM_ use $ takeWhile cont $ iterate next init
になるけど、これは無限リストを使っている
0811デフォルトの名無しさん2008/02/16(土) 23:19:34
>>809
あなたはネタを理解できない人なんですね
0812デフォルトの名無しさん2008/02/16(土) 23:23:05
遅延評価便利だよ。
MLが不便に思えるぐらいだ。
0813デフォルトの名無しさん2008/02/16(土) 23:23:13
>>811
ドッキリとかを真に受けるタイプの人でしょ?
>>809 がネタなんだけどね
0814デフォルトの名無しさん2008/02/16(土) 23:26:29
>>799
unsafeなんとかは、本当は参照透明なのに、コンパイラが参照透明だと見なしてくれない式を書くときに使う
そうじゃない使い方もできるけど、それは邪悪な使い方だ
0815デフォルトの名無しさん2008/02/16(土) 23:28:06
ffi使えばunsafe使わなくてもいくらでも邪悪なプログラムが書けるぜ。
0816デフォルトの名無しさん2008/02/16(土) 23:28:41
HaskellのFFIはめちゃくちゃ楽だからな。
組み込みプログラムもなんのその。
08177992008/02/16(土) 23:41:48
>>803　>>808

８０３のリンクは、
「参照透明は関数型言語の魅力としては不適当」と言っているのでは？
0818デフォルトの名無しさん2008/02/16(土) 23:47:33
>>816
オーバーヘッドもあるしメモリも食いまくるから組み込みには全く向かないだろ
0819デフォルトの名無しさん2008/02/16(土) 23:54:08
>>818
関係ない。
組み込み＝低リソースという時代は終わったんだよ。
それよりも、たとえばロケットや自動車のような用途では安全性が求められる。
0820デフォルトの名無しさん2008/02/16(土) 23:57:18
>>817
参照透明でなければ遅延評価は役に立たないよ
0821デフォルトの名無しさん2008/02/17(日) 00:00:21
D 言語に遅延評価もどきはあるけどな。
0822デフォルトの名無しさん2008/02/17(日) 00:02:57
遅延評価はテクニックに近いものもあるしな
08237992008/02/17(日) 00:06:23
>>820
なるほど…。

でも、遅延評価も必ず使うわけではないし、
(IOの時など遅延評価されては困る場合もあるわけですよね？)

なんというか、参照透明そのものの優位性がわからない…。

・コンパイラが作りやすい？
・数学的にみて美しい？

…、いずれも一般ユーザには関係ないですよね…。
0824デフォルトの名無しさん2008/02/17(日) 00:07:34
参照透明性ってデバッグの容易さの点で重要と聞いてるけど。
08257992008/02/17(日) 00:08:33
>>814
う〜ん…。これは正しいのでしょうか？

あくまでも、Haskellは参照透明であって、
そうでないプログラムは邪悪という事ですよね。
0826デフォルトの名無しさん2008/02/17(日) 00:11:43
>>823
参照透明だったら関数の返値をキャッシュできるよ
08277992008/02/17(日) 00:14:55
>>826
コンパイラの話ですよね…。
08287992008/02/17(日) 00:16:41
>>824
Haskellのデバッグってむしろ大変そうですけど…。
0829デフォルトの名無しさん2008/02/17(日) 00:18:15
>>827
完全にキャッシュできればプログラマはわざわざメモ化とかのテクニックを使ってプログラミングする必要がなくなる。
・・・とは言うものの、GHCでは完全にキャッシュしているわけではない。
0830デフォルトの名無しさん2008/02/17(日) 00:19:45
>>828
Cのデバッグで一番骨が折れるのが型によるバグ。
Haskellはコンパイルさえ通れば型に関しては完全に矛盾がない。
0831デフォルトの名無しさん2008/02/17(日) 00:20:48
>>823
だから、参照透明性はそんなに重大な特徴じゃないんだって
（利点が無いわけじゃない。コンパイラによる最適化がやりやすい。コードが読みやすい。リファクタリングしやすいetc）
逆に、「参照透明でないこと」(破壊的代入や副作用を認める)にも大して優位性は無いんだ

Haskellにはもっと重要な特徴がたくさんある
動作オブジェクトを利用した入出力とか、代数的データ型＋パターン照合とか、型クラスとか、遅延評価とか
08327972008/02/17(日) 00:25:59
>>830
Haskell の型はステキだと思いますよw

でも、traceとか「デバッグ」は大変そう…。
0833デフォルトの名無しさん2008/02/17(日) 00:29:07
>>831
>参照透明性はそんなに重大な特徴じゃない

そうですよね…。
でも、なんか、かたくなに参照透明性を守ろうとして
余計わかり難くなってる気がするんですよね。

全面的な参照透明性を捨てた方が、
すっきりするのではないでしょうか…？
08347992008/02/17(日) 00:29:52
↑>>833 は 799です
0835デフォルトの名無しさん2008/02/17(日) 00:30:17
第15回　Haskellでのデバッグのコツをつかむ
http://itpro.nikkeibp.co.jp/article/COLUMN/20071204/288630/
0836デフォルトの名無しさん2008/02/17(日) 00:30:34
traceってどういうのを指してるか分からんけど、printfデバッグの類は普通にできる

ただ、HaskellがCよりデバッグしにくいのは事実だと思う
gdbに匹敵する使いやすさのデバッガがまだ無いからだが

>>833
>でも、なんか、かたくなに参照透明性を守ろうとして
>余計わかり難くなってる気がするんですよね。
どの辺でそう感じた？
08377992008/02/17(日) 00:31:00
ああっ！
>>832 も799です。
08387992008/02/17(日) 00:35:00
>>836
> printfデバッグの類は普通にできる

そうなんですか？
なんかprintfいれるとバグが再現しないとか多そうですが…。


> どの辺でそう感じた？

IOモナドww
参照透明性を捨てれば
もっとステキな実装がありそうじゃないですか？
0839デフォルトの名無しさん2008/02/17(日) 00:38:46
参照透明性を確保するために導入したんだから
本末転倒だじょ
0840デフォルトの名無しさん2008/02/17(日) 00:41:05
俺はIOモナド大好きなのでその気持ちは良く分からん
例え参照透明性を捨ててもIOモナドは使いたい
08417992008/02/17(日) 00:41:50
>>839
ん？
いや、だから、参照透明性に固執するから、
IOモナドなんて理解しにくい方法で実装してるんでしょ？
0842デフォルトの名無しさん2008/02/17(日) 00:43:33
参照透明性を実現する完全に純粋な関数型言語を作るのが
Haskell の１つの目標だったんじゃないのか？
0843デフォルトの名無しさん2008/02/17(日) 00:50:41
IOモナド、というかIO動作の考え方は多少とっつきにくいけど、分かってしまえば簡単なことだし、
副作用を使った入出力よりずっとまともだと思う
それから、遅延評価の言語で素朴に副作用を使うと実行順が制御困難になるけど、
IO動作ならこの問題がない

>>842
だろうな
でも言語のユーザーにとってはそんな目標はどうでも良い
0844デフォルトの名無しさん2008/02/17(日) 00:51:38
参照透明性が要らないというなら OCaml とか他の言語使えばいい。
それだけだと思うぜ。
0845デフォルトの名無しさん2008/02/17(日) 01:00:20
>>844
その議論はおかしい
Haskellの特徴は参照透明性だけじゃない
デフォルトの遅延評価も型クラスもIOモナドも$演算子もOCamlには無い
参照透明性なんてどうでも良いという奴にでも、Haskellを使う理由はいくらでもある
0846デフォルトの名無しさん2008/02/17(日) 01:09:14
じゃあ、参照透明性の無いHaskell に相当する言語を作ったらいいんじゃね。
08477992008/02/17(日) 01:12:57
>>840
そうなんですか…。
結局、慣れの問題なんでしょうかねぇ…。
0848デフォルトの名無しさん2008/02/17(日) 01:15:01
Haskell では参照透明性をくずすものは trace のみなんだっけ？
08497992008/02/17(日) 01:15:23
>>846
まさに、そう、思うんですよw

そんな言語があれば、
確実にブレイクするのではないでしょうか？

誰か作って！私はもちろん……ﾑﾘ!
0850デフォルトの名無しさん2008/02/17(日) 01:26:25
>>848
unsafePerformIOってのがある

>>849
単に参照透明性のないHaskellならunsafePerformIOを言語の一部として認めれば良いんだけど、
IOモナドを排除するのは難しいと思う
>>843で書いたけど、普通の言語にあるような副作用による入出力は、遅延評価と相性が悪い
実行順を分かり易く制御するには、結局、IOモナドか、Cleanの一意型か、
それに代わる何か新しいメカニズムが必要になる
08517992008/02/17(日) 01:39:54
>>850

な〜るほど！
ひょっとしてunsafePerformIOを使いまくって
>>814 の言う邪悪なIOライブラリを作れば、
Haskellのままでもいいかもしれませんねw


0852デフォルトの名無しさん2008/02/17(日) 01:41:59
もう屁みたいな例をたくさんあげられるのはウンザリだよ。

こうしよう、C（ほかの言語でもいい）からHaskellに乗り換えるために十分な
説得力を持つ実務的な例を１つだけあげてくれ。
0853デフォルトの名無しさん2008/02/17(日) 01:55:30
darcs
08547992008/02/17(日) 01:55:42
>>852
「実務的」というかどうかはしらないけど、
コンパイラ的な処理には向いてるらしい…。


再帰下降構文解析
ttp://ja.wikipedia.org/wiki/%E5%86%8D%E5%B8%B0%E4%B8%8B%E9%99%8D%E6%A7%8B%E6%96%87%E8%A7%A3%E6%9E%90
HaskellやMLなどの関数型言語での再帰下降構文解析の実装は特に簡単である。

出典: フリー百科事典『ウィキペディア（Wikipedia）』
0855デフォルトの名無しさん2008/02/17(日) 02:00:39
> HaskellやMLなどの関数型言語での再帰下降構文解析の実装は特に簡単である。
っていうのはウソっていうのはどっかでみたなｗ
0856デフォルトの名無しさん2008/02/17(日) 02:06:37
>>854
実際、言語処理系には向いてる。
構文解析だけじゃなく、コンパイル過程での構文木の操作とかに
代数的データ型とパターンマッチがぴったりハマってかなり綺麗に書ける
（MLも同様。代数的データ型じゃなくてバリアントという名前だけど）。

言語処理系は、基本的にツリーの変形みたいな
I/Oを伴わない数学的な処理が多いから、という理由づけもできるかな。
08577992008/02/17(日) 02:08:10
Haskellというか、関数型言語の魅力としては、
>>803 のリンク先を読めばかなり納得できると思う。
0858デフォルトの名無しさん2008/02/17(日) 02:16:57
>>848
いいえ
0859デフォルトの名無しさん2008/02/17(日) 02:23:46
Haskellの言語仕様にunsafeとかFFIとかってあったっけ？
GHCの仕様じゃないの
0860デフォルトの名無しさん2008/02/17(日) 02:27:47
>>859
FFIはHaskell 98への追補
http://www.cse.unsw.edu.au/~chak/haskell/ffi/
unsafePerformIOも入ってる
0861デフォルトの名無しさん2008/02/17(日) 02:29:45
じゃあ、Haskellは純潔を失ったというわけだ
0862デフォルトの名無しさん2008/02/17(日) 08:36:34
ハードリアルタイムアプリはHaskellでは無理
0863デフォルトの名無しさん2008/02/17(日) 09:30:28
実時間要求とメモリを直接利用するアプリケーション以外はHaskellでおｋ
0864デフォルトの名無しさん2008/02/17(日) 11:58:51
>>863
できるだろ
http://www.haskell.org/ghc/docs/latest/html/libraries/Win32/System-Win32-DebugApi.html#v%3Ac_ReadProcessMemory
0865デフォルトの名無しさん2008/02/17(日) 12:01:27
仮想メモリとかOS必須じゃｎ
0866デフォルトの名無しさん2008/02/17(日) 18:47:44
Haskell (International Computer Science Series) (ペーパーバック)
Simon Thompson (著)
# ペーパーバック: 528ページ
# 出版社: Addison Wesley; 3Rev Ed版 (2008/9/15)
# 言語 英語, 英語, 英語
# ISBN-10: 0201882957
# ISBN-13: 978-0201882957
# 発売日： 2008/9/15

今度こそ発売?
0867デフォルトの名無しさん2008/02/18(月) 18:08:34
参照透明性を保証しないと、グラフ簡約が使えなくね？
0868デフォルトの名無しさん2008/02/18(月) 18:18:32
使えなくはないと思うが、何で？
0869デフォルトの名無しさん2008/02/18(月) 20:15:31
>>642
データ構造とアルゴリズムをまとめるだけなら、それこそ関数型言語の得意分野だし、
手続き型の世界でも、メッセージメタファって何それ、なgeneric programmingが幅を利かせている。
その分なおさら、状態と手続きをまとめるSmalltalk的なオブジェクト指向が
影響力を増しているように思う。
>>654のAlan Kayの言葉は、実行順序への依存性が下がること
(これはメッセージメタファ、イベント駆動から自然に出てくる)と、
参照透明という意味で状態を全く持たないことを(故意に？)混同している。
0870デフォルトの名無しさん2008/02/19(火) 02:47:18
ハードウェアリアルタイム処理って言葉にすれば
Haskellはかなりいけそうな感触なんだけどなぁ
0871デフォルトの名無しさん2008/02/19(火) 10:02:24
>>868
形式的な表現が同じでも、値が同じことの保証がなくなるから。
0872デフォルトの名無しさん2008/02/19(火) 10:36:55
>>871
副作用を入れるなら当然それは覚悟の上じゃないのか
0873デフォルトの名無しさん2008/02/19(火) 12:45:42
>>872
副作用を入れてもいいのは、値がユニット型の関数だけにしないと破綻するだろ。
0874デフォルトの名無しさん2008/03/09(日) 07:06:26
↓この暗号が解けたら初心者卒業と言えるでしょうか？
main = getArgs >>= putStr . flip id "\n" . foldr (.) id . map (showHex . read)

ttp://haskell.g.hatena.ne.jp/nobsun/20060819/ShowS を少し改変
0875デフォルトの名無しさん2008/03/09(日) 10:02:11
>>874
暗号に見えていたのが、何の変哲もないプログラムとして認識できるようになったら卒業だな。
08768742008/03/09(日) 19:04:29
>>875
そうですか…
1日がかりで解けたので初心者卒業かと思ったのですが…orz

何の変哲もないプログラムに見えるように精進しますw
0877デフォルトの名無しさん2008/03/09(日) 23:43:38
何の変哲もないように見える必要はないと思うが解くのに１日がかりはまだ初級者の域か。
0878デフォルトの名無しさん2008/03/13(木) 21:20:39
悩むところが見当たらん

おれはもうだめだ
0879デフォルトの名無しさん2008/03/13(木) 21:26:04
flip id "\n"が悩むところじゃないか？
なぜ($"\n")と書かないんだろう
0880デフォルトの名無しさん2008/03/14(金) 13:47:26
Prelude> ($ "789") $ ($ (($ "456") $ ($ "123") $ (++))) $ (++)
"123456789"

スタックマシンみたいだ(w
0881デフォルトの名無しさん2008/03/18(火) 18:48:31
便利だなこれ
\a -> hoge a 4 ()
flip (flip hoge 4) ()
($ ()) . ($ 4) . hoge
0882デフォルトの名無しさん2008/03/19(水) 16:27:19
>>881
ああ、そうやってカリー化できるんだ。目から鱗が落ちたよ。
0883デフォルトの名無しさん2008/04/12(土) 21:48:42
引く手あまたのプログラミング言語は?
http://slashdot.jp/developers/article.pl?sid=08/04/06/2313251
---
Java(16479件)、C++(8080件)、C#(7780件)、JavaScript(6749件)、
Perl(5710件)、PHP(2641件)、Python(1408件)、COBOL(1207件)、
Ruby(769件)、Lisp(33件)といった感じらしい。

とりあえずJavaとC/C++/C#、あとJavaScriptを覚えれば、
当分仕事には困らないようである。COBOLのしぶとさも目立つ。

ちなみにHaskellやOCamlの求人は10以下だったそうだ。
---
0884デフォルトの名無しさん2008/04/19(土) 00:45:19
仕事でプログラムやってるやつなんて
この板にいるの？
0885デフォルトの名無しさん2008/04/19(土) 01:39:26
ええっ？ほとんどプログラム関連の人じゃないの？
0886デフォルトの名無しさん2008/04/19(土) 01:41:22
プログラム関連の研究を仕事でやってる人はいるかもしれないが
0887デフォルトの名無しさん2008/04/24(木) 00:13:42
この「板」にはいくらでもいるだろう＞仕事でプログラムやってるやつ
このスレに限れば、仕事と直で結びつきにくい言語かもしらんけど

でも仕事でプログラムやる傍ら、趣味や素養のためにHaskell弄ってる奴も珍しくはないんじゃなかろうか
0888デフォルトの名無しさん2008/05/03(土) 18:08:15
俺は研究職だが仕事でHaskell使ってる。
0889デフォルトの名無しさん2008/05/25(日) 22:21:03
はじめましてAranskファンクラブです。
皆さんはAranskをご存知でしょうか？
最近ネット社会において急速に発言力を増しつつある
集団です。
本家：http://homepage3.nifty.com/Aransk/
ミラーサイト：http://www.geocities.jp/aransk88/
日本語Blog:http://aransk.cocolog-nifty.com/whypro/
英語もどきBlog：http://d.hatena.ne.jp/Aransk/ここまでがAransk Officialsです。
（上記以外にも２ちゃんねるのプログラム板にAransk専用スレが
立っていますが、これはAranskとは何のつながりもありません。）
上記の２ちゃんねる、yahoo掲示板に精力的に意見を
書き込むと同時に自らのサイトの更新も頻繁に
行っています。
驚いたことに、あらゆる場所で人気が「ありません。」
その人気の無さをこのBlogで究明してみるつもりです。
ご興味ある方は是非ご参加下さい。
0890デフォルトの名無しさん2008/05/25(日) 22:30:18
\yってｙを含まないって意味だっけ？
0891デフォルトの名無しさん2008/05/25(日) 23:10:13
Haskellの\はlambda
\y -> e で、yからeへの関数
0892デフォルトの名無しさん2008/06/05(木) 18:49:53
逆ポーランド記法で日本人に優しいとか言ってみるRPHaskellとか作って
0893デフォルトの名無しさん2008/07/21(月) 10:56:30
「初心者のためのプログラミング言語ガイド」スレに
Haskellを狂信的に勧めるやつが現れてスレがめちゃくちゃに。
0894デフォルトの名無しさん2008/07/21(月) 19:56:00
>>893
信者と信者っぽく振る舞ってネタにしてる奴と2種類いるようだな。
0895デフォルトの名無しさん2008/09/12(金) 21:26:02
Haskellの入門書は、ふつうのHaskellプログラミングでおｋ？
0896デフォルトの名無しさん2008/09/12(金) 21:30:22
>>895
WEBが一番

ここが一番わかりやすいぞ
http://www.sampou.org/cgi-bin/haskell.cgi
0897デフォルトの名無しさん2008/09/12(金) 23:45:22
>>896
マジか。本買おうかずっと迷ってたんだ。サンクス。これでやってみるよ。
LL Futureで見たんだけどHaskellって並列プログラミングの強さはどんなもんでしょう？

ttp://www.nicovideo.jp/watch/sm4505381
089836 ◆K0BqlCB3.k 2008/09/13(土) 00:50:59
>>897
現在開発中で一部は使用可能
http://hackage.haskell.org/trac/ghc/wiki/DataParallel/WorkPlan
0899デフォルトの名無しさん2008/09/13(土) 02:18:36
Erlangにすればいいんでない?
0900デフォルトの名無しさん2008/09/17(水) 01:21:22
>>897
本の方がわかりやすいと思うがWebの方を読んで理解できるレベルなら
それでいいと思う。お金かかんないし。
0901デフォルトの名無しさん2008/12/28(日) 21:41:49
ふつうのHaskellは馬鹿でも判るって意味では良書かな
その程度に敷居も得られる知識も低い
0902デフォルトの名無しさん2008/12/29(月) 09:26:47
道具として使うには十分
論文書きたいなら書籍より論文読めよ
0903デフォルトの名無しさん2008/12/29(月) 20:15:13
ふつけるよりも入門Haskellのほうが目から鱗的な部分があって楽しいと思う
0904デフォルトの名無しさん2008/12/30(火) 16:55:18
birdのhaskell本が入門書としては最強らしいよ
0905デフォルトの名無しさん2008/12/31(水) 16:52:16
Haskell界隈にも>>901みたいな厨が流入してくるとは隔世の感。
0906デフォルトの名無しさん2008/12/31(水) 17:14:30
>>905
このスレには昔からいただろww（　＾ω＾）
0907デフォルトの名無しさん2009/01/13(火) 19:07:14
本スレ落ちたのか？
0908デフォルトの名無しさん2009/01/13(火) 20:42:09
こちらが本スレです
レス数が900を超えています。1000を超えると表示できなくなるよ。