2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【アンチ】関数型言語は使えない【玩具】

1 :デフォルトの名無しさん:2011/11/08(火) 18:06:57.51
関数型言語は学習コストが高すぎる。

玩具として、研究者や学生の自己満足として、
教科書や黒板を賑わすアクセサリーとして、
あるいは頭の体操としての価値は認める。
だが、仕事ではほとんど使い物にならない。

やれば作れる、実際に作った、そんな言い分は聞き飽きた。
主要なソフトウェアのほとんどは非関数型で書かれている。
関数型がプチブームだが、爆発的に採用が増えているとも考えられない。
いずれ関数型のブームは去るだろう。
仮に関数型が生き残ることがあったとしても、
手続的な言語における一部の機能としてだろう。

2 :デフォルトの名無しさん:2011/11/08(火) 18:33:19.43
はいはい
アイちゃんアイちゃん

3 :デフォルトの名無しさん:2011/11/08(火) 18:40:07.75
バカに教えようとしたのがまずかったんだ

4 :デフォルトの名無しさん:2011/11/08(火) 18:50:44.56
人間の日常的な思考は全く関数的でない。
業務の手順等も全く関数的でない。
「まずこれをやって、それからこうして、
それでこうなるから、これをこうする」的な考え方をするのが普通の人間。
もしそれを自動化するプログラムを書こうとした場合、
それを素直に書ける言語のほうが普通は楽にできる。
仮に関数型のほうが簡潔に書けたとしても、
関数型に脳内変換しなければならない時点で負担は大きい。
関数型なら生産性が向上するという主張は、
一部個人ではそういうこともありうるが
社会全体としてはむしろ生産性の低下につながる。

関数型が使えないのは頭が悪いからだというのは、まぁある程度正しい。
だったら頭の良い人が自己満足で使っていればよいのであって、
他人様を巻き込む必要はない。

5 :デフォルトの名無しさん:2011/11/08(火) 19:06:26.34
京都大学霊長類研究所では、未知の感染症が蔓延し、
感染した研究員はどのスレッドにも同じコピペを
繰り返すといった症状が報告されています。

研究員によると思われる書き込みがあっても
近づかないようにしてください。

                  京都大学


6 :デフォルトの名無しさん:2011/11/08(火) 19:09:22.90
【萌え画像】子猫にブルマーをはかせてみた。。。(*´Д`)ハァハァ
http://toki.2ch.net/test/read.cgi/cafe60/1270834077/

7 :デフォルトの名無しさん:2011/11/08(火) 19:12:56.72
時々の状態を覚えておかないといけない
クライアントアプリケーションに関数型の適用は不適切だと思う
Webサーバアプリは大きく見ればフィルタと見なせるから
組みやすさは別として関数型が使える分野だと思う
使ったことはないが


8 :デフォルトの名無しさん:2011/11/08(火) 19:49:17.34
流行るということは馬鹿と貧乏人が手を出すということだ
よって関数型言語は流行りようがない

9 :デフォルトの名無しさん:2011/11/09(水) 10:29:21.69
黒板とな

10 :デフォルトの名無しさん:2011/11/09(水) 10:41:44.92
>>1
流行らないから安心しろ。
分かる人間だけが細々と使っていき、その成果が手続き型に取り込まれていくだけ。
もし流行るなら、もっとマシな世界になってる。

11 :デフォルトの名無しさん:2011/11/09(水) 14:46:59.29
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所

12 :デフォルトの名無しさん:2011/11/09(水) 15:18:41.53
>>1
スレタイ間違ってるよwww

誤:【アンチ】関数型言語は使えない【玩具】
正:【アンチ】関数型言語が使えない【玩具】

13 :デフォルトの名無しさん:2011/11/09(水) 17:56:57.42
>>1
CやRubyより覚える事少ないと思うんだが。。。


14 :デフォルトの名無しさん:2011/11/09(水) 18:01:16.24
というか>>1は関数型言語を知ってる側の人間だろう

15 :デフォルトの名無しさん:2011/11/09(水) 18:06:08.13
>>12,14

>>1は典型的なハスケラ症の患者

>366 名前: デフォルトの名無しさん Mail: sage 投稿日: 2011/10/26(水) 12:25:43.06
>>>365
>それはハスケラ特有の症例で、心の病の一つ
>
>ハスケルという言語を使っていると、世の中のあらゆる事柄すべてが
>ハスケルを中心に廻っているように見えるらしい
>従って、あらゆる関数型言語は静的実行かつ静的型付けでなければならないし、
>遅延評価が常識であり、一切の副作用は認めようとしない
>
>ハスケラにとって関数型言語とはハスケルのことであり、
>その窓から見える世界が彼らのすべて

誤:【アンチ】関数型言語は使えない【玩具】
正:【アンチ】ハスケルは使いものにならない【玩具】

16 :デフォルトの名無しさん:2011/11/09(水) 18:18:50.26
代数の基礎を一応は学んでいる理工系の人なら自然だと思うが
プログラム書くのはそういう人達だけじゃないからな

17 :デフォルトの名無しさん:2011/11/09(水) 18:25:43.24
OCamlだけは認める。

18 :デフォルトの名無しさん:2011/11/10(木) 04:51:27.64
>>16
一次関数二次関数習ってれば、十分覚えられるだろ


19 :デフォルトの名無しさん:2011/11/10(木) 11:31:32.54
感情的な毛嫌いをするような人たちに彼らの能力の対極
にある言語を使えるわけがないわな。


20 :デフォルトの名無しさん:2011/11/10(木) 11:54:04.26
>>13
学習コストと暗記量は比例しない。
覚えることが少なくても
使いこなすのが難しければ
学習コストは高い。


21 :デフォルトの名無しさん:2011/11/10(木) 12:04:22.15
かつてのプリントごっこで出来る事はプリントごっこでやればいいし、印刷機必須のものをプリントごっこでやろうとすると悲惨なことになるのと同様。

22 :デフォルトの名無しさん:2011/11/10(木) 13:21:47.56
>>20
使いこなす事も簡単だと思うけど。。。。
自分、yesコマンドとか、haskellでは作れても、Cやrubyで書けへんねん


23 :デフォルトの名無しさん:2011/11/10(木) 13:22:34.25
>>22
せやな

24 :デフォルトの名無しさん:2011/11/10(木) 16:37:17.80
>>20
それを言っちゃ。。。。


お里が知れる。

25 :デフォルトの名無しさん:2011/11/10(木) 22:18:12.24
>>22
無限ループ内でひたすらyes\n出力してフラッシュじゃだめなん?

26 :デフォルトの名無しさん:2011/11/10(木) 22:26:04.37
ruby -e"begin; loop{puts ARGV[0] || 'y'}; rescue Interrupt; puts; exit 0; end"

こんな感じ? 恥ずかしながらyesコマンドって初めて知った

27 :デフォルトの名無しさん:2011/11/10(木) 22:30:08.56
まあ、シェルスクリプトですら滅多に使わないからなあ

28 :デフォルトの名無しさん:2011/11/10(木) 23:02:36.21
>>25
ごめん。
たぶん、作れる。
作り方もそれで合ってると思う。

確実に作れないのはクイックソートをCでは作れないなw
配列でってだけで、どうすれば良いのか分からんw
昔、Cのクイックソート読んだけど、全然何やってるのか分からんかったwww

>>26
Haskellの入門書(日本人の書いた「入門Haskell」の方)に乗ってて、ちょっと前に、コマンドライン版じゃんけんゲームのテスト用に思い出しながら書いた
じゃんけんゲームは別にCでもRubyでも書けるんだけどね…



29 :デフォルトの名無しさん:2011/11/12(土) 15:55:12.09
>>24
別に間違ったことは言ってないだろ。
Common LispのほうがSchemeより使いやすいと感じる。
Schemeは覚えることは少ないが、理論に走りすぎ、
ミニマム主義が度を越していて、再帰を強要しすぎで、
実用性ではCommon Lispより劣る。
Common Lispは関数型のような手続き型だと言えなくもないが、
あれくらい節操が無くて何でもありのほうが
過剰にテクを要求されないので書きやすい。

30 :デフォルトの名無しさん:2011/11/12(土) 16:52:47.34
ハスケルって学校の実習でしか使われてないんでしょ?

31 :デフォルトの名無しさん:2011/11/12(土) 17:43:17.92
>関数型が使えないのは頭が悪いからだというのは、まぁある程度正しい。
>だったら頭の良い人が自己満足で使っていればよいのであって、
そのロジックなら「頭の良い」人が集まる会社は関数型を使うべきだよね
個人的には、その意味で「頭の良い」人はプログラマ人口の50%を超えると思う

32 :デフォルトの名無しさん:2011/11/12(土) 18:00:45.24
>>31
> そのロジックなら「頭の良い」人が集まる会社は関数型を使うべきだよね

え?その論理能力で関数型分かってるとか自称するの?
対偶を取っても、「頭の良い人は関数型を使える」であって、「使うべきだ」にはならんぜ?

33 : [―{}@{}@{}-] デフォルトの名無しさん:2011/11/12(土) 18:06:35.76
>>32
書いてからそれ思った
言い訳をすると、使えるなら使う方が良いというのは
「だったら〜使っていればよい」から読み取れないこともないよね

34 :デフォルトの名無しさん:2011/11/12(土) 18:11:47.45
>>33
色々な言語や環境を使ってみて自分で評価するのは大事なことだよね。
でも、「使うべき」という言葉からは、微妙に排他的なニュアンスを感じなくもない。

昔のオブジェクト指向もそうだったけど、これから盛り上がろうという言語や環境は
得てして独善的になったり排他的、攻撃的になったりしがちだから、
気をつけたほうがいいかもね。

35 : [―{}@{}@{}-] デフォルトの名無しさん:2011/11/12(土) 18:15:01.91
>>34
俺自身が「使うべき」と主張してる訳じゃないからな、一応言っておくと

36 :デフォルトの名無しさん:2011/11/12(土) 18:21:45.24
>>35
あ、すまん、勘違いしてた。吊ってくるわ。

37 :デフォルトの名無しさん:2011/11/12(土) 18:24:11.18
>>34

誤った用法:
>これから盛り上がろうという言語や環境は
>得てして独善的になったり排他的、攻撃的になったりしがちだから、

正しい用法:
>ハスケラは
>得てして独善的になったり排他的、攻撃的になったりしがちだから、

38 :デフォルトの名無しさん:2011/11/12(土) 18:28:39.88
それは「正しさ」をウリにしているパラダイムの宿命かもなw

ただし、Haskellのコードが本当に正しいのかは疑問が残る。
証明うんぬんとか言うが、全てのコードが正しさを証明されているわけじゃあるまい。
ましてや、仕様自体の無矛盾性まで証明されているわけでもあるまい。

39 :デフォルトの名無しさん:2011/11/12(土) 18:50:51.29
http://d.hatena.ne.jp/morchin/20110614/p1

[一般] なぜ関数型言語は普及しないか - プログラミング日記

言語を利用するための条件は以下の3つになると思う。つまり、言語が普及するための条件とも考えられる。

* 使用するための必要条件を満たしているか
* その言語を使用するメリットがあるか
* デメリットはないか

40 :デフォルトの名無しさん:2011/11/12(土) 21:24:20.76
いわゆる関数型っていうより宣言型の趣きが強い言語はキツイ

41 :デフォルトの名無しさん:2011/11/12(土) 22:27:12.33
関数型はコードが美しいけど、オブジェク指向は構造が美しい。

ツールでUML生成してニヤニヤするのがいいんじゃないか

42 :デフォルトの名無しさん:2011/11/12(土) 22:46:00.02
UMLってなんかおっさん臭い印象がある。

43 :デフォルトの名無しさん:2011/11/13(日) 05:32:45.92
Haskellを実プロジェクトに使うのは現状無理だな
メモリ消費が予測不能すぎ
ML系のほうが扱いやすいよ

44 :デフォルトの名無しさん:2011/11/13(日) 21:02:35.86
金融周りのツールで使われてるイメージ。あとはtwitter。
ってか、関数型のメリットってオブジェクトを持たない(状態を持たない)から
変数周りでバグが出にくいってメリットがあるんじゃないの?
後は型推論とか可読性とか
javaが読み辛いすぎるだけの気もするけれど

45 :デフォルトの名無しさん:2011/11/13(日) 22:11:33.57
関数型言語ってそもそも入出力どうしてんの
DB操作とかどうすんの

46 :デフォルトの名無しさん:2011/11/13(日) 22:14:19.99
関数型言語で tail -f って書けるの?

47 :デフォルトの名無しさん:2011/11/13(日) 22:32:08.95
Hello, worldができるんだから同じ要領であらゆる入出力ができるし、Cも呼べる

48 :デフォルトの名無しさん:2011/11/13(日) 22:33:33.26
>>47
君がstatもselectもepollも使ったことがないのは分かった

49 :デフォルトの名無しさん:2011/11/13(日) 22:38:06.81
は?
もしかしてC関数にポインタを渡せるかを心配してるの?
HaskellやOCamlなら当然できるよ

50 :デフォルトの名無しさん:2011/11/13(日) 23:07:00.75
>>45
http://www.nslabs.jp/haskell-rdbms.rhtml

>>46
キャッシュにしか残ってなかった
http://webcache.googleusercontent.com/search?q=cache:qYwvNDCRuyEJ:ja.doukaku.org/195/nested/+haskell+%26%26+unix%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89+%26%26+%22tail+-f%22&cd=1&hl=ja&ct=clnk&gl=jp

自分が書いたじゃんけんプログラム見ればわかりやすいと思うけど、31行より前は関数的、後は手続的に書かれてる
http://codepad.org/9mTpxBrA

一方で、自分が書いた独自自然数(と、それで計算するための関数・演算子は、すごく簡単に書ける
http://codepad.org/0WvSpM7o

手続的な処理が特に苦手と言うわけでもない
手続的な処理は、手続型言語と大差ないってだけ


51 :デフォルトの名無しさん:2011/11/14(月) 00:17:41.49
>>46
てきとーに書いたら手続き型っぽいコードになった

let rec tail_f filename where =
  let c_in = open_in filename in
  let size = (Unix.fstat (Unix.descr_of_in_channel c_in)).Unix.st_size in
    seek_in c_in where;
    Stream.iter print_char (Stream.of_channel c_in);
    flush stdout;
    close_in c_in;
    Unix.sleep 1;
    tail_f filename size
let tail_f filename = tail_f filename 0
let _ = tail_f "foo.txt"

52 :デフォルトの名無しさん:2011/11/14(月) 00:37:33.17
>>51
せめてfilenameじゃなくてc_inを渡す感じにすりゃいいのに。毎回opencloseする意味ないし、selectで待機できるだろ

53 :デフォルトの名無しさん:2011/11/14(月) 00:38:48.61
「関数型言語で手続き型言語っぽい記述もできる」
「手続き型言語で関数型言語っぽい記述もできる」の両方が真なら、
本質的な違いは制約の多さだけだな。

54 :デフォルトの名無しさん:2011/11/14(月) 00:42:35.64
手間掛ければまあ何でも出来る
細部が重要だ
破壊的代入のたびに一々 := だの ! だの書く気にならなんよ


55 :デフォルトの名無しさん:2011/11/14(月) 00:57:02.17
>>53
どうしてこんなキーワードがあるの?
http://d.hatena.ne.jp/kazu-yamamoto/20080904/1220495854

より、引用を抜粋(ややこしいw)

ちゃぶ台をひっくり返すようなまとめ

「なぜ Haskell は重要か」の一部を翻訳して、この記事のまとめとします。

(関数型言語と)同じ程度とは言えないが、命令を並べる方式でも抽象化していくとこはできる。
命令型言語では、新しいキーワードと標準ライブラリを導入することで抽象化する。
たとえば、多くの命令型言語は、プログラマーがループを実現する仕事から解放されるように、少しずつ動作が異なる複数のキーワードを用意している。
しかし、命令型言語は、命令を並べる方式に基づいているため、そこから完全に逃れることはできない。
命令型言語では、命令の並びに対し、抽象化のレベルを上げる唯一の方法は、さらなるキーワードや標準関数の導入である。
そして、言語はゴチャゴチャになる。


引用を抜粋、終わりw

まさに、OOPの事だな。

http://codepad.org/0WvSpM7o
のコードでは、dataと、deriving (Eq,Ord,Show,Read)、あと|(OR演算子だったり、ガードだったり)以外は、言語としてのキーワードは使ってない。(機能としては、パターンマッチも使ってるけど)
そのまま、数学の定義を持ってきてるだけ

手続型言語だと、キーワードはこんなに少なくできない


56 :デフォルトの名無しさん:2011/11/14(月) 00:58:09.83
あ、==もか
まあ、キーワード少ないのは変わらないか

57 :デフォルトの名無しさん:2011/11/14(月) 01:02:12.12
>>55
制御構文がムダに多いのは自然言語もそうだし、別に問題ないだろ。

制御構文が異常に多くなって呪文みたいになった言語なんてPerlくらいしか知らんよ。

58 :デフォルトの名無しさん:2011/11/14(月) 01:37:08.54
>>52
関数型とか関係なくselectじゃ待てんだろ

59 :デフォルトの名無しさん:2011/11/14(月) 01:38:17.26
>>57
そうは言うが、例えばRubyの入門書を読んだだけでは>>55と同じ動作のコードを書けるようにならない。
入門書では、Haskellと同じ抽象度を表現できるキーワードが揃ってない事になる。

が、このコードはプログラミングHaskellという入門書を読破もしてない自分が書いたものだ。
この差は、何だろうな。

一方で、副作用のある処理をしようとすると、HaskellでもHoogleなどで調べる回数が極端に増える。
関数型でも手続型でも、副作用がキーワードを生んでいる。とも言えるのかもしれない。


60 :デフォルトの名無しさん:2011/11/14(月) 02:03:44.72
>>58 は本当に入出力を知らないんだな…。
int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout);
最後の引数が何か分かるか?

61 :デフォルトの名無しさん:2011/11/14(月) 02:04:44.79
>>59 は TMTOWTDI とか聞いたこともなさそうだ。

62 :デフォルトの名無しさん:2011/11/14(月) 02:05:11.69
これから>>60がselectでtail -fを書くスレになりました

63 :デフォルトの名無しさん:2011/11/14(月) 02:13:05.99
>>62
GNU coreutils のsrc/tail.c が実例だ。 俺が書く必要はかけらもないな。

64 :デフォルトの名無しさん:2011/11/14(月) 02:54:24.92
selectで待機できるのはパイプやソケットやpty等であって
通常のファイルには役に立たない
(ファイルの終端に達してもファイルディスクリプタは読み取り可能として扱われるから)

65 :デフォルトの名無しさん:2011/11/14(月) 11:05:06.23
>>63
inotifyはLinux限定ですよ

66 :デフォルトの名無しさん:2011/11/14(月) 12:45:42.64
>>1 プログラマは資格もなにもいらないから能力のない奴がいっぱいいる。
言わばヤブ医者がいっぱい病院立てている状態。当然頭のわるい奴には
最新の医学なんて理解できないからいつまでも古い治療法を続けている。
そんな状態では高度な医学は流行っていないと観測される。

おれはどんなに少数派でも最新の医学を理解している医者のいる病院にいきたいな。


67 :デフォルトの名無しさん:2011/11/14(月) 12:57:52.66
じゃあその最新の医学とやらの例を挙げて欲しいな
名ばかり最新では困ります

68 :デフォルトの名無しさん:2011/11/14(月) 13:26:51.81
>>303
2chも書き込むのに資格が要らないんだが、気付いて無かったようだ。

69 :デフォルトの名無しさん:2011/11/14(月) 17:17:44.25
関数型が広まらないのは、難しいからじゃなくて
「OOP?デザインパターン?馬鹿じゃねーの?www」って雰囲気を
醸し出してるから。
そりゃ関数型言語以外のプログラマには反発されるよね。

70 :デフォルトの名無しさん:2011/11/14(月) 17:27:02.04
OOPって呼び方なんとかならないか
俺英語の感覚が染み付いてるからウープって読んじゃうわー
俺英語の感覚が染み付いてるからー

71 :デフォルトの名無しさん:2011/11/14(月) 17:51:18.58
>>69
ああ、本物のプログラマーは・・・とか、そんな感じのね
本当は、初心者でも割と簡単に複雑なプログラム組めるのにね・・・

初心者がいきなり初日にLength関数作れる言語って、Haskellに限らず、(多分)関数型言語だけだよ



72 :デフォルトの名無しさん:2011/11/14(月) 18:16:45.99
C#でも多分作れるぞ

73 :デフォルトの名無しさん:2011/11/14(月) 18:22:37.65
そんな情緒的なことで決まるか?
○○は仕事で普通に使うこれが仕事の標準の道具だ。
○○は豊富なライブラリが揃っていて環境もある。おまけに、つかいては
わんさかいる。
こんなところだろうよ。

74 :デフォルトの名無しさん:2011/11/14(月) 18:23:22.85
It is true that OOP is oops! :-)

75 :デフォルトの名無しさん:2011/11/14(月) 18:31:48.61
>>72
初心者が初日で?


76 :デフォルトの名無しさん:2011/11/14(月) 18:40:09.43
>>69

誤:関数型が広まらないのは、難しいからじゃなくて
  「OOP?デザインパターン?馬鹿じゃねーの?www」って雰囲気を
  醸し出してるから。
  そりゃ関数型言語以外のプログラマには反発されるよね。

正:ハスケルが広まらないのは、難しいからじゃなくて
  「OOP?デザインパターン?馬鹿じゃねーの?www」って雰囲気を
  醸し出してるから。
  そりゃハスケラ以外のプログラマには反発されるよね。

77 :デフォルトの名無しさん:2011/11/14(月) 19:16:50.67
手続き型スタイル
def length(x):
    n = 0
    while x != []:
        n += 1
        x = x[1:]
    return n

関数型スタイル(?)
def length(x): return reduce(lambda n,_: n + 1, [0] + x)

78 :デフォルトの名無しさん:2011/11/14(月) 19:20:20.63
そもそも、手続き型言語でリストのLengthを実装したいと思ったことがない件。

79 :デフォルトの名無しさん:2011/11/14(月) 19:30:21.82
javaでいうcollectionくらい使ったことがないの?>>78

80 :デフォルトの名無しさん:2011/11/14(月) 19:31:59.55
>>79
size()メソッドが既にあるだろう。 使うだけならなんで自分で実装する必要があるんだよ

81 :デフォルトの名無しさん:2011/11/14(月) 19:34:01.28
length xs = sum [1|_ <- xs]

def length(xs): return sum([1 for _ in xs])

カレーの圧勝だな

82 :デフォルトの名無しさん:2011/11/14(月) 19:38:40.50
関数型言語では遅延評価があるから、集合のlengthを求めるのに再帰が必要って話を

そもそも再帰しなくても標準ライブラリでデータのリストを扱う手続き型言語にもってくるから話がおかしくなる。

手続き型言語が持ってる、集合の最もシンプルなインタフェースは
Javaでいう Iterable だろうが、Javaでこれを生で扱う機会がそもそも多くないからな。

83 :デフォルトの名無しさん:2011/11/14(月) 19:50:26.83
reduceやリスト内包やsumを使ってて
再帰なんて使ってない件

84 :デフォルトの名無しさん:2011/11/14(月) 19:52:55.38
>>83
全要素のスキャンを行ってるのは同じだろうに。
組み込み演算子ならOK、って理屈は、javaなら標準ライブラリにsizeがあるってのとどう違うんだ?

85 :デフォルトの名無しさん:2011/11/14(月) 20:14:48.29
情報科学業界の知人らに
C#er なので 再帰はなるべく避けようと思います
っていったら何言われるかわからなくて怖い

86 :デフォルトの名無しさん:2011/11/14(月) 20:18:48.08
・Haskellプログラマ
lengthはあくまで一例であって、そういう機能を自分で実装する際に
どれだけ楽に書けるかに注目している。

・Javaプログラマ
標準ライブラリにsizeがある、で思考停止。
基本的にライブラリの機能を呼び出す事しか考えないドカタ気質。

87 :デフォルトの名無しさん:2011/11/14(月) 20:21:32.70
c#はx86とx64,DebugビルドとReleaseビルドで末尾最適化の有無が変わる恐ろしい世界

88 :デフォルトの名無しさん:2011/11/14(月) 20:22:02.96
>>86
よく分からんけど車輪の再発明が好きなの?

89 :デフォルトの名無しさん:2011/11/14(月) 20:22:52.84
lengthって例が適切ではないのを棚に上げて

90 :デフォルトの名無しさん:2011/11/14(月) 20:23:43.46
>>88
ライブラリに無い機能があったらどうする?という当然の可能性を考慮できないのがドカタ。

91 :デフォルトの名無しさん:2011/11/14(月) 20:29:18.41
前にどこかのスレで見た、下のコードのJava版は冗長すぎて笑ったwww

pyths n = [(x,y,z) | x <- [1..n], y<-[1..n], z<-[1..n], x^2+y^2 == z^2]

92 :デフォルトの名無しさん:2011/11/14(月) 20:34:02.47
こういう対立は収束するまで関わりたくないので
vimとかemacs とかいじってます

93 :デフォルトの名無しさん:2011/11/14(月) 20:40:42.37
>>91
楽しい言語スレだね
書き出しは私
他の言語だとどうなん?って聞いたらScalaやOCaml、Python、Javaが出た
Rubyが真っ先に来ると思ってたけど、結局来なかった


94 :デフォルトの名無しさん:2011/11/14(月) 20:42:49.64
Rubyプログラマは勝てる(短く書ける)勝負にしか参戦しないよ
護身完成してるから

95 :デフォルトの名無しさん:2011/11/14(月) 20:50:16.73
関数型は関数向きのコード書けると気持ちいいよね

96 :デフォルトの名無しさん:2011/11/14(月) 23:50:49.66
>>86
int[] array = new int[100];

配列というのは当然、領域を確保する時にサイズを指定するわけです。
array.size() というものがなければ、どうやってサイズを取得するのでしょうか。

int getSize(int[] array) {
...
}

この関数を再帰でもループでも、size() を使わずにどうやって書きますか?
教えてください。


97 :デフォルトの名無しさん:2011/11/15(火) 00:01:09.69
int[] array = new int[100];
int n = 0;
for (int i: array) n++;

98 :デフォルトの名無しさん:2011/11/15(火) 00:01:33.82
その for の停止条件に size が使われています。

99 :デフォルトの名無しさん:2011/11/15(火) 00:02:51.07
つまり、>>97 はこれと等価です。

int n = 0;
for (int i = 0; i < array.size(); i++) n++;

100 :デフォルトの名無しさん:2011/11/15(火) 00:07:21.91
リストの size を再帰で書けるのは、最後に nil で止まるからですよね。
nil と cons cell がリストというデータ構造を定める基本要素です。
同様に、先頭番地と要素数が配列というデータ構造を定める基本要素です。


101 :デフォルトの名無しさん:2011/11/15(火) 00:13:35.34
>>98
証拠は?使われていますと言われても納得できない

102 :デフォルトの名無しさん:2011/11/15(火) 00:14:58.67
AbstractList$Itr.class

public boolean hasNext() {
return cursor != size();
}


103 :デフォルトの名無しさん:2011/11/15(火) 00:16:37.07
おみそれいたしました。

104 :デフォルトの名無しさん:2011/11/15(火) 02:02:35.82
>>96
関数型言語のは配列でもリストでもなく、要素の「集合」で、要素数は遅延評価になってる部分集合を評価して解決しないと判明しない。

手続き型言語のデータコンテナと比較するのがそもそも間違い。

105 :デフォルトの名無しさん:2011/11/15(火) 02:43:21.25
>>104
横からツッコミを入れるけど、自分の知っている「集合」の定義とは、
・互いの要素は重複しない
・要素間に順序は存在しない
というもの

>>104の言う関数型言語では、(リストではなくて)集合を直に表現できるの?
自分の知っている関数型言語(ML, Haskell)では、集合はライブラリとして実装されている
少なくとも、>>77,81,91 のコードは(集合ではなくて)リストだよ
もしよろしければ、その(集合を扱える)関数型言語の名前を教えてくれ

106 :デフォルトの名無しさん:2011/11/15(火) 03:03:42.40
重複可集合で要素数を明示的に持ってないってなんのメリットがあるの?

107 :デフォルトの名無しさん:2011/11/15(火) 03:50:05.92
無限を表現できるというメリットがある

このメリットは重複の可否や順序の有無に依存しない(無限リスト, 無限配列, 無限集合など)

108 :デフォルトの名無しさん:2011/11/15(火) 05:14:02.76
>>55
OOPはキーワードを少なくできないって?
HaskellやML系よりSmalltalkのほうがキーワード数はずっと少ないよ。

関数型言語の人達がOOPを腐すときには大抵、OOPへの理解の浅さが見え隠れする。
これって、OOPの人達に迷惑なだけでなく、関数型言語の人達にとってもマイナスだよ。

109 :デフォルトの名無しさん:2011/11/15(火) 05:19:01.30
>>71
> 初心者がいきなり初日にLength関数作れる言語って、Haskellに限らず、(多分)関数型言語だけだよ

そういう態度が反発を食っているということに気付かないのかなあ?
その論理でいうなら、初心者がいきなり初日にDriveACarを書けるのはLOGO系だけだよ。
でもそんなの当たり前だろ。その言語のパラダイムにドンピシャな例題出したって、恥ずかしいだけ。

110 :デフォルトの名無しさん:2011/11/15(火) 05:25:51.29
>>91
効率悪いね。マトモなプログラマならMichener&Bresenham使うでしょ。
関数型言語の人って、O(n^2)のアルゴリズムがあるのにO(n^3)のアルゴリズムを平気で使うの?

111 :デフォルトの名無しさん:2011/11/15(火) 05:29:54.34
リストが得意なのはわかったから、同じ方法でリングバッファを実装してみてくれ。
初日でリングバッファの実装できるかな?
Smalltalkでは初日の初心者にも簡単に実装できたぞ。

112 :デフォルトの名無しさん:2011/11/15(火) 05:53:56.66
>>111
恥ずかしながら、マージソートがどういう動きするのか分からなくて、アルゴリズムの本で期待される動きを見てからHaskellで実装できるという低レベルさなんだが・・・
リングバッファと言うのも、同じく知らない。
どういう動きを期待されてるものなの?


113 :デフォルトの名無しさん:2011/11/15(火) 05:56:30.97
>>110
すまんね
マジで初心者なんで、まんま直感的に書いただけ。
効率的なアルゴリズムがあるなら教えて下しあ


114 :デフォルトの名無しさん:2011/11/15(火) 06:41:25.48
>>110
関数型言語の人は1から順に指を折って数えないと、数字すら理解できないんだよ

115 :デフォルトの名無しさん:2011/11/15(火) 06:43:32.95
ちなみに言うまでもないことだが、大半のコンピュータはビットベクタの並びをを数値として解釈するのとは大きく異なっている。

116 :デフォルトの名無しさん:2011/11/15(火) 06:43:55.15
× 大半のコンピュータは
○ 大半のコンピュータが

117 :デフォルトの名無しさん:2011/11/15(火) 10:16:09.12
>>113
let pyths n = [(a*a-b*b, 2*a*b, a*a+b*b) | a <- 1--n; b <- 1--(a-1)]

118 :デフォルトの名無しさん:2011/11/15(火) 11:29:59.93
>>107
大きさ不定を表す場合は
size = -1を あてればいいじゃん
全要素対象の演算でループ回数を予測できなきゃ最適化できへんやろ

119 :デフォルトの名無しさん:2011/11/15(火) 11:30:34.93
>>110
ドヤ顔してるところ申し訳ないんだけど、そのアルゴリズムは
ピタゴラス数を求めるアルゴリズムじゃないんだ……
だから x^2 + y^2 = z^2 を満たさない解も出すんだよ……
馬鹿な君には難しい話かもしれないけど……

http://en.wikipedia.org/wiki/Midpoint_circle_algorithm
http://dencha.ojaru.jp/programs_07/pg_graphic_09a1.html

120 :デフォルトの名無しさん:2011/11/15(火) 13:00:55.81
リファクタリングって関数型やってたら昔からあるふつうのコトだよね。

最初はラフにスケッチを作って、綿密に作品にしていく作業ということを
グレアムが言ってるけど、そうゆう作り方は関数型じゃ普通だもんな。

十年以上も前のことを追いついて騒いでるだけって見えるよ。

121 :デフォルトの名無しさん:2011/11/15(火) 15:29:19.66
>>119
お前、真性のおばか?
乱択アルゴリズムとか使ったことないの?

ダメだこりゃw

122 :デフォルトの名無しさん:2011/11/15(火) 15:30:48.34
>>120
> 最初はラフにスケッチを作って、綿密に作品にしていく作業ということを

君はこれをリファクタリングと呼ぶのか。
たぶん、君は一生関数型だけを使っていたほうがいいよ。
たのむから他の言語は使わないでくれ。尻拭いする側の身にもなってみろw

123 :デフォルトの名無しさん:2011/11/15(火) 18:58:03.23
うーん。。。
自分は、初心者じゃないプログラマがhaskell覚えれば、すごいものを簡単に作れるんじゃないかと期待してるんだが。。。


124 :デフォルトの名無しさん:2011/11/15(火) 19:15:14.11
いま簡単な回路のシミュレータ作ろうかと思ってるんだけど
haskell だと簡単?

組み合わせ回路、順序回路、配線それぞれに整数遅延を自由に設計でき
コンストラクタで回路要素を一個10文字程度で定義
ワイヤードORはアリっていう仕様

125 :デフォルトの名無しさん:2011/11/15(火) 19:21:28.56
>>124
>組み合わせ回路、順序回路

「プログラミングHaskell」に演習レベルのがあるね。

126 :デフォルトの名無しさん:2011/11/15(火) 19:37:03.66
>>121
その方法はこれより速いの?
ちょっと書いてみてよ。このくらいなら簡単でしょ?

let rec range x y step = if x > y then [] else x :: range (x + step) y step
let pyths n = [(a*a-b*b, 2*a*b, a*a+b*b) |
                a <- range 1 n 1;
                b <- range ((a mod 2)+1) (a-1) 2]

let pyths_all n m =
  let xs = [(k*x,k*y,k*z) | (x,y,z) <- pyths n; k <- 1--m] in
    xs @ [(y,x,z)| (x,y,z) <- xs]

127 :デフォルトの名無しさん:2011/11/15(火) 19:45:15.92
元コードが遅いことを認めたわけね。はい、ご苦労さんw

128 :デフォルトの名無しさん:2011/11/15(火) 19:48:56.98
>>127
いや、元コード書いたの俺じゃねーし
で、ちょっとコード書いてみてよ
まさかFizzBuzzレベルのコードが書けないわけでもないんだろ?

129 :デフォルトの名無しさん:2011/11/15(火) 19:52:48.96
ふーん、Michener&Bresenhamでググッてみた?

130 :デフォルトの名無しさん:2011/11/15(火) 19:55:08.72
色々バリエーションはあるが、ここが一番簡潔で読みやすいね
http://en.wikipedia.org/wiki/Midpoint_circle_algorithm

131 :デフォルトの名無しさん:2011/11/15(火) 19:57:15.75
まさかコード書けないレベルの人間がこのスレに居るとは……

132 :デフォルトの名無しさん:2011/11/15(火) 20:02:36.94
一応参考までに
http://openfmi.net/snippet/detail.php?type=snippet&id=8

133 :デフォルトの名無しさん:2011/11/15(火) 20:41:19.49
>>127
よく見ろw
HaskellじゃなくてOCamlだw


134 :デフォルトの名無しさん:2011/11/15(火) 21:52:27.59
>>125
関数はMLしかわかりませんが...

回路一個=関数一個として
遅延がある時点で
任意の関数fは遅延Dfの数だけd * d通りの状態を持つ
ことと等価でないといけないはずですが(3入力ならd*d*d)
純粋な関数型じゃイメージしにくいです

(でないと順序回路や入力の変化に対応できないはずです)


135 :デフォルトの名無しさん:2011/11/15(火) 22:13:39.02
Haskell で web application を書いた経験のある方いますか?
とっかかりとして、apache module はあるのでしょうか。
mod_haskell は 0.1 だそうですが、これは安定しているでしょうか。


136 :デフォルトの名無しさん:2011/11/15(火) 22:25:37.40
>>134
SMLでよければ、Programing in Standard ML に3ページほどの解説があるよ。
 http://www.cs.cmu.edu/~rwh/introsml/
高階関数と無限リスト(シーケンス)を応用した純粋な関数型プログラムで、
副作用は一切使われていない。コードはこんな感じ。

fun RS ff (S : wire, R : wire) =
 let
  fun X n = nor gate (zip (S, Y))(n)
  and Y n = nor gate (zip (X, R))(n)
 in
  Y
end

137 :デフォルトの名無しさん:2011/11/16(水) 02:23:43.52
回路シミュレーションならSICPの3章を見てみればいい。コツはわかる

138 :デフォルトの名無しさん:2011/11/17(木) 17:23:01.92
関数型言語が強力で、大きな可能性を秘めているのは誰でも認める。
しかし、その割には衆人に受け入れられないし、
強力にアピールするようなものが生まれてこない。

関数型言語は簡単だと主張する人は、嘘を言ってるつもりはないだろう。
しかし、難しいと感じる人が実際に大勢いて、実際に社会で活用される機会を比較すれば
明らかに見劣りしているという現実は受け容れるべきだ。

全部S式で考えるから簡単だという意見も時々耳にするが、これは論外。
人間の自然な思考は手続型であり、それをS式思考に転換ことに成功すれば簡単だろうが
実際にその転換に成功する人は多くない。
だからこそ、広く受け容れられるに至っていないのだから。

139 :デフォルトの名無しさん:2011/11/17(木) 17:52:23.56
仕方ないさ。違ったパラダイムのものを触るのは知らない時より
コストがかかるんだから。純真無垢の何もしたことがない人と
手続きの育った人を比べると、素直な髪の毛と
寝ぐせがついた髪の毛をセットするときの違いのようなものさ。
要は、わからないようになった人って多くは寝癖。その寝ぐせが
作るときの中心になってんだから、保守的になるのは普通だよ。
squeak界隈でも、プログラマより子供のほうが理解が速いという事は
あるらしいからね。
難しいと嘆くより、頭が硬くなって(あなたにとって)目新しいもの
を否定する頭の硬さに老化の兆しを感じて嘆いたほうがいいと思うな。

140 :デフォルトの名無しさん:2011/11/17(木) 18:13:02.91
F# がはやったら本気出す

141 :デフォルトの名無しさん:2011/11/17(木) 18:50:12.08
手続き型言語が関数型言語を参考にし始めてる事の説明になってないので15点。

142 :デフォルトの名無しさん:2011/11/17(木) 19:24:59.03
ちょっと取り入れるくらいがちょうど良い

143 :デフォルトの名無しさん:2011/11/17(木) 19:30:09.12
>>141
関数型の良いとこ取りをしつつ、関数型の悪いところを無視してるってこと
良いとこさえ真似れば関数型そのものは用済み

144 :デフォルトの名無しさん:2011/11/17(木) 19:55:59.63
CTMCPを知ってて言ってるんなら10点だな。

145 :デフォルトの名無しさん:2011/11/17(木) 20:16:40.16
>>144
関数型はそーゆーのを知ってる人のための言語なのか
象牙の塔専用言語ということが証明されたね

146 :デフォルトの名無しさん:2011/11/17(木) 21:38:15.43
#!/bin/sh
# the next line restarts using tclsh \
exec tclsh "$0" "$@"

proc mylength {x} {
length2 $x 0
}

proc length2 {x c} {
if {$x == {}} {
return $c
} else {
length2 [lreplace $x 0 0] [incr c]
}
}

puts [mylength {1 2 3 4}]

147 :146:2011/11/17(木) 21:50:49.11
;length by Scheme
(define (mylength x)
(length2 x 0))

(define (length2 x c)
(if (null? x)
c
(length2 (cdr x) (+ c 1))))

;Schemeで書けばこうなる
;関数型は得意なことならスッキリ書ける
;関数型だから関数型らしいものだけ書けば無敵
;普通のプログラマは簡単に窓を表示できたり、
;テキスト処理に便利な関数や強力な正規表現が用意された言語を使えばいい

148 :デフォルトの名無しさん:2011/11/17(木) 21:54:42.44
tclって末尾再帰最適化されるんだっけ?と思ったら
schemeと比べるために末尾再帰にしたのか

149 :デフォルトの名無しさん:2011/11/17(木) 22:37:32.77
代数DT, パターンマッチ, 高階関数、部分適用、オフサイドルール(任意)
をそなえた手続き言語欲しい

150 :デフォルトの名無しさん:2011/11/17(木) 23:04:02.07
>>144
http://hibari.2ch.net/test/read.cgi/tech/1196257692/
でも技術を磨こうとしたら、勉強したほうがいいよ。
>>149
関数オブジェクトや関数ポインタがあればある程度は高階関数の代用は
できそうなんだけどね。手続きがどれもこれもpascal/cの子供ばかりだから
毛並みの違う手続きも現れても良さそうなのにね。

151 :デフォルトの名無しさん:2011/11/17(木) 23:04:38.09
>>144 じゃなく>>145宛でした。

152 :デフォルトの名無しさん:2011/11/17(木) 23:21:28.94
にしてもCTMCPをやってる人って少ないよね。(ネットでは)
一部の読んだ人って大学の輪講とかで使ってんのかな。

153 :デフォルトの名無しさん:2011/11/17(木) 23:43:34.95
CTMCP程度で挫折してたらこの先厳しいだろ。

154 :デフォルトの名無しさん:2011/11/17(木) 23:49:37.01
インドから来てた短期研修生は知ってたな。
DB構築なんかも初めてのパッケージだとか言いながら、ネットで(勿論英語サイトを)調べながらちゃっちゃと組んでたw

155 :デフォルトの名無しさん:2011/11/17(木) 23:58:14.99
>>152
複数のプログラミング言語を使った後に読んだが、計算モデルの意味が解って、その言語に適したコーティングをやり易くなった。

156 :デフォルトの名無しさん:2011/11/18(金) 00:13:05.80
>>155
なるほど、僕も複数の言語使ってるけど、参考になります。その言語
言語で適した書き方あるもんね。

157 :デフォルトの名無しさん:2011/11/18(金) 04:11:37.15
関数型言語って役に立つな。
スイスの海軍並に役に立つな。

158 :デフォルトの名無しさん:2011/11/18(金) 08:59:35.09
>>149
つ Oz

159 :デフォルトの名無しさん:2011/11/18(金) 09:12:59.88
>>155
適した書き方、もあるが
解決したい問題→どの問題領域か?→どの計算モデルが適しているか?→どの言語が適しているか?
の見極めが早くなるので、読んどいた方が後々楽。
勿論、「最適言語」にも幅があるので、効果/追加リソースが大きいのを選ぶことになる。

160 :デフォルトの名無しさん:2011/11/18(金) 13:34:00.62
でも、それは問題解決というパラダイムに縛られた考え方。
プログラミングは問題解決型の領域だけじゃないぜ?

161 :デフォルトの名無しさん:2011/11/18(金) 13:53:38.26
低スキルでもどの言語でも大差なく扱える問題は、自分の慣れた言語でやれば良い話だな。
世間の仕事の9割以上はそういった、単純な事務処理だから別に問題ではない。
その手の仕事だけやる分には、このスレに書きこむ必要もないだろう。

162 :デフォルトの名無しさん:2011/11/18(金) 13:59:30.67
>>161
一兵卒の意見だな


163 :デフォルトの名無しさん:2011/11/18(金) 14:33:56.69
面白いよな。
問題解決領域を見極めた方法がわかりやすい本だよ
といえば、
問題解決のパラダイムに囚われた考え方。そんなんだけじゃないぜ?

どの問題でも大差なく扱える問題は自分でなれた言語でやれば良い話。

>>159のサジェスチョンを全く理解してないってことだと思う。

164 :デフォルトの名無しさん:2011/11/18(金) 17:49:54.58
>>163
問題解決パラダイムに染まりきってるね。
問題解決以外はどの言語でも大して変わらんとか、分かりやすいドカタ思考だ。

165 :デフォルトの名無しさん:2011/11/18(金) 18:06:24.27
>>164
うーん。。。 この人って 問題解決パラダイムのこと書いてたら、
それしか頭にないと思う人だろうか?お気の毒な頭脳をお持ちなのね。

166 :デフォルトの名無しさん:2011/11/18(金) 18:07:42.85
そもそも
>>159-161のながれを...

167 :デフォルトの名無しさん:2011/11/18(金) 21:41:13.95
え?

168 :デフォルトの名無しさん:2011/11/18(金) 22:12:35.82
>>165
一連の書き込みを、自分ともう一人だけがしてると思ってんじゃないかな?

169 :デフォルトの名無しさん:2011/11/19(土) 04:49:42.63
おかしいのは>>163だけで、>>159は真っ当だなw

170 :デフォルトの名無しさん:2011/11/19(土) 10:48:46.88
>>169やっぱりお気の毒な頭脳だろう。
丁寧に書くと>>163>>161,162の皮肉だって。 なんで流れを読まないんだろう。


171 :デフォルトの名無しさん:2011/11/19(土) 10:50:37.86
>>170
日本語お上手ですねw

172 :デフォルトの名無しさん:2011/11/19(土) 12:35:11.07
>>93
Rubyで書いてみたいな…けどHaskellわかんないんだ
JavaとPythonなら分かるんだけど、どんなコードだったの?

173 :デフォルトの名無しさん:2011/11/19(土) 18:15:42.25
久しぶりに社会に出たらC#が流行ってたのでやらされた。
C#にはnullとかいうのがあるらしい。
クソめんどうくさかった。

174 :デフォルトの名無しさん:2011/11/19(土) 20:37:19.00
>>172
public static List<Integer[]> pyths (int n) {
List<Integer[]> list = new ArrayList<Integer[]>();
for (int x = 1; x <= n; x++) {
for (int y = 1; y <= n; y++) {
for (int z = 1; z <= n; z++) {
if (x * x + y * y == z * z) {
list.add(new Integer[] {x, y, z});
}
}
}
}
return list;
}

175 :デフォルトの名無しさん:2011/11/19(土) 23:04:29.52
>>172
pyths n = [(x,t,z) | x <- [1..n], y <- [1..n], z <- [1..n], x^2 + y^2 == z^2]


176 :デフォルトの名無しさん:2011/11/20(日) 00:20:09.18
>>175
yの代わりにtが混入してる。

177 :172:2011/11/20(日) 02:00:52.12
>>174
おk把握

def pyths(n)
(1..n).flat_map{|x|(1..n).flat_map{|y|(1..n).map{|z|[x,y,z]}}}.select{|x,y,z| x**2 + y**2 == z**2 }
end

こんなもんかなあ、Rubyだと。

178 :デフォルトの名無しさん:2011/11/20(日) 02:54:00.73
これでもいい気はする。
def pyths(n)
(1..n)
.to_a
.combination(3)
.select{|x,y,z|x*x+y*y==z*z}
end

179 :172:2011/11/20(日) 02:59:41.99
…Array#combinationとか初めて知ったぜ

180 :デフォルトの名無しさん:2011/11/20(日) 06:49:14.50
>>175
>>178
haskellよりrubyの方が短いね

181 :デフォルトの名無しさん:2011/11/20(日) 19:48:27.46
なあ、そもそも俺はピタゴラス数を求めるプログラムにしか見えないんだが
結局、何を求めるプログラムなわけ?
関数型言語って人が見て何をやってるのか分からない言語じゃないのか?

182 :デフォルトの名無しさん:2011/11/20(日) 19:57:20.80
内包表記と関数型言語の関係ってどう解釈したらいいんだろうね。

183 :デフォルトの名無しさん:2011/11/20(日) 20:27:28.37
喫茶店で若いOL風の女性がCTMCP読んでて萌えた

184 :デフォルトの名無しさん:2011/11/20(日) 20:53:48.34
そこで 俺のmozartでozozしないか?と聞かないと。意味不明

185 :デフォルトの名無しさん:2011/11/20(日) 21:19:26.49
正直、174だろうが175だろうが、178だろうが
それぞれの熟練プログラマが書いたら効率は
そんなに変わらなくね?
アセンブラとかなら変わるだろうけど

違うとしたら、178が何をやってるのか理解するのに勉強が
必要だというぐらいだろ

186 :デフォルトの名無しさん:2011/11/20(日) 23:21:58.23
>>181
> 関数型言語って人が見て何をやってるのか分からない言語じゃないのか?

それは手続き型言語

187 :デフォルトの名無しさん:2011/11/21(月) 00:40:13.63
手続きは 資材を並べていく感じ
関数は 資材を加工する機械に通してる感じ。

188 :デフォルトの名無しさん:2011/11/21(月) 01:07:17.13
>>186
関数型は未だにパッと見でわからないです。

189 :デフォルトの名無しさん:2011/11/21(月) 01:08:58.40
関数型は組み合わせ
手続き型は積み重ね


190 :デフォルトの名無しさん:2011/11/21(月) 02:42:58.91
手続き型言語は古典力学
 時間の流れは一方的、開いた系で現実的

関数型言語は量子力学
 時間の流れは存在せず、閉じた系で理論的

191 :デフォルトの名無しさん:2011/11/21(月) 03:23:52.64
手続きは乱雑
関数型は整理

192 :デフォルトの名無しさん:2011/11/21(月) 07:42:39.76
手続き型は系列
関数型は羅列

193 :デフォルトの名無しさん:2011/11/21(月) 08:02:53.73
>>174
元ネタが見つからないのでわからないのですが、int しか使わない縛りとかあったのでしょうか。

List<Integer[]> list = new ArrayList<Integer[]>();
for (int x = 1; x <= 100; x++)
 for (int y = 1; y <= 100; y++) {
  double z = Math.sqrt(x * x + y * y);
   if (z <= 100 && (int) z == z) list.add(new Integer[] { x, y, (int) z });
 }


194 :デフォルトの名無しさん:2011/11/21(月) 08:26:01.80
>>193
それ、間違い。浮動小数点数の扱いに慣れてない?

195 :デフォルトの名無しさん:2011/11/21(月) 08:30:13.71
すみません、わからないので教えてください。

196 :デフォルトの名無しさん:2011/11/21(月) 08:36:50.09
なんだか、遂に、Ozまで流行りだした。

197 :デフォルトの名無しさん:2011/11/21(月) 08:46:16.00
>>196
Prologには既にブームの兆しがあるし、関数型の周辺に
猛烈な勢いで関心が拡がって、渉猟されてる感がある。


198 :デフォルトの名無しさん:2011/11/21(月) 08:48:26.52
>>34
Erlang人気は意外だった。

199 :205:2011/11/21(月) 08:50:34.60
何か壊れてる?
>>34 でなくて、>>196だね。

200 :デフォルトの名無しさん:2011/11/21(月) 09:32:35.99
>>185
理解するのに勉強が必要って…どれも必要だろう

201 :デフォルトの名無しさん:2011/11/21(月) 10:25:56.50
>>181
まんま、ピタゴラス数を求める関数でんがな
パッと見で分かってるじゃん


202 :デフォルトの名無しさん:2011/11/22(火) 02:11:23.03
>>188
当然関数型でも解りやすいのと解りにくいのがある。
Perlの変態コードだってパッと見わからんでしょ。

それに手続き型に何年親しんでから、関数型をどれくらいやったのか?
単なる慣れの要素もある

203 :デフォルトの名無しさん:2011/11/22(火) 05:13:59.50
>>200
その勉強量が違うだろ
多くの人が知らない概念を使ってる場合、
その多くの人は新たに勉強する必要がある
知ってる場合は勉強する必要はない

204 :デフォルトの名無しさん:2011/11/22(火) 12:55:21.67
>>202
関数型でわかりにくいというのはどこを指してるのか?
(reduce .. (filter .. (map .. (map ....
もなぁーど ...

基本は再帰を乗り越えなアカンっていうのはある。関数型で
バッドノウハウだと思ってるのは、末尾再帰くらいかも。

205 :デフォルトの名無しさん:2011/11/22(火) 15:35:23.14
ポイントフリーな書き方が出来るようになれば
カッコも再帰も最小限ですむよ

206 :デフォルトの名無しさん:2011/11/22(火) 16:09:47.64
>>205
ハスケルだったらね。ポイントフリーのほうが楽なこと多いよね。
あれで必要以上に複雑なことしなければ、誰だって使えるようになるでしょうよ。

207 :デフォルトの名無しさん:2011/11/22(火) 17:12:14.50
関数型が分からん奴ってunlambdaでもやってんの?

208 :デフォルトの名無しさん:2011/11/22(火) 19:41:54.44
ポイントフリーは難解

209 :デフォルトの名無しさん:2011/11/22(火) 20:10:56.45
関数型が広まらなかったのは、ハードウェアの制限のせい
64ビットOSが普及すれば、スクリプトより楽な巻子型言語が普及・・・して欲しいなぁ…
関数型言語って、基本的に簡単だけど、要求スペックも無限のメモリ、無限のクロックなんだよね・・・

通常アプリでメモリやクロック、スレッドを気にしなくてよくなったら、普及すると思うんだ



210 :デフォルトの名無しさん:2011/11/22(火) 20:11:45.59
x巻子
o関数


211 :デフォルトの名無しさん:2011/11/22(火) 20:20:11.59
追記(?)

それを解消するためのアルゴリズlムであり、末尾再帰なんだと思う


212 :デフォルトの名無しさん:2011/11/22(火) 20:30:08.07
プログラミング言語は道具に過ぎないってことを忘れてるだろ
現実を無視しちゃいかんよ

213 :デフォルトの名無しさん:2011/11/22(火) 21:00:40.61
193のどこが間違えているのか教えてください

214 :デフォルトの名無しさん:2011/11/22(火) 21:15:40.50
プログラマーか否かに関わらず、
人は手続型で思考する。
だから、先入観の無い子供でも
関数型は手続型より難しいと感じる。
S式や再帰を強調し、ほら簡単だろと言うから
関数型は嫌われてメジャーになれない。

215 :デフォルトの名無しさん:2011/11/22(火) 21:37:40.15
手続き型が自然なのは同意だが
一方数学というのは思考を簡約できる道具なわけで
手続きに関数の表現を盛り込んでいくのがいいと思う


216 :デフォルトの名無しさん:2011/11/22(火) 21:41:57.49
手続きが自然ってほんとかな? 疑問だな。

217 :デフォルトの名無しさん:2011/11/22(火) 21:48:11.68
高校数学あんまやってないプログラマのこと考えたら自明だろ

218 :デフォルトの名無しさん:2011/11/22(火) 21:57:05.12
むしろC的なメソッドを先にやってから
中?高?で関数を教えたほうがいいかもしれん

219 :デフォルトの名無しさん:2011/11/22(火) 21:59:19.13
手続きが思考に近いってのには異論はない

220 :デフォルトの名無しさん:2011/11/22(火) 23:01:53.48
末尾再帰がバッドノウハウてどういう意味?

221 :デフォルトの名無しさん:2011/11/22(火) 23:09:42.98
今日考えていたんだが、
UMLで設計するんじゃなくて、DFDで設計したらいいんだよね?

222 :デフォルトの名無しさん:2011/11/22(火) 23:23:19.23
状態がないのに自然なわけない

223 :デフォルトの名無しさん:2011/11/22(火) 23:30:49.75
関数言語の簡単さ、綺麗さって
オフサイドルールの面も大きいと思う

224 :デフォルトの名無しさん:2011/11/22(火) 23:35:06.03
中括弧言語は それだけで下品になるからなぁ。

225 :デフォルトの名無しさん:2011/11/22(火) 23:51:03.48
>>223
MLをディスってるんですか?

226 :デフォルトの名無しさん:2011/11/22(火) 23:54:47.57
>>206
ポイントフリーは読みにくい型エラーの温床になるから
あんまりやらないようにしてるんだけど

227 :デフォルトの名無しさん:2011/11/22(火) 23:55:21.01
でもHaskellって実際のコード見ると妙な演算子があちこちにいるよね
<+>とか.|.とか>>=とか

228 :デフォルトの名無しさん:2011/11/23(水) 00:24:00.14
ポイントフリーといえば、ほくろ付き巨乳とかあるね。
(.).(.)

229 :デフォルトの名無しさん:2011/11/23(水) 03:27:23.65
>227
そうそう、だいたい奇天烈演算子大会になってるよね。

で、演算子の字面見ても殆どイメージ湧かないし。
いや、別に二項演算子が嫌いなわけじゃないけど、セルフドキュメント性が低すぎる。

230 :デフォルトの名無しさん:2011/11/23(水) 05:48:44.62
>>214
でも、なぜか

x = x+1

等しくないよ?という入門者の意見の多いこと多いこと…
この段階では、関数型言語の方が自然らしい


231 :デフォルトの名無しさん:2011/11/23(水) 05:59:42.50
でも、そこで躓く入門者というのを見たことがない。
都市伝説なのではないか。

232 :デフォルトの名無しさん:2011/11/23(水) 06:46:58.39
>>227
Haskell使いの目指すところが手続的な個所も関数的に書こうとする事だからね…
そこが、ちょっと珠に傷って気はする
手続的に書く方が自然なところは手続的に書いて、関数的に書く方が自然なところは関数的に書けば良いのに、とは思うよ

関数的に書ける所では、デッドロックとか考える必要なくて、簡単に並列化できるし、手続的に書く方が自然なところは普通に手続的に書けるんだしさ


233 :デフォルトの名無しさん:2011/11/23(水) 06:51:12.91
>>230
でも「三角形のこの頂点のx座標y座標は動かせないよ」と言っても
どうして?と言われるぞ…

234 :デフォルトの名無しさん:2011/11/23(水) 06:52:20.60
>>231
居た
xとyの値を交換するってので、

temp = x
x=y
y=temp

ってするじゃない?
何でtempが必要なのか。いくら説明しても分からない奴がいた。
メモリの仕組みも習ってるはずなのに、理解できないらしい。
多分、メモリの仕組みそのものが理解できてない。

関数型言語の場合
タプルで受け取って、そのまま交換すればいい

swap (x,y) = (y,x)

これなら、そういうレベルの人でも分かるだろう。
・・・と、思いたいw


235 :デフォルトの名無しさん:2011/11/23(水) 06:54:08.09
>>233
動かす(新しい座標を返す)関数作ればいいだけだろ


236 :デフォルトの名無しさん:2011/11/23(水) 06:55:17.51
ハスケラが言う自然ってのはハスケルっぽく書けるということで、
それが日本語で普通に考えた時のやり方と全然違っていても
あくまでハスケルっぽいほうが自然なんだよ。

同じように、ハスケラが言う関数プログラミング的というのは
ハスケルっぽく書いてあるということで、MLとかLISPとかで
スマートに書いてあっても、それは関数プログラミング的じゃないんだよ。

237 :デフォルトの名無しさん:2011/11/23(水) 06:56:36.72
>>234
手続き型でもswapぐらい普通に実装できるが。
def swap(x,y):
  return y, x

238 :デフォルトの名無しさん:2011/11/23(水) 06:58:55.33
>>235
そんなので騙せるのは大人だけだよ。
新しい三角形をつくったって、元の三角形は動いてない。

239 :デフォルトの名無しさん:2011/11/23(水) 07:25:25.55
>>236
日本語とか以前として、算数/数学っぽく書けるって感じかな

数学に国境はないから、日本とか外国とか関係ない


240 :デフォルトの名無しさん:2011/11/23(水) 07:28:40.77
>>237
それを教えてない段階で疑問持たれる訳で

関数型言語は数学ベースだから、そう言う疑問を持たれにくいし、疑問への回答も論理的
(こう言う機能が有るよ!!ではない)


241 :デフォルトの名無しさん:2011/11/23(水) 07:30:44.56
>>238
それが、後から元の三角形が必要になった時の利点
(手続き型だと新しい三角形を作る前に保存してないといけない)


242 :デフォルトの名無しさん:2011/11/23(水) 07:44:58.98
>>240
教えてない?
あんたが知らないだけでしょw

関数型の人ってどこまでジコチューよww

243 :デフォルトの名無しさん:2011/11/23(水) 07:46:05.59
>>241
それじゃ子供どころか大人も騙せないぞw
それで説明できたつもりでいるようだから、関数型はダメなんだよ

244 :デフォルトの名無しさん:2011/11/23(水) 07:48:17.33
こういうスレにわざわざ議論しにくる人は、
叩く方も含めてほぼ100%関数型言語ユーザと思われ。
関数型言語の「メリット」は説明されなくても分かってるのでは。

Haskellでグラフのデータ構造を定義する上手い方法はあるのだろうか。

class Node {
Set<Node> edges;
...
};

普通のオブ指手続き言語ならこれだけの話だが。

245 :デフォルトの名無しさん:2011/11/23(水) 07:48:25.78
>>239
ハスケルじゃ関数名や変数名はつけないのか?
mapとかfoldとかfilterとかは世界共通の言葉なのか?

ハスケラのジコチューっぷりは世界共通なのか?

246 :デフォルトの名無しさん:2011/11/23(水) 08:21:07.82
>>244
俺はハスケラじゃないんで分からんけど、それってHaskellじゃ難しいの?
データ構造の定義に手続き型とか関係なさそうだが……

247 :デフォルトの名無しさん:2011/11/23(水) 08:35:38.33
>>246
edges への破壊的代入が出来ないとしたら?

248 :デフォルトの名無しさん:2011/11/23(水) 08:37:53.79
Google Trendsで現実見て来いよ

249 :デフォルトの名無しさん:2011/11/23(水) 09:52:48.08
Haskellでも破壊的代入はできるんだけどね。
デフォルトじゃできないだけで。

250 :デフォルトの名無しさん:2011/11/23(水) 11:07:12.02
正直、記号の分かりにくさはどっちもどっちじゃないかな

>>230
っ PASCAL
っ COBOL
他にも手続き型で代入演算子が = でない言語はあったと思うぞ

>>234
それも最近の言語は x,y = y,x と書けたりするからなあ

251 :デフォルトの名無しさん:2011/11/23(水) 11:46:48.72
>>234
分かるまで、ハノイの塔を実際にやらせてみるとか、どうだろうね。

252 :デフォルトの名無しさん:2011/11/23(水) 11:47:34.34
多重代入サポートしてる言語でも
y = x
x = y
と書いたらもちろん意図した結果にはならないので、なぜこう書いたらダメなのか
というのはどのみち理解しないといけないような
変数と値のセマンティックスは値型/参照型云々でも違ってくるので
初心者にとってはそう簡単じゃないのでは

エイリアシングからくる初心者にとっては不可思議な問題を
とりあえず考えなくともよいという意味では、参照透明だと確かにわかりやすいのかも

253 :デフォルトの名無しさん:2011/11/23(水) 13:05:31.01
多重代入サポートしてる言語で
y = x
x = y
と書くのは例えばどんなとき?
僕分からないんで教えて下さい。

254 :デフォルトの名無しさん:2011/11/23(水) 13:12:03.82
多重代入をサポートしてない言語なら、どんなときに書くか分かるのか???


255 :デフォルトの名無しさん:2011/11/23(水) 13:13:14.58
二行目の x = y には何の意味も無いよね〜

256 :デフォルトの名無しさん:2011/11/23(水) 13:13:58.34
>>245
え、そこから英語で躓くのかよ
変数や関数に対した英単語でないだろ


257 :デフォルトの名無しさん:2011/11/23(水) 13:16:56.56
難しい話じゃなくて

関数を書くのは関数型言語の方が楽
手続きを書くのは手続き型言語の方が楽

ってだけじゃねーの?

258 :デフォルトの名無しさん:2011/11/23(水) 13:27:23.12
デメリット側から言えば

たかが map のために functor が必要になるのと
たかが代入のために monad が必要になるのと

究極の選択。マシな方を選べ。ってだけじゃね?


259 :デフォルトの名無しさん:2011/11/23(水) 13:29:13.69
で、具体的には?

260 :デフォルトの名無しさん:2011/11/23(水) 13:29:44.44
個人的には。関数は第一級な方が当然便利。
参照透明性は要らん。言語に強制されるのは邪魔なだけ。

261 :デフォルトの名無しさん:2011/11/23(水) 13:30:55.70
なので、純粋ではない関数型言語か closure を扱える手続き型言語がいいね。


262 :デフォルトの名無しさん:2011/11/23(水) 13:32:17.07
ほうほう、君の中ではそうなんだね。よかったね。

263 :デフォルトの名無しさん:2011/11/23(水) 13:32:31.16
で、君は?

264 :デフォルトの名無しさん:2011/11/23(水) 13:33:26.59
で、君は?

265 :デフォルトの名無しさん:2011/11/23(水) 13:33:38.46
ここで逃げるのが Haskell 厨

266 :デフォルトの名無しさん:2011/11/23(水) 13:39:17.71
ほんとHaskell厨はクズだな

267 :デフォルトの名無しさん:2011/11/23(水) 13:40:57.32
これは Haskell 厨のカスさがよく分かるスレですね

268 :デフォルトの名無しさん:2011/11/23(水) 13:41:25.89
っていうか Haskell ってダッセーよな

269 :デフォルトの名無しさん:2011/11/23(水) 13:43:40.50
Haskell はOSすら書けない糞言語

270 :デフォルトの名無しさん:2011/11/23(水) 13:49:24.41
Hasmelって言語があるそうだな

271 :デフォルトの名無しさん:2011/11/23(水) 13:56:39.61
1行 連続ポスト厨が現れるとスレの質が相当低下するからな。
もうこのスレもおしまいかも。もともとフレーマー用だから
いいっか。

272 :デフォルトの名無しさん:2011/11/23(水) 13:57:50.70
なるほど、Haskell 厨はそうやって逃げるわけね

273 :デフォルトの名無しさん:2011/11/23(水) 13:58:58.14
もういいか?

参照透明性って、プログラマの責任で保証するというのでも
大した手間じゃないような気がするんだよな。
言語として副作用を持たないということは本当にメリットなのか?
デメリットの方が大きい気がする。

純粋だってのは認めるが、それは数学的な美学の問題。
プログラマの利益にならなきゃプログラミング言語としては使えないだろ。

274 :デフォルトの名無しさん:2011/11/23(水) 13:59:04.58
低下って
元々質()の低いスレで何言ってんだか
いいっか。

275 :デフォルトの名無しさん:2011/11/23(水) 13:59:32.66
もういいか?

参照透明性って、プログラマの責任で保証するというのでも
大した手間じゃないような気がするんだよな。
言語として副作用を持たないということは本当にメリットなのか?
デメリットの方が大きい気がする。

純粋だってのは認めるが、それは数学的な美学の問題。
プログラマの利益にならなきゃプログラミング言語としては使えないだろ。

276 :デフォルトの名無しさん:2011/11/23(水) 14:00:33.80
結論:Haskell はクズ

277 :デフォルトの名無しさん:2011/11/23(水) 14:38:01.16
>>220
最適化をしようと思ったら、末尾再帰でないものでも無理にでも末尾再帰
のフォームに変換しないといけないけど、それは言語の文法上の話じゃなくて
コンパイラやインタプリタより下層の制約から来てる。そこからバッドノウハウ
臭さがある。そんな制約なしにどんな再帰でも最適化されるようなものだったら
末尾再帰にこだわらなくてもいいだろうしね。

278 :デフォルトの名無しさん:2011/11/23(水) 14:46:48.58
多分、扁桃体から直接手を動かしてそうな人は関数型やってる
ほとんどの人は相手にしないんだと思う。やっぱり情動の制御
できるように前頭葉を鍛えなきゃ。頑張ってリハビリしたほうがいいよ。

279 :デフォルトの名無しさん:2011/11/23(水) 14:49:42.96
>>278
どうしよう、これ...

280 :デフォルトの名無しさん:2011/11/23(水) 15:16:18.58
>>277
逆に考えるんだ。
そもそも call を jmp に置き換えるのが末尾再帰除去であり、
末尾再帰除去の中で call が自分自身を呼び出している場合がループなのだ。

つまり、手続き型言語の連中が当たり前のように使っている
ループという制御構造それ自体がバッドノウハウなのだ。
彼らはバッドノウハウだと思っていないようだが。

281 :デフォルトの名無しさん:2011/11/23(水) 15:20:47.90
そうだね。

282 :デフォルトの名無しさん:2011/11/23(水) 15:22:29.65
自動的に末尾再帰に変換して除去してくれるのが理想の最適化コンパイラ
ーーーー壁ーーーー
プログラマが末尾再帰に書けば除去してくれるのが関数型言語
ーーーー壁ーーーー
末尾再帰を除去できない変わりに破壊的代入とループ構文を導入して
プログラマが手作業で末尾再帰除去できるようにしたのが手続き型言語


283 :デフォルトの名無しさん:2011/11/23(水) 15:28:14.17
Haskell 使うくらいなら HSP 使うはww

284 :デフォルトの名無しさん:2011/11/23(水) 15:33:50.46
それ随分と目的が違わねw

285 :デフォルトの名無しさん:2011/11/23(水) 15:36:18.41
HSPは0行でウィンドウが出せる

286 :デフォルトの名無しさん:2011/11/23(水) 16:03:18.11
>>280
おれも息を吐くが如く、末尾再帰にはお世話になってるけど、この話と
手続きのループとは話は別かな。
手続きのループに慣れ過ぎると、悪癖プログラマっぽいものしかいなくなる。
少なくともそれで関数をやるとね。せいぜいiterateにしてくれよと言いたく
なるけど、副作用の世界が絡んでるから一対一対応じゃない部分があるよね。
見た目も下品なループなんて抹殺すればいいが。藁

287 :デフォルトの名無しさん:2011/11/23(水) 16:05:25.18
万能な Ruby が最強だということが分かった
Haskell より速いし

288 :デフォルトの名無しさん:2011/11/23(水) 16:25:00.92
http://alohakun.blog7.fc2.com/blog-entry-812.html

289 :デフォルトの名無しさん:2011/11/23(水) 16:32:58.55
あ、勘違いしてた。別ではなかったな。ごめん286取り下げとく

290 :デフォルトの名無しさん:2011/11/23(水) 17:16:32.58
>>287
速い?
ghciは確かに遅いが、ghcでコンパイルした後だとLLじゃ話にならん速さだぞ?


291 :デフォルトの名無しさん:2011/11/23(水) 17:23:31.95
OCAMLはコンテストでは強いらしいが
初心者ポンと出されて
一日でどこまで作れるようになるかコンテストがあったら
手続きのほうが強そう

292 :デフォルトの名無しさん:2011/11/23(水) 17:28:20.56
どうだろう?
全くのプログラミング処女を捕まえて、教える場合と、クセのついたプログラマ
が学ぶ場合と違ってくるからな。変なクセがある分関数童貞の手続きプログラマ
のほうが、プログラミング処女より物分りが悪いってことはよくあるみたいだが。

293 :デフォルトの名無しさん:2011/11/23(水) 17:32:52.58
>>292
具体例も無しに言われても。。。


294 :デフォルトの名無しさん:2011/11/23(水) 17:36:07.39
>>292
例えば?

295 :デフォルトの名無しさん:2011/11/23(水) 17:41:50.82
OCamlは関数型だけど手続き型でもあるから
純粋指向の人達には軽く見られるけど、習得はし易い部類かと

296 :デフォルトの名無しさん:2011/11/23(水) 17:44:26.35
IO Monadって結局は副作用をランタイムに押し付けて
言語レベルでは知らんぷりしてるだけじゃん。

「臭いものに蓋」で、副作用による依存性の問題に
正面から向き合ってないよね。

297 :デフォルトの名無しさん:2011/11/23(水) 17:47:27.76
「ケンロン!ケンロン!」
「うわ、何アイツ、キモ・・・」
「ケンロン!ケンロン!」
「なんか臭いし・・・関わらないようにしようぜ」「そうね・・・」

298 :デフォルトの名無しさん:2011/11/23(水) 17:49:00.65
ハスケラみたいな排外的で独善的な奴に仕事を任せたくないよね
ハスケルで有名なプログラムって、グラディウスとかパールとか
既存のプログラムの書き直しばっかりじゃん

299 :デフォルトの名無しさん:2011/11/23(水) 17:52:27.80
Haskell 厨 「我々は高度な理論に基づいてプログラミング言語を扱っている。実装重視の土方とは違うのだよwww」

「またあんなこと言ってるけど」
「いいよ、あいつにはリストの長さを求めるプログラム書かせとくからwww」
「そりゃ大仕事だなwwww」

300 :デフォルトの名無しさん:2011/11/23(水) 17:56:20.95
>>293-294
教える経験のある人たちからはそうゆう話は時々出てくるくらい
だけど、違うと思うならそれでもいいよ。ずぶの素人より知ってるほうが
難しく感じるっていう話は、多少ショッキングだろうから。
しかしながら、この手のパターンはよくある話なんだよね。

301 :デフォルトの名無しさん:2011/11/23(水) 17:56:54.90
>>300
例えば?

302 :デフォルトの名無しさん:2011/11/23(水) 17:58:08.89
ML系やSchemeが教育で使われる背景もあったけど、調べてくれ。

303 :デフォルトの名無しさん:2011/11/23(水) 17:59:22.73
ほらね。結局逃げるんだよ。

304 :デフォルトの名無しさん:2011/11/23(水) 18:00:14.49
>>302
それはプログラミングではなく計算理論も合わせて教える場合だろう。


305 :デフォルトの名無しさん:2011/11/23(水) 18:01:49.68
>>300
それはどんな言語、どんなパラダイムでもそうなの。
ハスケルだけ特別、関数型だからみたいな事を言うから小馬鹿にされるの。

306 :デフォルトの名無しさん:2011/11/23(水) 18:02:06.25
なんでこんな滑稽なことが起きるのか?という背景だけは触れておくか
なまじっか知ってるために、自分の頭にある今までの学習パターンに当てはめる
が実は、当てはめたら沼に入るパターンも多いからさ。
プログラミングで変なクセがついたら矯正しづらいってのもよく知られてる
けどな。だいたい学習の王道は、副作用もできる関数型から始めるほうが、
いいからね。手続きから始めると、データ構造まで到達して使えるようになるのに
負担が大きいしね。

307 :デフォルトの名無しさん:2011/11/23(水) 18:02:23.56
結局>>302の中で完結してるんだから、何言っても無駄だと思うよ。

308 :デフォルトの名無しさん:2011/11/23(水) 18:02:31.42
>277
× 最適化をしようと思ったら、末尾再帰
○ 実用的な大きさのデータを扱おうとしたら、要末尾再帰


309 :デフォルトの名無しさん:2011/11/23(水) 18:03:22.48
>>305
誰がハスケルを取り上げてそんなことを書いた?
さすがに、これ見た時アホちゃう?と思ったよ。

310 :デフォルトの名無しさん:2011/11/23(水) 18:03:50.40
でも関数型言語って、
少なくとも数学的帰納法をすんなり理解できるところまで教育を受けてないと無理でしょ。


311 :デフォルトの名無しさん:2011/11/23(水) 18:03:57.09
>>306
さっきからその特徴的な改行はなんなの?

312 :デフォルトの名無しさん:2011/11/23(水) 18:04:45.13
さすがに、これ見た時アホちゃう?と思ったよ。

313 :デフォルトの名無しさん:2011/11/23(水) 18:05:45.07
>>310
高校生レベルならOKってことだね。それがわからんというのは
プログラミングするにしても、資材を並べるだけしかできないと思うよ。
論理的に考える素養がなさそうだからね。

314 :デフォルトの名無しさん:2011/11/23(水) 18:07:37.11
>>309
いや、アホはおまえw
「初心者のほうが、かえって理解が早いことがある」なんてことは
構造化プログラミングの時にも、
アメリカの初等教育でLOGOが流行した時にも、
オブジェクト指向が普及しはじめた時にも、
同じことが言われていた。

関数型だからとか、もうアフォとしか言いようがない。

315 :デフォルトの名無しさん:2011/11/23(水) 18:07:58.42
>>313
いや、普通にパソコン好きな少年なら、
高校生レベルになる前にとっくに「クセ」がついてるでしょ。という意味です。


316 :デフォルトの名無しさん:2011/11/23(水) 18:08:35.80
「論理的に考える=関数型で考える」

完全にカルト信者だw

317 :デフォルトの名無しさん:2011/11/23(水) 18:08:42.76
>>313
そういう気持ち悪い言い回しするから友達いなくなるんだよ。

318 :デフォルトの名無しさん:2011/11/23(水) 18:09:21.24
ハスケラ発狂w

319 :デフォルトの名無しさん:2011/11/23(水) 18:10:35.32
>>314
頭悪いな。違ったものをすでにみにつけてるものよりか何もないほうが
吸収が良いことがあるという事から、ずぶの素人とすでにやってる人が
学ぶのでは違う。と書いてるんだが。いい加減、わけのわからん早とちり
で勝手に都合よく解釈するのは。。。馬鹿な奴にアホと言われても
屁とも思わんよ。鼻で笑ってるだけだから。

くだらんやつ相手にするのも暇な時間だけにしなきゃ。

320 :デフォルトの名無しさん:2011/11/23(水) 18:12:30.16
>>315
その仮定が適切なのか、ちょっとわからんし、一般的だとは思えないよね。
共通のコンセンサスがないというのだけはわかったが。

321 :デフォルトの名無しさん:2011/11/23(水) 18:12:37.44
関数型厨の選民思想は見ていて爆笑なのだが、
ご本人達は本気で信じているのだということを思うと可哀想でならない。

カルトって怖いね。

322 :デフォルトの名無しさん:2011/11/23(水) 18:12:50.12
さてはこいつ最近Haskell覚えた高校生だな。
中途半端に頭いいからはてなあたりででかい口叩いちゃう系の。

323 :デフォルトの名無しさん:2011/11/23(水) 18:12:55.95
>>319
だから、一般論としてそういう話があるのは一向に構わないけど、
それと「素人は関数型の方がよい」という主張が繋がらないということでしょ

324 :デフォルトの名無しさん:2011/11/23(水) 18:14:54.31
これはあえてキモい振る舞いでハスケラを演じることでイメージダウンを図るハスケルアンチとみた

325 :デフォルトの名無しさん:2011/11/23(水) 18:15:48.71
素人に勧めるなら、まずはなでしこみたいに、識別子がほぼ全部日本語の関数型言語を
作ってからだな。

326 :デフォルトの名無しさん:2011/11/23(水) 18:18:18.61
>>323
そ。関数型のところに「構造化言語」「LOGO」「LISP」「Java」どれでも当てはまる。

もっと一般化すると、
空手とかで他の道場で変なクセつけた中学生よりも、
はじめて空手を習う小学生のほうが教えやすい。
あたりまえだってw

327 :デフォルトの名無しさん:2011/11/23(水) 18:18:30.48
Haskell厨はキモイなぁ

328 :デフォルトの名無しさん:2011/11/23(水) 18:18:59.53
まあ、どっちから始めるのでも構わないけど最初にやる言語は重要だと思うよ。
逆に、整数型が当たり前のように多倍長な言語で入ってしまうと、
そういう事を気にしなければいけない言語に慣れるのは大変だと思う。
手続き型言語の中で言えば、ポインタやメモリ管理なども同じ問題。
Java→C と C→Java のどちらが「二番目の言語」を覚える障壁が低いのか。

関数型言語の方が、手続き型言語よりも高水準だね。より抽象度が高いという意味で。
そこはそうだと思う。
それ以外の話、使う人のレベルがどうとか、初学者にとってどうとか、そんなのは議論の余地大有り。


329 :デフォルトの名無しさん:2011/11/23(水) 18:19:18.48
>>326
うるさい氏ね

330 :デフォルトの名無しさん:2011/11/23(水) 18:20:06.65
>>328
そうだな!君は正しいよ!!

331 :デフォルトの名無しさん:2011/11/23(水) 18:22:03.03
「10の階乗ってね、1*2*3*・・・*9*10ってやることなんだよ。」
これなら小学生でもわかる。

「10の階乗とはnの階乗ならn-1の階乗で、1の階乗や0の階乗なら1なんだよ。」
これを小学生が聞いたら「ハァ?」ってなる。

332 :デフォルトの名無しさん:2011/11/23(水) 18:22:27.82
関数型言語全般はともかく、IO Monadは手続き型を知らない方が学び易いかもな

知ってたら絶対「なんでこんな面倒なこと覚える必要があるの?」
って気になって習得に集中できない
メリットを聞いても「参照透過性がむにゃむにゃ……」みたいな説明しかしてくれないし

333 :331:2011/11/23(水) 18:23:18.61
書き間違えたorz
「10の階乗とはnの階乗ならn-1の階乗にnかけたもので、1の階乗や0の階乗なら1なんだよ。」

334 :デフォルトの名無しさん:2011/11/23(水) 18:24:14.28
>>332
手続き型を知らないひとにはIO Monadをどう説明するの?
結局は参照透明性ムニャムニャになるでしょw

だって、それが本当の理由なんだから

335 :デフォルトの名無しさん:2011/11/23(水) 18:25:02.45
ケンロン!ケンロン!

336 :デフォルトの名無しさん:2011/11/23(水) 18:25:36.09
>>334
うるさい氏ね

337 :デフォルトの名無しさん:2011/11/23(水) 18:25:46.80
>>331
そう。それ実はかなり重要なところだと思う。

手続き型言語でも closure なんかは当たり前に取り込まれるけど、
map や filter といったところは、手続き型言語専門の人にとっても簡単。
fold をスッと納得できるかどうか。そこが壁だね。

338 :デフォルトの名無しさん:2011/11/23(水) 18:28:03.15
>>334
知らなかったら疑問に思わないから、「面倒だな、でもそういうもんなのかな」
って学習するんじゃないかな
可哀想だけど

339 :デフォルトの名無しさん:2011/11/23(水) 18:28:25.24
で、その学習しやすい関数型言語って、具体的にはどれのこと?
まさかHaskellさんですか?

340 :デフォルトの名無しさん:2011/11/23(水) 18:28:59.35
>>328
> 関数型言語の方が、手続き型言語よりも高水準だね。より抽象度が高いという意味で。


お前が言う抽象度ってのはラムダ抽象だけだろw
世の中には他にも色々な抽象があるんだよ。

例えば、関数型言語は高階述語論理よりも抽象度が高いのか?

341 :デフォルトの名無しさん:2011/11/23(水) 18:32:01.99
>>340
機械語としての0,1ビット列から、より遠くに離れている方が抽象度が高いという意味です。


342 :デフォルトの名無しさん:2011/11/23(水) 18:33:39.70
なんでHaskell厨ってここまで上から目線になれるのかな

343 :デフォルトの名無しさん:2011/11/23(水) 18:34:32.32
ハスケル使える俺ってスゲエ!って酔ってるからじゃないかな?

344 :デフォルトの名無しさん:2011/11/23(水) 18:35:03.53
>>296
そもそもIOモナドの導入は、参照透明性を守りながら入出力をしたいという
言語の表層の問題を解決するために導入されたものであって、
「副作用による依存性」とか難しいことを解決しようとしてる訳じゃないから、その批判は的外れ

345 :デフォルトの名無しさん:2011/11/23(水) 18:35:05.73
>>339
はい


346 :デフォルトの名無しさん:2011/11/23(水) 18:35:50.85
>>345
氏ね

347 :デフォルトの名無しさん:2011/11/23(水) 18:36:52.02
はてなの灘高生なみのキモさを感じる

348 :デフォルトの名無しさん:2011/11/23(水) 18:39:28.71
reft x = 3;

これでxはintとかに型推論して参照透過扱い、
というのはどう?




349 :デフォルトの名無しさん:2011/11/23(水) 18:42:34.80
却下

350 :デフォルトの名無しさん:2011/11/23(水) 18:43:36.25
めんどくせーから、お題出して、各言語で書いてみようず


351 :デフォルトの名無しさん:2011/11/23(水) 18:44:11.05
全くのプログラミング処女を捕まえて、教える場合と、クセのついたプログラマ
が学ぶ場合と違ってくるからな。変なクセがある分関数童貞の手続きプログラマ
のほうが、プログラミング処女より物分りが悪いってことはよくあるみたいだが。

352 :デフォルトの名無しさん:2011/11/23(水) 18:46:02.31
理論が美しい言語はHaskell以外に存在しないからね。
不勉強な君たちには理解できないと思うけど。

353 :デフォルトの名無しさん:2011/11/23(水) 18:48:16.61
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

354 :デフォルトの名無しさん:2011/11/23(水) 18:52:30.45
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

355 :デフォルトの名無しさん:2011/11/23(水) 18:53:18.61
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

356 :デフォルトの名無しさん:2011/11/23(水) 18:53:34.55
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

357 :デフォルトの名無しさん:2011/11/23(水) 18:54:13.04
発言をコピペしてそんなに楽しい? ... 幼稚すぎる。

358 :デフォルトの名無しさん:2011/11/23(水) 18:55:56.02
>>351
逆はポール・グレアム始め多く関数型言語覚えてると手続き型言語でも良いプログラマになると聞くが、どっちが本当なんだぜ?


359 :デフォルトの名無しさん:2011/11/23(水) 18:57:06.36
x多く
o多くの優秀なプログラマが

360 :デフォルトの名無しさん:2011/11/23(水) 18:57:13.35
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

361 :デフォルトの名無しさん:2011/11/23(水) 18:57:22.09
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

362 :デフォルトの名無しさん:2011/11/23(水) 18:57:48.58
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

363 :デフォルトの名無しさん:2011/11/23(水) 18:58:10.25
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

364 :デフォルトの名無しさん:2011/11/23(水) 19:00:52.26
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

365 :デフォルトの名無しさん:2011/11/23(水) 19:04:21.81
>>358
理由は簡単なんだ、アルゴリズムを理解するのにschemeやML系というのは
すごく助けになる。特に木構造の理解には良いし。
だけど、手続き型というのは、文法ノイズが多いことでアルゴリズムを理解
するときに、混同したりということも起こりえるから。そんなこんなで、
データ構造を扱うのが気楽にできるというのもあって、扱う問題に対して
適切なデータ構造とアルゴリズムを選択できるという利点があるからだよ。
感覚的にわかってたら、C++のSTLだってJavaのCollectionだって扱う感覚
が分かるってことからだよ。

366 :デフォルトの名無しさん:2011/11/23(水) 19:06:03.07
なんか真性のキチガイにストークされ始めたようなので、
退散する。キモいもん・・・・。

367 :デフォルトの名無しさん:2011/11/23(水) 19:09:15.35
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

368 :デフォルトの名無しさん:2011/11/23(水) 19:09:24.40
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

369 :デフォルトの名無しさん:2011/11/23(水) 19:10:48.96
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

370 :デフォルトの名無しさん:2011/11/23(水) 19:30:57.75
いい加減に汁

そして、正々堂々と>>350

371 :デフォルトの名無しさん:2011/11/23(水) 19:35:49.64
ハスケラは逃げる口実を与えてくれたことに対して感謝するべきだなw

372 :デフォルトの名無しさん:2011/11/23(水) 19:49:34.85
>>365
独善の極みだな
吐き気がする

おまえみたいのが関数型の普及を妨げていることに気付け

373 :デフォルトの名無しさん:2011/11/23(水) 19:55:05.79
>>371
いや、>>350書いたのHaskellerの自分なんですが…


374 :デフォルトの名無しさん:2011/11/23(水) 20:00:04.02
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

375 :デフォルトの名無しさん:2011/11/23(水) 20:00:10.35
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

376 :デフォルトの名無しさん:2011/11/23(水) 20:00:47.78
>>358
理由は簡単なんだ、アルゴリズムを理解するのにschemeやML系というのは
すごく助けになる。特に木構造の理解には良いし。
だけど、手続き型というのは、文法ノイズが多いことでアルゴリズムを理解
するときに、混同したりということも起こりえるから。そんなこんなで、
データ構造を扱うのが気楽にできるというのもあって、扱う問題に対して
適切なデータ構造とアルゴリズムを選択できるという利点があるからだよ。
感覚的にわかってたら、C++のSTLだってJavaのCollectionだって扱う感覚
が分かるってことからだよ。

377 :デフォルトの名無しさん:2011/11/23(水) 20:01:44.27
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

378 :デフォルトの名無しさん:2011/11/23(水) 20:02:05.78
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

379 :デフォルトの名無しさん:2011/11/23(水) 20:02:43.18
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

380 :デフォルトの名無しさん:2011/11/23(水) 20:05:11.95
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

381 :デフォルトの名無しさん:2011/11/23(水) 20:06:55.40
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

382 :デフォルトの名無しさん:2011/11/23(水) 20:09:24.66
手続型言語厨の逃げですか?
ほら、>>350


383 :デフォルトの名無しさん:2011/11/23(水) 20:09:27.45
なんで発狂してんだ?
OOPのVisitorパターンが冗長だって仄めかされたから?

384 :デフォルトの名無しさん:2011/11/23(水) 20:10:13.38
仄めかすも何も自明すぎて

385 :デフォルトの名無しさん:2011/11/23(水) 20:10:20.73
便乗荒らしじゃないか

386 :デフォルトの名無しさん:2011/11/23(水) 20:11:43.84
>>350
じゃあとりあえず >>244で。

387 :デフォルトの名無しさん:2011/11/23(水) 20:12:06.47
Haskell で回答出てないので。

388 :デフォルトの名無しさん:2011/11/23(水) 20:15:17.67
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

389 :デフォルトの名無しさん:2011/11/23(水) 20:15:49.70
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

390 :デフォルトの名無しさん:2011/11/23(水) 20:16:10.27
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

391 :デフォルトの名無しさん:2011/11/23(水) 20:17:45.50
>>244
>Haskellでグラフのデータ構造を定義する上手い方法はあるのだろうか。
これ悩むんだよね

前やった時はとりあえず計算量無視で関数を作ってみて
あとで速度が必要なところだけ定義は同じで内部でSTモナドを使った関数に置き換えた

木構造がシンプルに書けるといっても破壊的代入がないと
大規模なデータではシンプルなコードは実用的な速度が出ない
実用的な速度を出すには手続き型と同じような書き方を回りくどい方法でとらないといけない

あと大規模データを延々と処理し続けるようなプログラムだと
遅延評価は思いがけないところでメモリリークを起こしやすいように思う
そしてそれを見つけるのが困難

スクリプト的な使い方には非常によいと思う
でも、実用的にはOCamlくらいがいいんじゃないかな
HaskellはType Classや構文が羨ましいけどね

392 :デフォルトの名無しさん:2011/11/23(水) 20:17:45.63
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

393 :デフォルトの名無しさん:2011/11/23(水) 20:17:48.48
>>386
ん、若田
ただな。問題は、自分がプログラミングHaskell読み終わってない初心者なんだなw
使用例とか、どういう動きを期待されてるのか知らないと、書けんw
教えてくれw


394 :デフォルトの名無しさん:2011/11/23(水) 20:18:44.86
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

395 :デフォルトの名無しさん:2011/11/23(水) 20:20:24.62
>>393
あ、大丈夫
typeで独自の型を作るところまではやってるから、後は何とか出来ると思う
あの薄さの入門書でどこまで出来るかやってみたいんだ


396 :デフォルトの名無しさん:2011/11/23(水) 20:20:45.35
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

397 :デフォルトの名無しさん:2011/11/23(水) 20:21:05.68
なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。
勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。
Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、
その点が容易かどうか。最も、難しいところを置いといても
プログラミングはできるけどね。

OOPとの対比になるけど、Visitorパターンが理解できたら、
無名関数でやってることと同じようなことがOOP言語ならできるけど
OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、
関数型やってる奴のほうが、使えるパターンかもしれんが。

398 :デフォルトの名無しさん:2011/11/23(水) 20:27:37.78
ん、「データ構造 グラフ Haskell」でググったら、こんなん出てきたが、これで良いのか?

type Graph = ([Int], [(Int, Int)])

ソース
http://www.shido.info/hs/haskell9.html


399 :デフォルトの名無しさん:2011/11/23(水) 20:28:29.44
グラフならペアのリストなりセットでいいような

400 :デフォルトの名無しさん:2011/11/23(水) 20:32:22.08
アルゴリズム系でHaskellに挑むとか、無謀すぎだろ


401 :デフォルトの名無しさん:2011/11/23(水) 20:35:33.47
>>398
そのグラフからエッジを一本削除してください

402 :デフォルトの名無しさん:2011/11/23(水) 20:37:34.15
>>401
ごめん
エッジを削除ってのは、どういう動作なの?
>>395=>>398なの
全く分からんでググった


403 :デフォルトの名無しさん:2011/11/23(水) 20:38:17.39
書けない言語で無理しなくていいよ

404 :デフォルトの名無しさん:2011/11/23(水) 20:47:09.45
>>391
回りくどいって言うが、IORefはOCamlのrefとほとんど同じだよね
名前が長くて鬱陶しいのは認めるけど、実用性をうんぬんするような違いではないと思う

しかし自分が普段使ってない言語の実用性が低く見えるのはある程度仕方ないんだろうな
俺も「OCamlってマルチコア対応してないのにどうやって実用プログラム書けるんだろう」とか思うし

405 :デフォルトの名無しさん:2011/11/23(水) 20:49:13.56
>>403
いや、グラフとか、エッジを削除とかの用語が分からんだけ
マージソートも、コードなしのアルゴリズムの本で組めたから
(「アルゴリズムのキホン」とか言う、これで手続型言語で組めるのかいな?という舐めきった本)


406 :デフォルトの名無しさん:2011/11/23(水) 20:50:11.42
分からんなら黙ってればいいのに

407 :デフォルトの名無しさん:2011/11/23(水) 20:51:47.78
>>404
いや、それは関数型特有の独善性だから。
勝手に一般化しないでくれ。迷惑だ。

408 :デフォルトの名無しさん:2011/11/23(水) 20:51:58.75
>>406
そんな初心者が書けたら、どうする?


409 :デフォルトの名無しさん:2011/11/23(水) 20:53:57.21
むしろHaskell勉強しててグラフ理論も知らんとかバランスが悪い

410 :デフォルトの名無しさん:2011/11/23(水) 20:54:12.61
もち、手続型の人たちも、グラフの定義とエッジ削除のコードの準備お願いしますね


411 :デフォルトの名無しさん:2011/11/23(水) 20:54:37.55
>>409
だから、マジ初心者なんだってば


412 :デフォルトの名無しさん:2011/11/23(水) 20:55:48.62
>>407
関数型の独善性って?関数型ユーザの独善性って言いたいの?
それこそ不用意な一般化だろ。同意できないならそうとだけ言えばいい

413 :デフォルトの名無しさん:2011/11/23(水) 20:55:53.02
だから出てこなくていいってば。pyths のコードで「素数って何か知らんけど教えて」といわれてるようなもんだ

414 :デフォルトの名無しさん:2011/11/23(水) 20:56:21.70
pyths関係なかった。あれはピタゴラス数か

415 :デフォルトの名無しさん:2011/11/23(水) 20:57:50.88
グラフを知らないのにどうやってハスケルの動作原理を理解したんだwww

416 :デフォルトの名無しさん:2011/11/23(水) 20:57:59.46
>>413
え、Pythsはピタゴラス数であって素数じゃないけど・・・・
手続型の人が怖がってるんですか?
初心者Haskellerに?


417 :デフォルトの名無しさん:2011/11/23(水) 20:59:17.38
>>412
バーカ、おまえが先に一般化をしたんだろ
他人の一般化を批判する権利はない

自分だけが特別だと思ってる関数型厨の典型だな

418 :デフォルトの名無しさん:2011/11/23(水) 21:03:52.84
>>415
え、グラフ理論(?)とHaskellの動作原理に何の関係が…
と、言うか、動作原理は理解してない。・・・と思ってる


419 :デフォルトの名無しさん:2011/11/23(水) 21:04:38.43
>>417
なにそれ。互いのミスを指摘しあうのは議論なら当然だろ
「お前が先に間違えたから俺の勝ちな」とか言っても始まらんよ

あと何か一般化が無条件で悪いと思ってる?

420 :デフォルトの名無しさん:2011/11/23(水) 21:10:13.08
>>404
>回りくどいって言うが、IORefはOCamlのrefとほとんど同じだよね
型がクドくなる

421 :デフォルトの名無しさん:2011/11/23(水) 21:10:32.29
関数型言語のクイックソートって空間計算量が O(nlogn) という理解で正しい?

422 :デフォルトの名無しさん:2011/11/23(水) 21:11:57.63
あとSTモナドは型注釈必須なのでめんどくさいから使いたくない
まぁunsafeなんちゃらつかえばいいんだけど

423 :デフォルトの名無しさん:2011/11/23(水) 21:14:28.17
>>421
使った端から到達不能になるから
O(n)でいいんじゃない?

424 :デフォルトの名無しさん:2011/11/23(水) 21:18:09.84
>>421
Haskellの有名なやつを念頭に置いてる?
あれは遅延リストだから空間計算量は訳分からんことになる
最悪O(n log n)かもしれない

同じことを正格なリストか配列でやればO(n)
in-placeのクイックソートを実装すればもちろん追加メモリは定数で済む

425 :デフォルトの名無しさん:2011/11/23(水) 21:18:52.60
あの・・・
グラフの説明とエッジ削除の説明は・・・


426 :デフォルトの名無しさん:2011/11/23(水) 21:19:26.72
いや最悪O(n^2)っぽい

427 :デフォルトの名無しさん:2011/11/23(水) 21:20:19.93
>>425
ここはお前の勉強部屋じゃない

428 :デフォルトの名無しさん:2011/11/23(水) 21:21:48.63
>>425
まともなデータ構造の教科書を買うか借りるかぐぐる

429 :デフォルトの名無しさん:2011/11/23(水) 21:24:32.31
ocamlerがHaskellをディスるスレ

430 :デフォルトの名無しさん:2011/11/23(水) 21:26:00.82
実際ocamlは使い易いし

431 :デフォルトの名無しさん:2011/11/23(水) 21:27:34.40
>>427-428
せめて、手続型言語のコードは出ないんでしょうか?



432 :デフォルトの名無しさん:2011/11/23(水) 21:41:57.79
グラフに
4種類のノルムを定義して

それぞれについてダイクストラ
結果に応じて条件分岐して
各エッジに容量を設定して
最大フロー問題

433 :デフォルトの名無しさん:2011/11/23(水) 21:43:06.45
ち、自分で出来ない事を関数型言語は〜とか言わないで欲しいなぁ…
関数型言語の検証ができないじゃないか

自分は文法に惚れただけで、実用可能かどうかははっきりしてないんよ
このスレが検証にうってつけだと思ったんだけどな・・・


434 :デフォルトの名無しさん:2011/11/23(水) 21:45:11.51
Haskellの前は何使ってたんだ?その言語が手続き型なら自分で書けよ。
要はグラフ理論知らないだけだろ?勉強不足。

435 :デフォルトの名無しさん:2011/11/23(水) 21:46:09.65
>>432
ハスケルではつらそうな例を考えて見ました

436 :デフォルトの名無しさん:2011/11/23(水) 21:51:59.91
>>432
いやだから・・・
マジ初心者だから、ダイクストラから分からんのよ…
一応、ググったらCのコード出てきて、typeすら使う必要ないっぽいけど・・・

ダイクストラ法 Haskellでググったらこんなん出てきてるけど

type Index = (Int, Int)

data Node = Node { cost :: !Int, pos :: !Index, from :: !Index }
deriving (Show, Eq, Ord)

ソース
http://haskell.g.hatena.ne.jp/route150/20100502/1272792417

こういうのを、自分はちゃんと自分で書きたいんだよ

んで、手続型言語のソースが一向に出ないのも、説明が出ないのも何でよ・・・


437 :デフォルトの名無しさん:2011/11/23(水) 21:53:04.78
手続きの書き方は自明すぎるから

438 :デフォルトの名無しさん:2011/11/23(水) 21:54:34.05
面倒くせえからグラフ知らないなら双方向リストでいいよ。それがグラフだ。

439 :デフォルトの名無しさん:2011/11/23(水) 21:56:10.02
>>434
そうよ
手続型だろうが、関数がら多だろうが、それを知らなきゃ書けんのよ

マージソートのときは、Haskellでは分かっても、手続型言語で書き方分からんかった(いや、配列じゃなくてリストで作れってなら、今なら作れるけどさ)
色々やったよ
CもRubyもJavaもSmalltalkまでやったさ


440 :デフォルトの名無しさん:2011/11/23(水) 21:56:56.67
>>437
なら、それがHaskellで書くヒントになるから書いてほしい


441 :デフォルトの名無しさん:2011/11/23(水) 21:57:41.76
>>439
「グラフというデータ構造を知らないんだから書けるわけないだろ、教えてくれないそっちが悪い」ってか?
それお花畑すぎねえか?

442 :デフォルトの名無しさん:2011/11/23(水) 21:59:16.59
>>437
勉強してから来てくれ


443 :デフォルトの名無しさん:2011/11/23(水) 21:59:48.77
>>440
だから双方向リストでいいって。
末尾に O(1) で要素を add できる。
末尾要素を O(1) で remove できる。
末尾要素を O(1) で取得できる。
一つ前の要素を O(1) で辿れる。

これを満たすデータ構造を作れ。

444 :デフォルトの名無しさん:2011/11/23(水) 22:01:39.78
>>443
グラフ知らない人に
オーダー記法使って話しかけるなww

445 :デフォルトの名無しさん:2011/11/23(水) 22:03:14.95
すまんかったwww

446 :デフォルトの名無しさん:2011/11/23(水) 22:04:09.59
てかオーダー気にしないならある意味Haskell最強かもしれんwww
代入なんて効率のためにあるようなもんだし

447 :デフォルトの名無しさん:2011/11/23(水) 22:04:46.76
>>443
ふむ、ちょい頑張ってみる
酔っぱらってきてるから、明日とか明後日になるかもだけど、作ってみるよ


448 :デフォルトの名無しさん:2011/11/23(水) 22:05:32.97
逃げるか。俺も泥酔した状態で443書いたんだけどな。

449 :デフォルトの名無しさん:2011/11/23(水) 22:07:21.87
>>446
うい、無限のメモリと無限のクロックがあれば最強
だから、個人的には64ビットOSの普及がHaskell普及のカギかな?とか思ってみたり
CからC++、さらにLLへと流れてきた延長で


450 :デフォルトの名無しさん:2011/11/23(水) 22:08:27.37
おいおい64ビットOSの普及がカギとか...

451 :デフォルトの名無しさん:2011/11/23(水) 22:09:02.87
>>448
いや、書くよ
今日書けるか自信がないだけ
何つーても初心者(少なくともHaskellはw)な上に、酒がまわってきた


452 :デフォルトの名無しさん:2011/11/23(水) 22:10:27.57
>CもRubyもJavaもSmalltalkまでやったさ

という人が双方向リストを作るのに明日か明後日になる。
それがHaskell

453 :デフォルトの名無しさん:2011/11/23(水) 22:11:16.27
>>450
ぶっちゃけ、コード書くのは楽だけど、LLとはどっこいどっこいだとして、やっぱメモリ食うもんよ
クロックの方は、腐ってもコンパイラだから、LLより速いんだけど(Rubyの後でHaskellやってたから、マジビビった)


454 :デフォルトの名無しさん:2011/11/23(水) 22:12:00.17
>>452
いや・・・
入門書で挫折してるから…
覚えた言語の数が問題じゃないんですぜ?


455 :デフォルトの名無しさん:2011/11/23(水) 22:13:05.76
>>453
それで、32ビットOSが64ビットOSになるのに合わせて、搭載されるメモリが2^32倍になるのかな?

456 :デフォルトの名無しさん:2011/11/23(水) 22:13:12.99
一方ジャバラーはライブラリをそのまま使った

457 :デフォルトの名無しさん:2011/11/23(水) 22:13:43.78
>>443
あ、ついでだけど、双方向リストって英語でなんて書くの?
関数名&ファイル名にしたいんだけど


458 :デフォルトの名無しさん:2011/11/23(水) 22:14:46.47
>>456
そりゃそうだろ。ソースを見て写経してもいいが意味ないし

459 :デフォルトの名無しさん:2011/11/23(水) 22:15:28.20
Haskell勉強しようって奴はこんなのばかりなのか?

460 :デフォルトの名無しさん:2011/11/23(水) 22:16:02.16
実のところocamlerだがhaskellに偏見を持ちそうだ。

461 :デフォルトの名無しさん:2011/11/23(水) 22:18:45.42
あんたら話しをごっちゃにしすぎ。一次資料に当たれ。

462 :デフォルトの名無しさん:2011/11/23(水) 22:22:52.94
>>455
実用的にはそこまで要らないだろうけど、末尾再帰使わんと、4GBじゃ不足する場面もあるんよね…
末尾再帰よりはループの方が素直なんよ
(そういえば、Haskellにもfor関数あるっポイんだが、使い方分からん…。副作用のある関数で使うモナドの糖衣構文do内の引数なし再帰は実質、ラベル付きGotoだから、困るわけではないんだけど…)

自分でfor関数作った方が速いんじゃろか…
(doが付く関数内でしか使わんけど)


463 :デフォルトの名無しさん:2011/11/23(水) 22:23:24.90
圏論の勉強中だから静かにしてくれる?

464 :デフォルトの名無しさん:2011/11/23(水) 22:25:09.62
>>459
たぶん…
かなり稀な方だと自覚してる
ウザがられるの分かってるけど、Haskellが一番しっくり来たんで絶賛宣伝中
逆効果かも知れんけど、その時は、真のHaskellerが何とかしてくれると(ry


465 :デフォルトの名無しさん:2011/11/23(水) 22:27:35.06
>>464
名前欄にHaskellSamuraiとか入れとくといいよ

466 :デフォルトの名無しさん:2011/11/23(水) 22:28:02.88
>>433=464
ksg

467 :デフォルトの名無しさん:2011/11/23(水) 23:33:13.41
Haskell侍。。。Ocaml岡村。。。。

468 :デフォルトの名無しさん:2011/11/23(水) 23:35:21.30
はすけるのコードって、どうやってパフォーマンスチューニングするん?
メモリ足りない時とかI/Oの帯域幅が重要な時とか。

469 :デフォルトの名無しさん:2011/11/24(木) 00:34:25.91
アルゴリズムの見直しは大きいだろうよ。okazakiを参考にするとか

470 :HaskellSamurai:2011/11/24(木) 00:43:21.42
一応、双方向リストっぽいのは出来たんだけど、自信がない…

data DList f l = Null | DList f l
deriving (Eq, Ord, Show, Read)


そもそも、双方向リストってのが、どういう動きするのかが分からんのだもん・・・

一応、自分の作った双方向リスト(か分からない何か)の使用例

>Null
Null

>DList Null Null
DList Null Null

>DList 1 (DList 2 Null)
DList 1 (DList 2 Null)

>DList (DList Null 2) 1
DList (DList Null 2) 1


471 :デフォルトの名無しさん:2011/11/24(木) 00:57:08.04
上から順に、

空リスト

空リストの空リスト

通常のリストと同じ方向にリスト作成

通常のリストと逆方向にリスト作成

これを使ってO(1)で結果が返るadd関数やremove関数作を作れるかはまだ分からない状態


472 :デフォルトの名無しさん:2011/11/24(木) 01:01:08.94
セルに前方と後方へのポインタ2つをつけたらいい。
それを使ってrmapとかrconsとか実装してみればいい。

473 :デフォルトの名無しさん:2011/11/24(木) 01:03:59.62
http://stackoverflow.com/questions/1844195/doubly-linked-list-in-a-purely-functional-programming-language
これでも読んどけ。

474 :デフォルトの名無しさん:2011/11/24(木) 01:51:33.02
>>315
懐かしいなあ、俺とかプログラミング始めたの小学生のときだわ
初めての言語はBASICだったが
仮に初めてが関数型言語だったとしたら、さんすうの知識でやれたんだろか?

475 :デフォルトの名無しさん:2011/11/24(木) 04:47:55.03
>>419
なるほど、ハスケラってメンヘラなんだな

476 :HaskellSamurai:2011/11/24(木) 06:42:56.06
>>472
双方向リストモドキを定義しなおし、そのhead関数も定義してみた

data DList a = Null | DList (DList a) a (DList a)
deriving (Eq, Ord, Show, Read)


dhead (DList Null x _) = x
dhead (DList xs _ _) = dhead xs

使用例
*Main> dhead (DList (DList Null 2 Null) 1 (DList Null 3 Null))
2

477 :デフォルトの名無しさん:2011/11/24(木) 07:22:27.25
>>404
> OCamlってマルチコア対応してないのにどうやって実用プログラム書けるんだろう

Unix.fork または ocamlmpi

478 :デフォルトの名無しさん:2011/11/24(木) 14:40:24.15
マルチスレッドもいけるF#最強ってことですね

479 :デフォルトの名無しさん:2011/11/24(木) 15:05:22.40
f# はfuntor ない

480 :デフォルトの名無しさん:2011/11/24(木) 17:35:22.41
>>476
それ、2分木だろ
全然双方向リストになってねえよ

481 :デフォルトの名無しさん:2011/11/25(金) 16:17:52.04
>>476
流れは良くわからんが
そも双方向リストは単純に再帰定義できないからhaskellでは素直に書けないよ
双方向リストを実装したライブラリというのも、俺は見たことないな
どうしても使いたいなら頭を捻るか、STモナドやIOモナドに入れて対応しよう
再帰定義できないデータ型としては例えば他に両端キューやハッシュテーブルがあるけど、
haskellの両端キューは特別な木で実装されてるし(前者)、
haskellのハッシュテーブルはIOモナドの中でしか使えない。(後者)
そして普通はハッシュテーブル使うぐらいなら再帰定義可能な平衡二分探索木を使うようだね
haskellのやり方というのはそういうものだ

482 :デフォルトの名無しさん:2011/11/25(金) 16:51:50.46
>>481
分かりやすく二行でまとめると、

・手続き型言語やLisp/ML等の大半の関数型言語 --> 双方向リストやハッシュが「自然に書ける」
・Haskell --> 再帰定義やモナドといった「面倒な手法を駆使しなければ」表現できない

ということですかな

483 :デフォルトの名無しさん:2011/11/25(金) 17:13:22.23
>>482
他の関数型言語がそれらを自然に書けるかどうかは不勉強なんで良くわからんな
ただ、双方向リストで必要な参照型と、ハッシュテーブルで必要な破壊的代入は、どっちもhaskellが生理的に嫌ってる部分だからね
その両方を簡単に扱える言語であればどちらも自然に書けるはずだよ

モナドはともかく、再帰定義が『面倒な手法』というのは手続き的な発想だな
むしろhaskellは再帰を愛しているからこそ、できる限りそれだけで対応したがる、というのが正しい
あんまり変わらない? うん、まあ、そうかもしれんね

484 :デフォルトの名無しさん:2011/11/25(金) 17:35:37.07
手続き型が自然は疑問だよ、読み書きそろばんを小学校のうちに矯正させられ
るんだから。

小学校に上がる2年前にタッチタイピング、1年前にLISPで数の概念を教えて
中学卒業前に偏微分まで独学させたらおもしろい子供になると思う。学校では
数学を習うから手続き型も覚えるし、かなりちょうど良いんじゃないかな。
あと小学校で習う筆算の+−×÷の記法って特殊だよね。あとそろばん習って
いる人は今は少ないかもしれないけど、そろばん流暗算も特殊だよね。
余談だけど子供には読み書きもしっかりやらせたいと思っている。とくに書きは
意識的にやらせないと覚えないので意識的にやらせる。プログラミングの習得って
早ければ早いほどプログラミング歴が長くなって、時間感覚が豊富になるよね。
15歳からプログラミングを始めて18歳で考えるプログラミングや世間に対する
とらえ方と6歳からプログラミングを始めて18歳で考えるプログラミングや世間に
対するとらえ方はまったく違うものになるだろうね。15歳から始めたヤツは27歳
ぐらい必要だろうし。早くても24歳ぐらいは必要だろうなあ。これは読みと書きにも
言えること。数学はそういう時間感覚があるのか、知らん。
>>230
x = x+1ってx <== x+1の省略記述だよね、厳密には。教育言語のPascalがx := x+1なん
だっけ?
>>231
躓きはしないけど「うん?」とはなっていたなあ。
>>232
慣用句だと思って暗記して使うしかないけどなあ。9.9割はパターン認知処理で問題が
起きないので忘却曲線を意識してすべて暗記すればいいと偉い先生が言っていたよ。
>>236
日本語の算術的に考え方で言うとそろばんと升とかの方が歴史は長いんじゃないの?
近代化のために江戸時代的なものを脱ぎ捨てて今があるけど。

485 :デフォルトの名無しさん:2011/11/25(金) 18:10:20.80
>>484
日本の教育システムは、採点し易いか否かを優先してるから、論理性は教える方も解ってないからなあ。

486 :デフォルトの名無しさん:2011/11/25(金) 18:47:52.51
>>314
アメリカの教育って今の日本の教育並にウンコだっただけでしょ。
あとプログラミングの教育って相当難しいんじゃないかな。おまえら、
中高でかなり時間割り当てられているはずだけど、古文、漢文自作できるか?
あとA4二枚の英作文できるか?
>>321
選民思想なのかわからないが、人が選択肢している時点で合理的な判断をして
いるから合理性は出てくるだろうなあ。
>>331
それただ教えてもらっていないだけでしょ。今の数学の教科書みたいに二段飛び、
三段飛び当たり前だときついけど、小中高のすべて合わせて1,500ページの教科書を
渡して中1まで進めれば勝手に独学して進めるヤツは結構いると思うよ。
>>338
あいさつの概念、作文の概念、読書の概念、算数の概念、活版印刷の概念とか一々
やったら子供は逃げ出すだろうなあ。空手や柔道みたいに型を教えて、何年後かに
分かればいいだけ。
>>474
数学が得意で国語が不得意だったけどベーマガのBasicコードを写しているだけだったな。
付属のリファレンスを読んでみたけど、関数?(学校で習った関数だよな?)?だった。
市の図書館に行っても小難しい本しかないし、ネットもなかったらフリーソフトを
手に入れる手段もなかった。万単位のお金を払ってプログラミング言語を買う概念なんて
なかったし、そのソフトを仮に大奮発で買うとテキストを買うのは無理だからなあ。
やっぱり本でどうやって引き込んでいくかが大事な気がする。プチゲーム(ジャンケン
ゲーム等)を組ませつつ、数理的な問題も組ませつつ引き込んで行く。
80年代がマイコン全盛なんだっけ?子供向け本も多かったんだろうけど、今はそうい
うのが少ないんだろうなあ。子供向けではないけど個人のWebページで言語入門みたい
なのがあるからそういうのでアナルファックの味とか覚えるのかな。

487 :デフォルトの名無しさん:2011/11/25(金) 18:59:04.95
>>485
論理性も教えるためにゆとり教育ができたんだけどね。小学校は熱心だったようだけど、
中高は一部の先生がボイコットしちゃったたみたいだね。まあ、ゆとり以前に
週5授業とか、予算と教員に教材仕込む時間を設けなかったりとか、色々と問題があった
し、ゆとり導入前にマスゴミが学校をガンガン叩いて劇場化して、教員が教えられない
状況を作っちゃったからどうしょうもないんだけどね。子供に一番良くないのは親が
教員を疑うことと教員が自信を持って教えられる環境がなくなることらしい。
アメリカのデータだとインディアン部族の教育が体罰あるらしいが、体罰したからって
変な子供になるわけではないらしい。文明先進民族の白人が勝手に「体罰は良くない」と
注意し始めて、インディアン自身が白人が言っていることの方が正しいと思ってしまって、
教え方にブレが生じて、荒れ始めたらしい。日本は家庭体罰に行政介入できるようになっ
ちゃったから家庭教育しづらいわ。子供の人権を盾にやりたい放題させるのは子供自身にも
本当に良くないと思うわ。まあ、この流れは当分止まらないんだろうけどなあ。

488 :デフォルトの名無しさん:2011/11/25(金) 19:12:30.73
あと思ったけど手続き型言語の代表言語をいくつか出さないか?
Cであったり、Javaであったり、.netであったり、Perlであったり、Pythonであったり、
RubyであったりだとCの実行速度を持ちつつ、VM上で動くのでOSを環境依存もなく、
Windows対応もよく、文書整形向きでワンライナーもしやすく、可読性もよく、日本人が
作った最強言語と錯覚させる恐れがある。個人戦でVSで戦ったら実際の所はどうなんだろ。
トーナメントつくって議論して勝敗決めていこうか。

489 :デフォルトの名無しさん:2011/11/25(金) 19:25:39.38
ここはOcamlerがHaskellerを煽るスレでな

490 :デフォルトの名無しさん:2011/11/25(金) 19:48:23.59
Haskellは純粋ゆえに、どうしょうもなく使えないパターンってあるからね。
双方向はそう幽霊だよね。学習用と見たときな明確に欠点かなと思ってる。
スペシャリストとジェネラリストに分けたら、Haskellはスペシャリストなん
だよ。Ocamlはまだジェネラリストの顔を持ってる。

手続きが書きやすいかどうかは知らないけど、lispで構造体を使って双方向
リストを作ってみたら、いささかCと変わらん感じがする部分は出てくるよ。
どうしてもポインタ操作で破壊的操作が必要だからね。木構造はHaskellは
大変扱いやすいんだけどなぁ。HaskellというよりML系はというほうが適切か。
だから、木構造を上手に活用する方法を考えだすんだろうね。

HaskellでSICPの後継が欲しいってのもSICPスレで読んだけど、Haskellじゃ
どうしても途方もなくめんどくさくなる章があるんだよな。それがHaskell
の限界だと思ってるよ。限界を超えようとして頑張ってる人たちも多いけど
大変だよね。その頑張ってる人たちがいるから並行処理に魅力があるんだけ
どな。

491 :デフォルトの名無しさん:2011/11/25(金) 19:52:29.20
IORefやIOUArrayがりがり書き換えまで含めてHaskellだと思ってる

492 :デフォルトの名無しさん:2011/11/25(金) 20:04:12.52
誰もHaskellで双方向リスト書かないの?

493 :デフォルトの名無しさん:2011/11/25(金) 20:09:39.54
>>492
see >>473

494 :デフォルトの名無しさん:2011/11/25(金) 22:05:39.70
ocaml の特有の基本仕様は大体覚えたんだけど
こっからhaskell 覚えてメリットある?

495 :デフォルトの名無しさん:2011/11/25(金) 22:32:25.61
どうしてO(1)のハッシュマップを使わずに
O(log(N))の平衡木を使わなけゃならんの?

どうして双方向リストを使わずに
単方向リストや配列を使わなけゃならんの?

496 :デフォルトの名無しさん:2011/11/25(金) 22:40:34.57
>>495
べつにハッシュマップや双方向リストを使いたければ使えば良いよ
そのかわりpersistentなデータ構造にはならないってだけ

497 :デフォルトの名無しさん:2011/11/25(金) 22:55:32.69
>>496
効率の良いデータ構造をモナドの外で使えないのは不便じゃないの?

498 :デフォルトの名無しさん:2011/11/26(土) 00:02:27.09
不便なこともあるね

499 :デフォルトの名無しさん:2011/11/26(土) 00:24:12.60
ノイマン型コンピュータ、もっといえばチューリングマシン自体が手続き型なんだから、
その上で動かす関数型言語がぎこちないのは当然の理屈だな。

500 :デフォルトの名無しさん:2011/11/26(土) 00:46:38.19
手続き型、関数型の概念は共に構造化がベースだから、チューリングマシンとは別カテゴリ。

501 :デフォルトの名無しさん:2011/11/26(土) 00:56:37.11
>>495
そのためにありとあらゆる工夫をして高速化してるのがOkazakiじゃなかったっけ?
良く言えばすごいけど、Okazaki本は話しか聞いてないから見てないけど、SMLで
かかれてるんだよな?
悪く言えば、純粋のためのバッドノウハウと取られかねない。藁

502 :デフォルトの名無しさん:2011/11/26(土) 01:05:55.91
Oderskyに空目した

503 :デフォルトの名無しさん:2011/11/26(土) 01:08:08.51
それscala病 :-)

504 :デフォルトの名無しさん:2011/11/26(土) 01:15:18.21
>>500
んなこたーない。
主流CPUの機械語が全て手続き型なのは紛れもない事実

505 :デフォルトの名無しさん:2011/11/26(土) 01:16:55.39
命令型プログラミング
http://ja.wikipedia.org/wiki/%E5%91%BD%E4%BB%A4%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0
宣言型プログラミング
http://ja.wikipedia.org/wiki/%E5%AE%A3%E8%A8%80%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

一般に命令型プログラミングは、手続き型プログラミングと同義として扱われる。

506 :デフォルトの名無しさん:2011/11/26(土) 01:18:09.14
>>499,500,504
用語がおかしいから意見が食い違う。
機械語は手続き型というより、命令型プログラミングという表現が正しい。

507 :デフォルトの名無しさん:2011/11/26(土) 05:14:39.53
ハスケルの人達はLISPを馬鹿にしているけど
結局ハスケルの代数データ型は
LISPのcar,cdrのリスト構造の範疇内でしか
データを操作できないってことでOK?

508 :デフォルトの名無しさん:2011/11/26(土) 06:32:13.65
>>501
oka S aki ね

509 :HaskellSamurai:2011/11/26(土) 07:08:13.68
>>480
こんなのも書いてみたけど、双方向リストじゃ・・・ないよね・・・
ジグザグな構造になっちゃうし


data DList a = Null | Prev (DList a) a | Next a (DList a)
deriving (Eq, Ord, Show, Read)

使用例

Prev (Prev Null 1) 2
>Prev (Prev Null 1) 2

Next 1 (Next 2 Null)
>Next 1 (Next 2 Null)

Prev (Prev (Next 3 Null)) 1) 2
>Prev (Prev (Next 3 Null)) 1) 2

うーん・・・
双方向リストの使用例みたいなのが見たい・・・


510 :デフォルトの名無しさん:2011/11/26(土) 07:09:42.50
双方向リストは定義し難いが無限リストは定義し易い

511 :デフォルトの名無しさん:2011/11/26(土) 07:32:40.18
じゃあ双方向無限リストでいいよ。

512 :デフォルトの名無しさん:2011/11/26(土) 07:44:33.01
>>492
>>509
『各要素が左右へのポインタを保持する』という実装にこだわらないなら、
つまり、ただ>>443のインタフェースが欲しいだけなら両端キューを使えばいいよ
ttp://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Sequence.html

513 :デフォルトの名無しさん:2011/11/26(土) 08:30:49.02
と、いうか俺の>>481の表現はまずかったな。すまない
『双方向リスト』は再帰定義できないから、
haskellは両端キューを『フィンガーツリー』で実装している
『ハッシュテーブル』は再帰定義できないから、
haskellは連想配列を『平衡二分木』で実装している
というのが正しい

514 :デフォルトの名無しさん:2011/11/26(土) 10:57:48.09
Haskellはデータサイズが大きくなるとlogNだかの呪いがかかって使い物にならないってこと?
この後どうなっちゃうの?

515 :デフォルトの名無しさん:2011/11/26(土) 11:25:03.90
>>514
>>496

516 :デフォルトの名無しさん:2011/11/26(土) 11:25:19.56
ハッシュテーブルのO(1)はメモリ効率の悪さとトレード・オフで実現されてるものだからねえ・・・
連想配列として常にハッシュテーブルが最適とは限らない
なにより一応両方使えるんだから適宜使い分ければよいでしょう

517 :デフォルトの名無しさん:2011/11/26(土) 11:38:15.05
>>507
バカにしてるだろうかね?謎だな。エバンジェリストのところのhaskellの
wikiがgaucheのなのに。

518 :デフォルトの名無しさん:2011/11/26(土) 11:41:51.84
http://en.wikibooks.org/wiki/Haskell/Zippers

519 :デフォルトの名無しさん:2011/11/26(土) 11:49:20.23
http://learnyouahaskell.com/zippers
http://www.haskell.org/haskellwiki/Zipper

ぐぐるとZipperを使えって話があったのでZipperを調べてみた。

520 :デフォルトの名無しさん:2011/11/26(土) 12:37:32.56
木の上を行ったり来たりできるよってことでいいのか
確かに双方向だな

521 :デフォルトの名無しさん:2011/11/26(土) 14:07:35.45
>>513
フィンガーツリーや平衡二分木というのはデータ構造に関する
汎用的なアルゴリズムだから、Haskell固有の概念ではない
実際、二分木による連想配列の実装は手続き型言語でも使われる

これに沿って>>482を書き直すと、

Lisp/ML等の大半の関数型言語 -->
・手続き型言語の経験者であれば、(破壊的代入を用いる事で)
 その経験を活かして容易く双方向リストやハッシュを実装できる
・もしも参照透明性が必要であれば、(難解ではあるが)
 フィンガーツリーや平衡二分木といったアルゴリズムで実装する事もできる
・どちらを選ぶかはプログラマの判断であり、
 処理系からプログラマには「自由」が与えられる

Haskell限定 -->
・双方向リストやハッシュはフィンガーツリーや平衡二分木といった
 (難解な)アルゴリズムを用いなければ実装できない
・プログラマは参照透明性の保証を、常に処理系から「強要」される

ということですかな

522 :デフォルトの名無しさん:2011/11/26(土) 14:44:19.31
Haskellだと参照透明性が「必ず」保証される
MLとかは参照透明性は必要であればプログラマが保証する必要がある

と思いきやUnsafeIOとかあるしな

523 :デフォルトの名無しさん:2011/11/26(土) 15:02:03.95
俺はunsafe系は流石に触らないなぁ・・・
といいつつtraceは使うんだけどね

524 :デフォルトの名無しさん:2011/11/26(土) 15:16:27.44
Haskellの場合はプログラマが必要に応じて参照透過性を壊せる。

525 :デフォルトの名無しさん:2011/11/26(土) 15:20:47.79
だからHaskellなら参照透明性を守ったまま破壊的代入ができるんだって
もちろん破壊的代入をしないスタイルの利点(persistentなデータ構造、
状態に関するバグに悩まされない)は失われるけど、それは当然のトレードオフ

526 :デフォルトの名無しさん:2011/11/26(土) 15:25:08.28
IOモナドに参照透過性があるって事?

527 :デフォルトの名無しさん:2011/11/26(土) 15:26:18.51
>>522
X: Haskellだと参照透明性が「必ず」保証される
O: Haskellだと参照透明性をプログラマが「必ず」保証しなければならない

X: MLとかは参照透明性は必要であればプログラマが保証する必要がある
O: MLとかはプログラマは参照透明性を保証することもできるし、
    保証しないコードも書けるという「自由」がある

528 :デフォルトの名無しさん:2011/11/26(土) 15:35:00.67
>>526
うん。もうちょっと正確に言うと、IOモナドやらIORefやらを使うだけでは
Haskellの参照透過性を壊すことはできない
unsafePerformIOその他の危険な関数を使えば壊せる

529 :デフォルトの名無しさん:2011/11/26(土) 15:44:10.23
ML系って参照透明性のことでschemeみたいに、!の有り無しで見た目区別する
みたいな工夫をしてるの?よくしらんねんけど

530 :デフォルトの名無しさん:2011/11/26(土) 16:04:08.75
>>525
>だからHaskellなら参照透明性を守ったまま破壊的代入ができるんだって

それは「モナドを使えば....」という前提があるわけで、
そのモナドで包んだ範囲内では参照透明性が保証されるという話だろ?
言い換えると、Haskell処理形は参照透明性が保証されたコードしか受け付けないから、
プログラマが(モナドを使って)保証したコードを書いているという事だ

つまり、

Haskell限定 -->
・I/Oや破壊的代入といった参照透明性を阻害する処理については、
 すべてモナドを使わなければコードが書けない

Lisp/ML等の大半の関数型言語 -->
・モナドのような難解な概念を持ち出さなくても、自然にコードが書ける
・もちろん>>136のSMLの実例あるように、参照透明性を保証したコードも書ける

ということを意味している

手続き型言語およびLisp/ML等の大半の関数型言語に慣れた、いわゆる普通のプログラマにとって
たかが入出力ですらいちいちIOモナドを使わなければコードが書けないダメ言語が Haskell

531 :デフォルトの名無しさん:2011/11/26(土) 16:09:14.95
まるでIOモナドが魔物ででもあるかのような口ぶりだな

532 :デフォルトの名無しさん:2011/11/26(土) 16:28:38.67
>>531
たとえば「読んで; 計算して; 書く」という単純な処理は、
SMLなら以下のような明解なコードになる
(他のML族やLisp族でも同様なコードになる)

 let
  val x = 読む
  val y = 計算 x
 in
  書く y
 end

それがHaskellでは、こんな初歩のプログラミングですら
IOモナドを使わなければコードが書けないだぜ
どこをどう考えても 「Haskellはダメ言語」 だろ


533 :デフォルトの名無しさん:2011/11/26(土) 16:29:36.50
>>530
単にdo書くだけなのに、そんなに手間か?
個人的には手続モードと関数モードを行ったり来たりする感覚


534 :デフォルトの名無しさん:2011/11/26(土) 16:35:02.03
一次資料に当たれって。

535 :デフォルトの名無しさん:2011/11/26(土) 16:41:56.76
>>533
他人様の作ったモナドを利用するだけの「末端プログラマ」であれば、
それでもいいんじゃね?

536 :デフォルトの名無しさん:2011/11/26(土) 17:10:47.30
「読んで; 計算して; 書く」というだけの簡単な処理をするだけのために
「副作用」とかいう謎の概念を駆使しないといけない言語と比較するなら、
五十歩百歩だろ

537 :デフォルトの名無しさん:2011/11/26(土) 17:17:48.90
副作用という概念は手続き型言語だけしか使わなくても知っておくべきだと思うが

538 :デフォルトの名無しさん:2011/11/26(土) 17:21:27.86
>>535
入力して計算して出力するだけなら、それで十分じゃね?
何を無駄にモナド作るんだよ


539 :デフォルトの名無しさん:2011/11/26(土) 17:27:14.34
>>537
そりゃ、アセンブリ以外の手続き型言語は大抵副作用という概念を持っているからな

540 :デフォルトの名無しさん:2011/11/26(土) 17:29:36.46
>>532
Haskellはよく知らんがこんな感じだろ?似たようなもんじゃね
do
  x <- 読む
  書く y
  where
   y = 計算 x


541 :デフォルトの名無しさん:2011/11/26(土) 17:31:23.33
>「副作用」とかいう謎の概念を駆使しないといけない言語
って手続き型言語のこと言ってるんじゃない?

542 :デフォルトの名無しさん:2011/11/26(土) 17:31:29.19
>>540
細かいことを言うとそのwhereはletにしないとxがスコープにないのでエラーになる

do
  x <- 読む
  let y = 計算 x
  書く y

ますます似てる

543 :デフォルトの名無しさん:2011/11/26(土) 17:40:02.35
似てるどころか一緒じゃね?

544 :デフォルトの名無しさん:2011/11/26(土) 17:43:37.02
まあアンチスレらしく不便な点を挙げるとしたら、
純粋関数として定義したものの、あとからその『内部』でIOを扱いたくなった場合、
printfデバッグみたいにここに一行挟んでー、みたいな気楽な使い方は、残念ながら出来ない。
一度IOを持ち込むとsafeなやり方ではその中から出られなくなってしまうから(つまり、関数の返り値の型が変わってしまう)

545 :デフォルトの名無しさん:2011/11/26(土) 17:48:45.95
それはあるね
printfデバッグに限ってはDebug.Traceを使うけど

546 :HaskellSamurai:2011/11/26(土) 17:55:49.14
>>514
いや・・・
自分が無理に副作用無しの双方向リスト作ろうと奮闘してグダグダにしてるだけ・・・

今月の数学セミナーによると、計算機科学全般の副作用を数学上で再現するためにモナドが生まれたっぽい
つまり、関数型言語のみならず、手続型言語全般の動作を数学上で再現するにはモナドが必要らしい
そういう意味では、モナドでオブジェクト指向も再現できるのかも

そういう意味で、モナドは副作用のない数学の世界に、副作用を再現する概念なんだよね
Haskellのモナドも、良く分からんが、そういう事なんじゃないかと思う

それはともかく、自分は双方向リストはじめ、勉強不足すぎるから、しばらくROMるよ


547 :デフォルトの名無しさん:2011/11/26(土) 18:06:31.90
HaskellSamuraiさんHaskellスレにおいでよ。

548 :デフォルトの名無しさん:2011/11/26(土) 18:10:16.97
関数型言語を使う予定はないが
その考え方はいただいてやったぜ。
C++のSTLとかも影響受けてるんだよね?

549 :デフォルトの名無しさん:2011/11/26(土) 20:01:17.16
>>548
お互いに不完全だけどね


550 :デフォルトの名無しさん:2011/11/26(土) 20:11:11.78
数年すればお互い色々整理されて使いやすくなるだろう

551 :デフォルトの名無しさん:2011/11/26(土) 20:21:34.91
そう思って既に15年 orz

552 :デフォルトの名無しさん:2011/11/26(土) 23:38:28.72
まあ代入のある関数型言語は全部手続き型言語の影響を受けてると言っていい

553 :デフォルトの名無しさん:2011/11/27(日) 00:13:35.71
Fortranの影響を受けてない高級言語など存在しない

554 :デフォルトの名無しさん:2011/11/27(日) 00:33:36.04
お互いじゃなくて、Haskellの個性の沿った使い方を丁寧に教える
状況というやつじゃない?You learn a Haskell ...の最後になんで
Zipperなのかがよく分かる流れだったよ。


555 :デフォルトの名無しさん:2011/11/27(日) 01:03:33.62
結局のところ、lazy evaluation と eager evaluation の
どっちがデフォルトが嬉しい?って話に尽きるのでは
eagerな言語では、Haskellとは逆に遅延評価したい処理をモナドに包んだりするわけでさ

まあ、普通のプログラマである俺にはlazyがデフォルトは厳しいわ

556 :デフォルトの名無しさん:2011/11/27(日) 07:02:48.01
>>547
レベル高すぎて中々書き込めないけど、たまに書き込んでますよ

何ヶ月か前に数学セミナーで圏論の連載が始まるって書いたのも私だったり
(今月号で5回目だから、だいぶ前か)


557 :デフォルトの名無しさん:2011/11/27(日) 09:02:38.23
for Great Goodって、どこのカルトかと・・・

558 :デフォルトの名無しさん:2011/11/27(日) 09:35:18.56
>>555
>どっちがデフォルトが嬉しい?って話に尽きるのでは
いや、それはHaskellの特徴のほんの一部じゃないか
遅延評価よりも重要なものがいくらでもあると思う
型クラス、純粋さ、インデント構文、マクロとか

559 :デフォルトの名無しさん:2011/11/27(日) 09:45:37.55
インデント構文が重要?

560 :デフォルトの名無しさん:2011/11/27(日) 09:54:50.50
Haskellに遅延評価がなかったら、で誰か思考実験してみて

561 :デフォルトの名無しさん:2011/11/27(日) 09:58:05.99
俺は重要だと思ってるけど異論もあるだろうな
具体的には、閉じ括弧を書かなくて良い場面が多いので、
関数の最後の引数にdoやラムダ式を書いたり、
激しくネストした関数呼び出しを書いたりしても見難くなりにくい
これはコーディングスタイルにかなり影響を与えてると思う

閉じ括弧が少なくなるのはインデント構文だけじゃなくて
$の影響もあるけど

562 :デフォルトの名無しさん:2011/11/27(日) 11:20:32.71
>>558
cleanで代替できるわけか

563 :デフォルトの名無しさん:2011/11/27(日) 11:34:04.55
>>559
横レスだが、個人的には見やすいので助かってる。
プログラミング始めた頃は、これパースしにくいだろ
センス無いなーと思ってたけど、使って行くうちに
インデント以外の事(データ構造とか)で頭を悩ます
ようになったんで、パット見判るのが良い。

564 :デフォルトの名無しさん:2011/11/27(日) 12:05:29.29
>>562
開発が止まってるやんけ


565 :デフォルトの名無しさん:2011/11/27(日) 12:05:41.98
>>559
読みやすくなる。あれだけ括弧のことを言われるlispでも実は
インデントでソースを読んでいるくらい。

566 :デフォルトの名無しさん:2011/11/27(日) 14:52:58.70
>>564
つまりハスケルの開発もすぐ止まっちゃうの?

567 :デフォルトの名無しさん:2011/11/27(日) 17:09:30.54
>>563
インデント構文は忘れた頃にコードに手を入れようとするとひどい目に合う
haskellでも文脈自由構文使う
インデント構文以外選べないpythonは使わない


568 :デフォルトの名無しさん:2011/11/27(日) 17:45:13.36
そして
「あいつのコード読みにくい。どうしてインデント構文つかわねえんだ」
と陰口叩かれる

569 :デフォルトの名無しさん:2011/11/28(月) 00:16:13.44
>>566
Haskellの場合、関数型言語特有の技術の有効性を検証する目的で作られた一面もあるから、まず開発が止まることはない


570 :デフォルトの名無しさん:2011/11/28(月) 00:21:33.60
>>567
どっちかと言うと、忘れたころに読み直す時にこそ、インデント構文の方が読み直しやすいと思うんだが、痛い目って、手直しでインデントがズレまくるとか?
単に関数にまとめるのが下手なだけちゃうんかと


571 :デフォルトの名無しさん:2011/11/28(月) 00:27:44.32
>>560
でかいファイルの読み込みでしょっぱな困る
コード上は無限リストで一気に全部読み込んでるように見えて、遅延評価で必要になった分ずつ読み込んでいくからメモリがパンクしないのに、遅延評価が無かったら、プログラマの方でメモリがパンクしないように気をつかわにゃならん


572 :デフォルトの名無しさん:2011/11/28(月) 00:30:59.17
そんでも上手いこと要らないデータは捨てないと同じことだがね

573 :532:2011/11/28(月) 01:07:30.76
>>540,542,543
しばらく待ってみたが、残念な解答ばかりだな

>>532では明確に書いていなかったけど、もしも「お題」を書くとしたら、

 モナドを使わずに「読んで; 計算して; 書く」という処理をHaskellで書きなさい
 ここで、ごく単純な逐次処理なのだから、再帰の使用は禁止します

というものになる。後だし条件かもしれないが、それくらいは推測できるだろ?
>>532では「(Haskellじゃ)IOモナドを使わなければコードが書けない」と書いてあるんだから

Haskellのdo記法や>==はモナド向けの構文糖だ
お前等はそんなことも知らないナンチャッテ・ハスケラなのか?
Haskellという言語の表層だけで満足して酔っているお前等は「ドカタ・ハスケラ」だ

574 :デフォルトの名無しさん:2011/11/28(月) 01:40:12.96
関数型でdo構文みるのは苦痛だな。見苦しいというのか、出来る限り避けたいよね。

575 :デフォルトの名無しさん:2011/11/28(月) 02:11:32.12
(>==)の結合性を教えていただきたいものだなwwww


576 :デフォルトの名無しさん:2011/11/28(月) 05:43:18.62
>>569
そりゃcleanも同じだ
Haskellだけ特別だと思ってる?

577 :デフォルトの名無しさん:2011/11/28(月) 07:35:43.93
>>571
正格なHaskellなら間違いなくiteratee使うだろ

578 :デフォルトの名無しさん:2011/11/28(月) 07:38:25.72
>>573
>モナドを使わずに「読んで; 計算して; 書く」という処理をHaskellで書きなさい
「モナドを使わずに」なんて妙な条件を読み取れって方が無茶だろw
もともと
>SMLなら以下のような明解なコードになる
と書いてあったから、モナドを使って同様に明快なコードになることを示しただけ

579 :デフォルトの名無しさん:2011/11/28(月) 07:45:37.09
>>574
Haskellのdoならすごく読み易くない?
(>>=)やラムダを多用したコードの方が汚く見える
Haskellに限らず逐次実行のための仕組み一般(OCamlの;とかも)を指しているなら、
それなしでどうやってプログラム書くのか

580 :デフォルトの名無しさん:2011/11/28(月) 08:09:58.63
do記法の中に(>>=)を混ぜるのが最強
異論は認める

581 :デフォルトの名無しさん:2011/11/28(月) 09:18:03.28
>>573
>==が>>=のタイポだとしてもお前話にならないから帰っていいよ。

582 :デフォルトの名無しさん:2011/11/28(月) 09:43:06.23
煽るにも技術的なバックグラウンドが必要だな。

583 :デフォルトの名無しさん:2011/11/28(月) 11:25:50.20
>>578
そもそも「読んで計算して書く」って、それ自体が手順だしな…
手続き的に書くほうが自然だし、ちゃんと要所でそれが出来るのがHaskellなんだし

584 :デフォルトの名無しさん:2011/11/28(月) 11:33:31.02
アンチの質が低すぎてアンチスレがアンチスレになっていない件

585 :デフォルトの名無しさん:2011/11/28(月) 13:14:13.04
Haskellの長所でありクソな点は、計算の中に副作用を入れるのがモナドをやりくりしないといけなくてめんどくさいことですし。
副作用のある手続きの中に計算を入れるのは他の言語と大差ない。

586 :デフォルトの名無しさん:2011/11/28(月) 15:31:59.75
>>579
どうしても避けられないところはあるけど、極力避けてるよ。
doの中ってやっぱり手続き臭が強くって、あのクサさは最悪だと感じてるから。
まるで卵の腐った匂いだ。

587 :デフォルトの名無しさん:2011/11/28(月) 16:30:50.72
硫黄大好き

588 :デフォルトの名無しさん:2011/11/28(月) 18:23:53.51
>>583は結局、手続き的な記述の利点を認めているわけで、
だったら手続き型ベース+関数型スタイルでいいだろうとなる。
にもかかわらず関数型マンセーなのは矛盾を感じるな。

>>586 のハスケル原理主義のほうがかえって好感が持てる。

589 :デフォルトの名無しさん:2011/11/28(月) 18:31:41.98
>>1はScalaやF#なんが含めて煽りたかったんだろうが、
まさかHaskeller対その他になるとはな。

590 :デフォルトの名無しさん:2011/11/28(月) 19:04:37.27
>>588
HaskellもMLも十分、手続き型言語とのハイブリッドだよ
逐次実行、破壊的代入、複雑な入出力、どれも避けて通れないアプリは多いんだから、
これらをうまく書けないような言語は汎用言語として欠陥がある

>だったら手続き型ベース+関数型スタイルでいいだろうとなる。
それよりも関数型ベース+手続きスタイルが良いと思ってる奴がHaskellとかMLを使ってるだけ

591 :デフォルトの名無しさん:2011/11/28(月) 20:29:45.70
>>588
手続き型「にも」利点があるし、そのほうが書きやすく直感的な処理もある

592 :デフォルトの名無しさん:2011/11/28(月) 20:58:07.30
自分は、
できるだけ関数型で書いて、副作用を少なくする
効率やどうしても副作用が必要なところは関数やマクロに閉じ込める
というのが良いと思ってる。

593 :デフォルトの名無しさん:2011/11/28(月) 21:52:28.86
賛成反対はともかく、それはなぜ?


594 :デフォルトの名無しさん:2011/11/28(月) 22:15:34.63
>>592
卵の腐ったのが嫌いな人なんですが、同感です。
最初は、副作用が無い版をつくってチューニングしてだんだん形にしていく。

595 :デフォルトの名無しさん:2011/11/28(月) 22:21:54.52
>>593
デバッグのやりやすさだと思うよ。手続き型の書き方を利用していくと
関数の作用が、複数にまたがるために、エラー箇所の見積もりが面倒になる。
一つくらいだったら、さほど問題はないけど、複数同じようになってみたら
ちゃっちゃと作っていく関数型スタイルを壊すだけになるんだよ。トレース
にしてもプロファイルにしても煮詰める箇所を定めやすい。
だから、一つ一つの関数の作りはシンプルでというのは、自分の中では鉄則。
でも、doなんて多様するとね。。。あとが大変なのよ。

596 :デフォルトの名無しさん:2011/11/28(月) 23:37:26.50
do記法が嫌いな人って結構いるんだなぁ・・・意外

597 :デフォルトの名無しさん:2011/11/28(月) 23:49:48.58
if 〜
then
 〜
else
 〜

と書けないのが悲しい

598 :デフォルトの名無しさん:2011/11/28(月) 23:50:44.17
そんなのたった二つスペース入れるだけでいいじゃんかwww

599 :デフォルトの名無しさん:2011/11/29(火) 00:26:59.17
http://blog.raynes.me/blog/2011/11/27/the-clojure-community-and-me/
この人17歳でClojureの本を出すらしい。最初の言語はHaskellと言って
るとのこと。

600 :デフォルトの名無しさん:2011/11/29(火) 00:29:11.48
13でHaskellの師匠を見っけたのか。 中学生でも関数型は可能だな。

601 :デフォルトの名無しさん:2011/11/29(火) 00:31:33.65
A lot of people wonder if learning Haskell, a purely functional language,
as a first language would make OOP languages be as difficult to learn
and understand as functional languages are to OOP developers.
My answer, given my experiences, is no.
Learning a functional language first gave me the programming
foundations that I needed to understand OOP and how it compared
to other paradigms.

と答えてるな。

602 :デフォルトの名無しさん:2011/11/29(火) 01:06:33.44
関数型を最初に勉強したらOOPの勉強が困難になるかっていうとそんなことないお
関数型のおかげでOOPの習得に必要なプログラミングの基礎も身についたお
だから初心者も関数型から入ったらいいお!Prolog最高だお!

ってことか

603 :デフォルトの名無しさん:2011/11/29(火) 05:06:14.90
>>600
Scratchは色々な国の小学生に使われているよ。
しかもSmalltalkで改造されたパーツが小学生間で流通してるよw

604 :デフォルトの名無しさん:2011/11/29(火) 07:15:13.10
>>597
Haskell 2010では書けるようになった

605 :デフォルトの名無しさん:2011/11/29(火) 10:19:26.34
>>592
良識人登場

606 :デフォルトの名無しさん:2011/11/29(火) 11:46:44.56
>>590
汎用言語なんてあったか?

607 :デフォルトの名無しさん:2011/11/29(火) 12:50:17.46
>>603
だから。。。何?

608 :デフォルトの名無しさん:2011/11/29(火) 19:02:18.26
今時は13歳はもうビッチってことだろw

609 :デフォルトの名無しさん:2011/12/02(金) 02:32:46.15
template用途だと関数型言語は理にかなっているよね

C++だってtemplateは純粋関数型言語だし
まぁあれは構文が腐っているけど

610 :デフォルトの名無しさん:2011/12/02(金) 07:46:44.41
テンプラと関係あるっけ?

611 :デフォルトの名無しさん:2011/12/03(土) 06:10:29.62
>>597
むしろ、elseなしが書けないわけですが・・・
パターンマッチあるから、困ることもないんだが


612 :デフォルトの名無しさん:2011/12/03(土) 09:21:52.54
そういう時はifじゃなくてwhenじゃない?

613 :デフォルトの名無しさん:2011/12/03(土) 22:07:14.99
>>610
入力のソースを変形して出力するという処理だから関数型に適している

614 :デフォルトの名無しさん:2011/12/04(日) 19:41:46.01
関数型「でも」できるってのと、
関数型「のほうが上手く」できるってのは
ずいぶん違う話だぞw

164 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)