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

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

1 :デフォルトの名無しさん:2012/02/28(火) 20:45:47.95
前スレ
http://toro.2ch.net/test/read.cgi/tech/1320743217/

2 :デフォルトの名無しさん:2012/02/28(火) 21:08:37.06
オブジェクト指向言語で関数型風味(?)に書いたらこんな感じ?
http://ideone.com/CXMrq

要素数と実行時間が何の関係無くなるけど
そもそも何を比較してたんだっけ

3 :デフォルトの名無しさん:2012/02/28(火) 21:38:51.34
今時の技術についていけなくなったら辞めてくださいね

4 :デフォルトの名無しさん:2012/02/28(火) 22:28:08.33
前スレで関数型言語は玩具にすぎないと結論出たからスレは不要

5 :デフォルトの名無しさん:2012/02/28(火) 23:03:54.55
>>1

前スレ>>992-993
なら、Haskellもコンパイラの進歩でpythonに並ぶ余地はあるって事か

元々、length関数や、++演算子(リストの連結演算子)が初心者にも簡単に作れるってのが気に入ってるだけだから、体感できない速度差は気にならんけど・・・
Haskellに惹かれるのは、defとか、forとか、(モナド使わない限りはifも)そう言うキーワードをなるべく見ないで済むってのが、一番大きい気がする
(というか、forとifが一番見たくない)

あと、基本的に右辺と左辺が=(等しい)なのも気に入ってる

コンパイラのmain=...と言うのも、あながち間違ってない

速度こそpythonに劣るだろうけど、自作のmap関数や、++演算子などの":"で区切られて、状態を次の再帰に引き摺らないものは、単純再帰でも、ループとして扱われる
(だからこそ、末尾再帰は、次の再帰に状態を引き摺らないのでループになる)
結局、アセンブラに実現できることは、関数型言語でも、命令型言語でも、最終的な最適化の形は同じになるだろうけど、それは時間が解決する話

関数型言語の最終的な最適化の形は
http://ideone.com/SaMJe と http://ideone.com/kzkty が同じ速度になる事

これは、参照透明性が確保されて無いと、最適化できない事の一つ
(まだ実現されてないけし、逆に言えば、参照透明性が確保された関数に限れば、命令型言語でも理論的には最適化可能なはず)


6 :デフォルトの名無しさん:2012/02/28(火) 23:24:52.82
>>5 最後の行について
Fortran95には、純粋関数/手続きというのがあって、これは副作用を持たない
ということなのたが、ベクトル演算ができるようになる。
が、write文が使えなくなるとか、グローバル変数が使えないとかいろいろ
制約があって非常に使いにくい。

7 :デフォルトの名無しさん:2012/02/29(水) 00:07:48.89
●過去スレ
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1277215506/
関数型言語は何故普及しないのかを考える
http://hibari.2ch.net/test/read.cgi/tech/1286791669/
【アンチ】関数型言語は使えない【玩具】
http://toro.2ch.net/test/read.cgi/tech/1320743217/

●関連スレ
関数型言語Part5
http://toro.2ch.net/test/read.cgi/tech/1252470706/

8 :デフォルトの名無しさん:2012/02/29(水) 00:20:49.11
速度比較は、よくネタになるけど、最も抽象度の低い言語でも出来る例での比較→言語自体の優劣の流れは無意味だろ。
VBとアセンブラを比べるようなもんだけど、単純作業での比較にこだわる人が多いのはなんでだろう?


9 :デフォルトの名無しさん:2012/02/29(水) 00:25:12.28
なぜ関数型言語は普及しないか - プログラミング日記
http://d.hatena.ne.jp/morchin/20110614/p1
「なぜ関数型言語は普及しないか」に対する言及
http://togetter.com/li/149656
関数型言語が普及しない理由 - mizon dev
http://d.hatena.ne.jp/mizon9/20111112/1321046483
関数型言語が普及しない理由その2 - mizon dev
http://d.hatena.ne.jp/mizon9/20111112/1321128525
関数型言語が普及しない理由 - 偏見プログラマの語り!
http://d.hatena.ne.jp/kura-replace/20111114/1321236695
関数型言語が普及しない理由 - より良い環境を求めて
http://d.hatena.ne.jp/n314/20111114/1321290502

10 :デフォルトの名無しさん:2012/02/29(水) 01:47:42.56
>>8 パッと見て、いろいろ言えるからではないだろうか。
そこそこ重たい数値計算をやりだすと、関数型言語が謳う理想通りにいかない
場面はいろいろあるのだが、2chのように限られた字数でしかも関係者外にも
わかるように問題点を説明するのはなかなかうまくいかない。

11 :デフォルトの名無しさん:2012/02/29(水) 02:30:51.04
個人的にはHaskell、lispはアプリ言語が欲しい時によく使うし、C、Javaはインフラで使ってる。
各言語には目的によって向き不向きがあるから、用途を論じるとか、用途拡大方法を考えるならまだ判る。
同じような単純作業の比較で何を得たいのか判らないんだよね。

12 :デフォルトの名無しさん:2012/02/29(水) 06:20:45.06
>>8
抽象度が低くてもチューリング完全なら最終的にできることは一緒
どれだけ簡潔に書けるかという意味でいうなら、reverseという簡単な例ですら
CとHaskellには大きな差がちゃんと在った

つーか前スレの配列版HaskellはCの次に速かったぞ
コード量もC並みだが

13 :デフォルトの名無しさん:2012/02/29(水) 08:54:55.81
>>12
>reverseという簡単な例ですら

そういう単純な例で実行時間が違うのはわかるけどさ、それを言語全体の優劣判定に短絡するのが無意味だと思うんだが。

コンピュータの利用範囲が広がるに連れて、アセンブラだけでは実現に手間がかかるから色んな言語が開発された訳だから。
例えば金融商品企画のようなアプリを、リソースを大量に使えばCでも開発は理屈上は可能だが、
それはもはやHaskellのインタープリターをCで再発明するくらいの問題になる。
だから疑問は、リソースには色々あるのに、なぜ単純な例で時間だけに拘るのか?という事。

単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。

14 :デフォルトの名無しさん:2012/02/29(水) 11:44:51.88
誰かHaskellが遅いから言語として劣ってるって書いてたっけ?

事実としては「Haskellは遅い」それだけ
言語の優劣は各自で判断すべき

15 :デフォルトの名無しさん:2012/02/29(水) 11:56:48.77
はっきり数字出ましたし。

16 :デフォルトの名無しさん:2012/02/29(水) 12:14:19.99
関数型のリファレンス言語と見られる言語が遅かったら
そりゃ価値を見出せないよ


17 :デフォルトの名無しさん:2012/02/29(水) 13:22:34.34
速さならOCamlがC並ってのは良く聞く
自分はdefとかrecとか関数定義にプログラミング言語特有のキーワード使う機会が少ないのが気に入ってhaskell使ってるけど


18 :デフォルトの名無しさん:2012/02/29(水) 14:33:26.94
>>13
>単純例しか経験がなくて、時間以外のリソースは微々たるものだと考えてる者なら必然だけどね。

このスレは、既存のHaskellコンパイラより早いHaskellインタープリターを自作出来る猛者が集う場所ですよ?

19 :デフォルトの名無しさん:2012/02/29(水) 14:33:56.41
遅い遅いって一生言ってろ、でいいんじゃね?

シートベルトって窮屈じゃん、って言ってるバカと同じなんだから。

20 :デフォルトの名無しさん:2012/02/29(水) 14:40:32.02
>>14
>事実としては「Haskellは遅い」それだけ

そのとおり。
Haskellでできる事は全部、C、Pythonならもっと早く出来る。
時間は重要なリソースだという事は学生にはわからんだろうな。

21 :デフォルトの名無しさん:2012/02/29(水) 15:16:18.78
>>20
えっ。Haskellの遅延評価のようなことがC、Pythonなら
もっと速くできるなんていっていいのですか。
少なくとも「早く」はできませんよね。

22 :デフォルトの名無しさん:2012/02/29(水) 15:29:25.53
>>21
そういうときは、コードを書いて「これを書いてみろ」って言うくらいじゃないとね

ていうか、遅延評価は手段のひとつであって、それ自体が目的であることは滅多に無い

23 :デフォルトの名無しさん:2012/02/29(水) 16:21:54.03
時間という点では開発時間も重要だね

でも長いコードと、それと同性能で短いコードで
前者の方が早く作れたりするのは良くあることだから
コード量と開発時間の相関も割りと微妙なんだよね

学習コストだとか、命令型と関数型の両方を扱える人のうち
関数型の方が早く開発出来る人の割合とかも気になるところ

24 :デフォルトの名無しさん:2012/02/29(水) 17:05:05.52
haskellが遅いってのは、
c/c++より遅い、あるいは静的言語の中では平均的に遅い、という意味なんだが、
時々文脈を(意図的に?)混同して、スクリプト言語よりも遅いとか言い出す輩が後を絶たない。
前スレで可変長配列と片方向連結リストを混同して勝利宣言してる馬鹿を見た時はまたかと思ったよ。

25 :デフォルトの名無しさん:2012/02/29(水) 17:06:08.59
>>17
夢を壊して申し訳ないが...

OCaml

http://ideone.com/MqIzH  (リスト)
http://ideone.com/LH93F  (配列)

26 :デフォルトの名無しさん:2012/02/29(水) 17:06:10.29
藁人形製作乙です。。。

27 :デフォルトの名無しさん:2012/02/29(水) 17:34:45.71
>>24
Haskellは可変長配列に代表されるような速いデータ構造を
扱おうと思ったら途端に面倒になるのが問題なんだろ

悔しかったらPythonより速いコードをPython並みに簡潔に書いてみろ

28 :デフォルトの名無しさん:2012/02/29(水) 17:37:02.40
Haskell並みに安全で機械語にコンパイルされたコードをPythonから生成してから言え

29 :デフォルトの名無しさん:2012/02/29(水) 17:44:34.78
>>28
Haskellが安全?www

xs = head []

30 :デフォルトの名無しさん:2012/02/29(水) 17:46:18.05
実行速度の比較をしているときに安全とか抽象力とかいうから
虫ケラ、じゃなかった、ハスケラはコミュ障だっていわれんの!

31 :デフォルトの名無しさん:2012/02/29(水) 17:47:33.28
>>28
Pythonより速いコードをPython並みに簡潔に書けないという
ギブアップ宣言か

もう「Haskell = 遅い」が定着しそうな勢いだな

32 :デフォルトの名無しさん:2012/02/29(水) 17:54:26.32
pythonは永続データと破壊操作を巧みに両立させて速度稼いでいるからな。
どっかでhaskellの人が永続=透明性と書かない人は理解してない人と断定してたけど、
どうしてhaskellの有名人はみんなアレなんだ?

33 :デフォルトの名無しさん:2012/02/29(水) 18:20:19.50
おまえの脳内の勢いがすごい勢いで加速中ということはよくわかった

34 :デフォルトの名無しさん:2012/02/29(水) 18:58:08.72
vectorパッケージが見つからない、と思ったらGHC6.8とはね・・・
古すぎるだろ・・・・
ふふふ残念ながらMPが足りないようだ・・・


・・・とするのは悔しいので前スレのSTUArray版(お借りします)とVector版を手持ちの環境で走らせて計測してみましたよ
STUArray版(コードは省略)
結果(+RTS -sオプションから抜粋)

9 MB total memory in use (0 MB lost due to fragmentation)

Total time 0.12s ( 0.10s elapsed)

次はVector版
コード
module Main where
import qualified Data.Vector.Unboxed as V

main :: IO ()
main = print $ V.head $ V.reverse $ V.iterateN 1000000 (+1) (1 :: Int)

結果

5 MB total memory in use (0 MB lost due to fragmentation)

Total time 0.05s ( 0.04s elapsed)

まあこんなところですね

35 :デフォルトの名無しさん:2012/02/29(水) 19:34:46.13
隔離スレとして、ちゃんと機能してるようで何より。

36 :デフォルトの名無しさん:2012/02/29(水) 19:37:34.53
「なんで時間だけに拘るの?」
「遅いのは事実だ!!」
凄いコミュ力だなw

37 :デフォルトの名無しさん:2012/02/29(水) 19:46:13.50
>>23
>コード量と開発時間の相関も割りと微妙なんだよね

その言語に慣れている者が書くという前提で、一日に書けるコード量は言語による大差は無いというのをどっかで見た。


38 :デフォルトの名無しさん:2012/02/29(水) 19:55:58.80
コード書いてる時間より
ビルド, 実行, ソースとにらめっこ, ウロウロしながら思考
してる時間の方が長い希ガス

39 :デフォルトの名無しさん:2012/02/29(水) 19:57:15.64
コード量が同じなら抽象度の高い言語の方が多くの事が出来るだろうな。

40 :デフォルトの名無しさん:2012/02/29(水) 20:13:38.52
>>39
一般に低水準の言語の方がワード単位の入力時間が短くなる。
極端な場合、倍位にはなる。だから、よほど難しい問題でないかぎり、
>>37がいうように一日に書けるコード量は同じに、近い。
しかし、それだけ体力もいるから、プログラマの定年が若くなる。
高水準な言語だと60歳でも十分。この差は大きい。

41 :デフォルトの名無しさん:2012/02/29(水) 20:28:55.82
高水準な言語とはもしかしてCOBOLのことを言っているのだろうか。

42 :デフォルトの名無しさん:2012/02/29(水) 21:33:07.14
リスト操作の速度を比較しようって決まって、
ベンチマークも決まって実装計測して結果が揃ったところで
どうして時間だけとか言い出すのは完全にコミュ障だろw

43 :デフォルトの名無しさん:2012/02/29(水) 21:38:19.97
数行の「リスト操作」って、何を比較したことにもならんぞw

44 :デフォルトの名無しさん:2012/02/29(水) 22:18:59.01
>>43 くやしいのうw

45 :デフォルトの名無しさん:2012/02/29(水) 22:59:57.73
gccがhaskellになったら考える
なったらなったでメンテする人がいなくなりそうだけど

46 :デフォルトの名無しさん:2012/02/29(水) 23:38:01.82
>>43
まあ元々、アッカーマンとか無視してる時点で、無意味だから。

47 :デフォルトの名無しさん:2012/03/01(木) 00:21:41.07
haskellが一行で配列を高速にreverseしたのがそんなに悔しいんですか?


48 :デフォルトの名無しさん:2012/03/01(木) 06:12:44.47
reverse関数「を」どれくらい簡潔に実装できるかって話してたのに
(しかも言い出したのはHaskeller)
ライブラリのreverse関数呼び出してドヤ顔して馬鹿じゃないの?

49 :デフォルトの名無しさん:2012/03/01(木) 06:19:26.14
>>31を「1行」とかいう人は
目か頭のいずれかもしくは両方とも悪い。

50 :デフォルトの名無しさん:2012/03/01(木) 06:23:35.74
>>49
???

ああ、自分の頭が悪いって告白ですか
そういうのはパパやママに言ってください
我々の所為じゃないので

51 :デフォルトの名無しさん:2012/03/01(木) 06:48:15.28
>>46
アッカーマンを無視するってどういうこと?

52 :デフォルトの名無しさん:2012/03/01(木) 08:08:18.25
>>48
ん、ああそういう流れだっけ?
じゃこれで
module Main where
import Prelude hiding (length, head)
import Data.Vector.Unboxed

rev :: Vector Int -> Vector Int
rev v = generate (length v) $ \ i -> v ! (length v - 1 - i)

main :: IO ()
main = print $ head $ rev $ iterateN 1000000 (+1) (1 :: Int)

9 MB total memory in use (0 MB lost due to fragmentation)
Total time 0.06s ( 0.05s elapsed)

今度はgenerate自作しろって言い出すんでしょうかね(笑)

53 :デフォルトの名無しさん:2012/03/01(木) 08:26:52.95
っていうか『プリミティブなアルゴリズムが簡潔に書ける!』とか言って
車輪の再発明繰り返して喜んでるだけのhaskellerに問題があるよねえ
(どういう意味にせよ)少しは実用的な話をしようぜ?

54 :デフォルトの名無しさん:2012/03/01(木) 09:13:52.23
>>50
ああ、43のtypoだと解らない程度の頭なんだね。
カワイソス

55 :デフォルトの名無しさん:2012/03/01(木) 09:17:06.03
>>52
おそ!

56 :デフォルトの名無しさん:2012/03/01(木) 10:16:55.81
2chで”流れ”を感じ始めたら、少なくとも二重の意味でヤバイな。

57 :デフォルトの名無しさん:2012/03/01(木) 11:00:27.41
>>51
関数型が得意なベンチマークでなきゃヤダヤダ


ってこと。

58 :デフォルトの名無しさん:2012/03/01(木) 12:27:42.50
Rは関数型に入りますか?

59 :デフォルトの名無しさん:2012/03/01(木) 12:38:56.07
C言語プリプロセッサは関数型に入りますか?

60 :デフォルトの名無しさん:2012/03/01(木) 16:28:17.22
バナナの皮は関数型言語に入りますか?
λ
形が似てるんですが

61 :デフォルトの名無しさん:2012/03/01(木) 16:39:32.31
お前、先生が許可したら人も殺すのか
関数型言語を殺すつもりか!

62 :デフォルトの名無しさん:2012/03/01(木) 19:44:58.10
haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
(一部のみ、先行評価より速い)

そもそも、reverseが単方向リストに不利なわけだが・・・
とりあえず、main/print(IOモナド使った関数)以外の関数を自作してみた

http://ideone.com/15yhM

自分がHaskellに惚れたのは、IO関連以外は言葉遊びみたいな感じで自作出来るのが楽しいから
(rangeはもうちょっと作りこめたかも・・・)
速さよりも、その構造を調べるのが楽しい

data Natural = Zero | Succ (Natural) deraiving (Eq,Ord,Show,Read)

自然数の定義と、リストの定義が似ているのが分かる。
自然数は、その長さそのものが数字としての意味を持ち、リストは長さにも長さと言う意味はあるが、自然数との決定的な違いは、要素自体も値を持っているか?だけだと言うのが分かる


遅延評価生かしたプログラムなら、ファイル処理とかだろうけど、ideoneでファイルの読み込ませ方知らん(と言うか、在るのか?)
ので、一応、こんなのも作ってみた(1から1000000までの足し算の合計のリストを作って、先頭の10要素を表示)

http://ideone.com/insk7

簡約の様子を見てみると関数同士が絡み合って、一番外側の関数の終了条件のみで、他の関数の終了条件を満たして無くても、関数が終わるのが自然と理解できる

もちろん、最初から無駄の無い処理を書かれると負ける。foldllやmapみたいな、状態を次の再帰に引き摺らない様に書けば、スタック消費が抑えられるって言うだけで、Haskell自体の最適化は弱い



63 :デフォルトの名無しさん:2012/03/01(木) 22:13:10.07
不覚にも>>60-61の流れに

64 :デフォルトの名無しさん:2012/03/01(木) 22:56:48.12
なんで、list reverseだけでここまで引っ張ってるんだ!?
>>11を受けて関数型言語/命令型言語の適材適所の話題になると期待したのだが。

65 :デフォルトの名無しさん:2012/03/01(木) 23:19:04.92
>>64
まあここは隔離スレだし、目的が互いに異なる言語同士を単純作業で比較したがる人が集まる場所でもある。
鳥と魚を比較するのに、共通項目だからといって体重や肺活量で比較するようなもんで、最重要と言えるほどの意味は無いと思うが。

比較するなら、計算モデルからのアプローチ(CTMCPなど)も有るので、該当スレが宜しいかと。

66 :デフォルトの名無しさん:2012/03/02(金) 10:52:02.59
本スレで煽り質問しかできないバカは回線切って吊れ

67 :デフォルトの名無しさん:2012/03/02(金) 11:57:42.38
>>62
>haskellの遅延評価は、元々先行評価よりも遅い傾向にあるんだけどな・・・
>(一部のみ、先行評価より速い)

評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ?
遅延評価を使ったプログラムの総時間と混同してないか?

68 :デフォルトの名無しさん:2012/03/02(金) 11:58:15.19
>>67
X 尊えば
O 例えば

69 :デフォルトの名無しさん:2012/03/02(金) 13:03:35.88
>>67
>評価する際の処理時間が先行評価より速い遅延評価って尊えば何だっけ?

遅延評価とか先行評価とかいうのは評価『戦略』であって、『評価するかどうか』を決めるだけだ。
実際に『評価する際』には評価戦略の段階は通り過ぎてるからその問は無意味だろう。

そして遅延評価は評価するまでに猶予を置く意味合いしか無いから、
無駄な計算をしないという仮定のもとでは、遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
>>62のいう『一部』というのはたらい回し関数みたいなもののことを言ってるんだろうが、
あれはグラフ簡約がたまたまメモ化の役割を果たし無駄が省けているためであって遅延評価だからではない。

そもそも速度で評価戦略を語ることがナンセンスだよ。
あれは(たらい回しみたいな)一部の計算を無駄なく書くのを簡単にするためのものだ。
無駄なく書くのが難しくなってる計算の方が多くね、ってのが遅延評価に対して意味のある批判だろうよ。

70 :デフォルトの名無しさん:2012/03/02(金) 13:11:35.99
>>69
>そもそも速度で評価戦略を語ることがナンセンスだよ。

別にそんな話はしてなくて、「先行評価より早いものがある」について具体例が知りたいだけ。
だから、総時間と混同してないか?って書いたんだがなあ。
どっかでの、Haskell=遅いって話のことなら俺は無関係。

71 :デフォルトの名無しさん:2012/03/02(金) 13:15:22.81
だからさ、評価戦略によって『評価するかどうか』が決まってからは遅延評価も先行評価も同じ道を辿るんだから、
評価戦略に対して「aはbより早い」とかいうのは論理的に間違ってるってこと。

72 :デフォルトの名無しさん:2012/03/02(金) 13:20:50.03
>そもそも速度で評価戦略を語ることがナンセンスだよ。
これはhaskellerの負け惜しみとかそう言うんじゃなくてさ、
速度と評価戦略が別次元の問題だってことを言いたいだけ。
haskellのたらい回しとcのたらい回しは記述が似てても、
『そもそもやってることが違う』んだから。

73 :デフォルトの名無しさん:2012/03/02(金) 13:37:52.45
遅延評価は計算量を減らす目的もあるけどそれが全てじゃないよね
それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし

割と手軽に計算量を減らせる(処理系にお任せ出来る)ってくらいだろう

無限リストとかを評価しちゃうと氏ぬのは言語に関係無いから
その辺はCでも配列でなく関数とかで仮想化するし

74 :デフォルトの名無しさん:2012/03/02(金) 13:45:42.93
>それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
いや、まったく同じ計算をするなら同じ処理時間になるよ。
ならないとしてもそれは遅延評価のせいではない。

75 :デフォルトの名無しさん:2012/03/02(金) 13:47:20.92
>遅延評価戦略が先行評価戦略よりも速くなることは有り得ない。
よくみると俺もこんな発言をしていた。
俺も論理的に間違っているということだな(キリッ

76 :デフォルトの名無しさん:2012/03/02(金) 13:51:12.30
>>64
ネタの投下も無しに贅沢な
それに、>>62はプリミティブな関数が自作出来るのが楽しいって言ってるだろ
python版出すなり、新しいネタ出すなりすれば良い


77 :デフォルトの名無しさん:2012/03/02(金) 13:54:12.03
>それに同じ計算量、無駄を省いたCの処理とかに敵うわけないし
というか『適うわけない』と思った根拠はなんなのだ?
論理的に同じ計算をするならあとはなんというか、言語の基礎体力だけの問題になるはずだが。
あれか、haskellではIntがボックス化されているからとかなんかそういうのか。

78 :デフォルトの名無しさん:2012/03/02(金) 13:56:34.33
>>74
>まったく同じ計算をするなら同じ処理時間になる
同じロジック書いても
遅延評価を実装するために発生するオーバーヘッドとかの影響で
まったく同じ計算(機械語レベルで)にはならないんじゃないの?

79 :デフォルトの名無しさん:2012/03/02(金) 14:03:36.00
>>77
>言語の基礎体力だけの問題
そうだよ、そういう話
例え同じロジックでもインタプリタ方式の方が遅いとかそういうの

Cは安全性を犠牲にしてでも速度優先するってコンセプトがあるわけだし

80 :デフォルトの名無しさん:2012/03/02(金) 14:11:15.32
>>-79までの中に、62が居るとのお告げがあった。

81 :デフォルトの名無しさん:2012/03/02(金) 14:18:12.44
>>78
遅延させることに意味がある場合、それはオーバーヘッドとは言わないんでは?
計算結果を明示的にキャッシュするのだってもちろんスペース喰うわけで。
そういうことじゃなくてGHCの実装の深いところに基づくオーバーヘッドだというなら、
俺にもよく分からないが、お前にはそれが有意な差であると合理的に説明できるのか?

82 :デフォルトの名無しさん:2012/03/02(金) 14:20:45.94
>>80
そのレスバグだろ
開始インデックスの指定漏れてんぞ

83 :デフォルトの名無しさん:2012/03/02(金) 14:35:31.40
>>81
意味有る無しに関わらずオーバーヘッドと言うよ
機械語レベルでの違いによるものなら大小に関わらず有意だよ

84 :デフォルトの名無しさん:2012/03/02(金) 14:38:40.45
>>83
呼ぶのか。なるほど。
それは明示的に計算結果をキャッシュするコストと比べてどうなの?


85 :デフォルトの名無しさん:2012/03/02(金) 14:39:21.82
このコストっては手間的な意味じゃなくてね

86 :デフォルトの名無しさん:2012/03/02(金) 14:41:06.81
あと機械語レベルで差が出るというソースは?
簡易なものなら是非見てみたい。

87 :デフォルトの名無しさん:2012/03/02(金) 14:44:46.65
無いと思うならそれでいいよ
haskellはcと同じ速度ってことでさ

88 :デフォルトの名無しさん:2012/03/02(金) 14:45:35.68
まあ説明できないことは最初から分かってたさ

89 :デフォルトの名無しさん:2012/03/02(金) 14:49:53.34
オーバーヘッドがあったとしても遅延評価には利点があるという話だったんだけど
ここまで速度に拘るとは思わなかったからね

90 :デフォルトの名無しさん:2012/03/02(金) 14:53:17.52
あるかどうかもよく分からないオーバーヘッドの話を持ち出したのはそちらではなくって?
まあね。実際俺もあるとおもうよ。オーバーヘッド。
話として持ち出すからには根拠を持っていてほしいなと思っただけさ。

91 :デフォルトの名無しさん:2012/03/02(金) 14:56:03.90
ちなみに俺がオーバーヘッドがあると思ったのは
単にゼロオーバーヘッドでの実装は無理だろうと思ったのと
「c言語 haskell 速度比較」とかでググッた結果を見たというだけ
流石に個々の速度比較の詳細までは知らない

逆にオーバーヘッドが無いってのを示してくれたらもちろん前言撤回するよ

92 :デフォルトの名無しさん:2012/03/02(金) 14:59:04.52
こんなスレにいる駄民がそんなことを示せるわけ無いじゃないか!俺のことだよ!

ていうかよくよく読み返すと>>78は疑問文だねえ。
俺が謝ったほうがいいのかも知れない。
だがわたしは(ry

93 :デフォルトの名無しさん:2012/03/02(金) 16:34:36.45
遅延評価って、一見全部読み込んでから一部だけ出力するって処理で、必要な分しか読み込まないってので、>>62の上のmyreverseはリストを反転する必要があるから、全部読み込んでるけど、下のaddlistをmytake 10 してる方は、最初の10要素分しか読み込まない
先行評価だと、全部読み込んでから始まるか、最初の10要素だけ読み込む様に書き分ける

ファイル処理とかで、書き分ける必要が無い事になる

とは言え、最近の言語なら、オブジェクトにその辺の処理を押し込んでそうだが


94 :デフォルトの名無しさん:2012/03/02(金) 16:37:16.86
オーバーヘッドつーか、評価機構の構造自体が違うのに、
全体の処理時間が同じなわけがないだろjk

95 :デフォルトの名無しさん:2012/03/02(金) 17:43:05.82
正格評価でもありとあらゆるところにdelayとforceを忍ばせれば
遅延評価になると思うんだけど
計算量が減るところだけ遅延評価にした方がやっぱりいいと思うんだよね

96 :デフォルトの名無しさん:2012/03/02(金) 20:31:03.15
>>93
そのかわり、ファイル読み込んで同じファイルに書き出すときとか
「あー、この辺で正格評価するべ」的なこと考えんといかんけどな

97 :デフォルトの名無しさん:2012/03/02(金) 23:50:52.90
配列のreverseくらいならC++でも一行だな
std::copy(in.rbegin(), in.rend(), std::back_inserter(out));


98 :デフォルトの名無しさん:2012/03/03(土) 00:36:28.38
最近の関数型って実装まで気にするような段階なんだな
はてなあたりの選民気取りが「haskellはCより速い(キリッ」とか言い始めたら俺もそろそろ関数型始めようかな

99 :デフォルトの名無しさん:2012/03/03(土) 05:11:01.91
速度稼ぐ必要があるコードだと結局はモナド頼りなんだろ?

関数型言語って名前捨てて”モナド型言語”とでも呼べばいいんじゃね?

100 :デフォルトの名無しさん:2012/03/03(土) 06:46:14.07
おめえらhaskell以外の話もしろよ

101 :デフォルトの名無しさん:2012/03/03(土) 06:54:33.70
遅延評価のコストについては、コンパイラの本とかに載ってることあるよ

102 :デフォルトの名無しさん:2012/03/03(土) 07:59:28.26
>>98 大学の研究のレベルから、一般はてな民が話題にするまで10年ぐらいだから、
おまえは常に10年遅れだけど、好きにすればいいと思うよwwww

103 :デフォルトの名無しさん:2012/03/03(土) 08:12:49.54
xmonadの影響で今になってX11プログラミングを始めた漏れが
8時(10分以上遅れ)をお知らせしますね

104 :デフォルトの名無しさん:2012/03/03(土) 09:12:49.53
10年遅れどころかMLなら40年遅れHaskell直系のMirandaからでも30年遅れだろ


105 :デフォルトの名無しさん:2012/03/03(土) 10:58:06.61
作ればあるもん

106 :デフォルトの名無しさん:2012/03/03(土) 13:05:49.24
>>104
登場時期が基準とかおもちゃじゃあるまいし

107 :デフォルトの名無しさん:2012/03/03(土) 13:19:05.21
ギークやらアルファブロガーやら呼ばれる人が話題する時点ではまだ玩具

それを使用する企業やそれなりの規模のオープンソースプロジェクトが
出始めるくらいから実用品だな

108 :デフォルトの名無しさん:2012/03/03(土) 14:01:18.50
Javaと心中するのは自由ですから、他人を巻き込もうと必死にならないでねw

109 :デフォルトの名無しさん:2012/03/03(土) 14:10:19.50
定番の必死認定

110 :デフォルトの名無しさん:2012/03/03(土) 14:43:35.56
このスレでの関数型言語って純粋関数型言語(Haskell,Mirandaとか)だけ?
非純粋関数型言語(Lisp,R,OCamlとか)も含むの?

Haskellはよく知らないけどCommon Lispは実用かなって思って

111 :デフォルトの名無しさん:2012/03/03(土) 15:00:07.62
アンチの脳内の都合で、その場により変わりますw

112 :デフォルトの名無しさん:2012/03/03(土) 15:05:20.65
>>111
あなたの認識ではどっちですか?

113 :デフォルトの名無しさん:2012/03/03(土) 15:07:01.59
関数型言語に定義なんてないし的当だよ

一般的な定義は

・関数を実行時に生成できる
・関数を引数として渡せる
・関数を関数の戻り値として返せる

だと思うけど、最近は勝手に

・変数に一度しか代入できない

とかルールを付け加えたり好きかっていう人が増えたから

114 :デフォルトの名無しさん:2012/03/03(土) 15:14:52.67
昔は、関数型言語と比べて手続き型言語は原始的で貧弱に思えたけど、
最近は手続き型言語もクロージャを取り込んで関数的にも書けるから、
そうなると実用上は手続き型言語で十分だと感じるけどな。

基本は手続き的に処理を書きつつ、コレクションの操作だけ map や filter,
reduce を使って関数的に書く。他人にも読みやすいコードを書こうとすれば
最終的にはそのくらいのところに落ち着くと思うけど。

>>108 みたいな「仮想ドカタ」を煽るのは現実が見えていないと思うなあ。
今時、職業プログラマだって C, Java だけじゃなくて JavaScript も Ruby も使うよ。
JavaScript で言えば、JQuery なんて発想がかなり関数的だと思うけど。
XML を対象に XPath でパターンマッチかけて filter やら map やら。
ほとんどそういう処理。

115 :デフォルトの名無しさん:2012/03/03(土) 15:19:10.49
>>113
上の3つだとJavaScriptやC++(functor)、C#(delegate)あたりも含まれるな
初代スレの1はむしろ参照透過性、変数に一度しか代入できないことの方を嫌ってるように見える

116 :デフォルトの名無しさん:2012/03/03(土) 15:19:35.75
>>113
そうなんだよね。僕もそのくらいが「関数型言語」だと思うんだけど、
逆に、そのくらいはもう、手続き型言語にも取り込まれてるんだよね。

だから、そんなのはもう関数型言語「ならでは」の長所になってない。
逆に、末尾再帰除去とかカリー化とかになってくると、まだ差がある。

とはいえ >>114 くらいのスタイルだと、
別に末尾再帰除去やカリー化がなくても、そこまで困らないけどね。

117 :デフォルトの名無しさん:2012/03/03(土) 15:27:07.99
javascriptはschemeをC言語っぽい文法に直したものだろ
昔から関数型言語と言われているよ

118 :デフォルトの名無しさん:2012/03/03(土) 15:27:17.91
Haskellなどで言う「関数」は、集合・写像ベースの概念だから、変数の書き換えに依存しないやり方のほうが関数を率直に表現出来るってだけの話だ。
Cにも同じ字面の「関数」があるが、関数型言語の関数と区別したい時は、サブルーチンと呼んだ方が実態に近い。

119 :デフォルトの名無しさん:2012/03/03(土) 15:33:16.95
良い所とか取り込んで明確な境界が無くなくなってる面があるんですね

研究目的の言語の成果が実用目的の言語に適用されたと考えたら
必ずしも実用である必要は無いのかもしれませんね

120 :デフォルトの名無しさん:2012/03/03(土) 15:33:41.38
>>117
それは違うかな。
「言われている」ではなく、
関数型言語を知っている人たちが JavaScript は関数型言語っぽいと
「言っている」が正しい表現じゃないかな。

少なくとも、
Ecma-262 の 4 Overview には
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment.

と書いてあるんだから、何言語かと一つに決めるなら、
明らかにオブジェクト指向言語でしょ。

121 :デフォルトの名無しさん:2012/03/03(土) 15:40:05.10
>>119
「何ができるか」って意味なら差はどんどん無くなってる
だが、他人のコードを読むときには「何ができないか」ってのも重要で、
そこが手続き型言語と関数型言語では違う

わざわざコードを読んで副作用が無いか目でチェックしなくても
言語仕様で保証されてるなら読むのが楽になる
OOPのアクセス修飾子なんかと同じだな

122 :デフォルトの名無しさん:2012/03/03(土) 15:42:52.61
>>120
http://www.ecmascript.org/es4/spec/overview.pdf
ここの4ページにはこうある

ECMAScript 4th Edition (ES4) is a multi-paradigm programming language that is evolved from the
3rd Edition2 (ES3), which in turn is based on JavaScript3, a programming language for the web developed at
Netscape Communications Corporation starting in 1995.

ES3 is a simple, highly dynamic, object-based language that takes its major ideas from the languages Self
and Scheme.

123 :デフォルトの名無しさん:2012/03/03(土) 15:49:23.32
http://ja.wikipedia.org/wiki/ECMAScript

ECMAScript 4 は過去2回仕様作成が挑戦されたが、仕様がまとまらず、失敗に終わっている。

124 :デフォルトの名無しさん:2012/03/03(土) 17:26:19.51
何でも関数型言語にしたがる香具師がいるな…

125 :デフォルトの名無しさん:2012/03/03(土) 20:52:56.07
関数型言語の判断基準について、整理してみた。大きく3つのグループに分類できる。
・関数型言語(誰も文句無し)
・関数型プログラミングが可能な言語
・それ以外の手続き型言語

 FP
  ---- 壁0. 変数の壁 ----
 Haskell
  ---- 壁1. 純粋性(副作用)の壁 ----
 SML/OCaml
  ---- 壁2. 型推論の壁 ----
 Scheme
  ---- 壁3. 末尾再帰最適化の壁 ----
 ========<< 越えられない壁 >>========
 Smalltalk/Ruby
  ---- 壁4. 条件判定式/局所宣言式の壁 ----
 Perl/Python/JavaScript
  ---- 壁5. クロージャ/ラムダ式の壁 ----
 ========<< 越えられない壁 >>========
 C/C++/Java...etc

なお、このカキコは「関数型言語Part5」スレの過去カキコ(283-335)を編集したもの
議論の参考になればと思う

126 :デフォルトの名無しさん:2012/03/03(土) 21:14:44.32
末尾再帰最適化とか、マジ関係無いだろ
実装上の話だろ

127 :デフォルトの名無しさん:2012/03/03(土) 21:47:46.75
GCC(C/C++) → 末尾再帰最適化あり

あとC++のboost::lambda(ラムダ式)とはどうなんだろうか
言語自体に直接ラムダ式があるわけじゃないけど

boost::lambdaとスマートポインタでクロージャも作れるらしい

壁4はよく分からない

128 :125:2012/03/03(土) 22:07:55.69
>>126
関数型言語にとってリストが最も基本的な複合データ型であることは、
誰もが認めることだろう
でも末尾再帰最適化が実装されていない言語の多くでは、
可変長配列(RubyであればArrayクラス)でリストを代用している
もしも、これを真面目に「ドット対の連なり」としてリストを定義して
その操作を再帰関数で定義した場合、ちょっとしたデータ量であっても
簡単にスタックオーバーフローが発生してしまう

だから、関数型言語で書かれたコードを末尾再帰最適化が実装されていない言語へ
移植しようとした場合、再帰ではなくfor/while文のような手続き型構文を使わざるをえない
これは(末尾再帰最適化という)実装がプログラミングスタイルに大きな影響を与えるという
典型的な一例であると思う

129 :デフォルトの名無しさん:2012/03/03(土) 22:11:49.10
>>128
>関数型言語にとってリストが最も基本的な複合データ型であることは、
>誰もが認めることだろう

認めねーよ。
それも実装上の話だろ。


130 :デフォルトの名無しさん:2012/03/03(土) 22:12:39.97
>>128
でも、機械を上手く動かすためのコンパイラの技術だろ
関数型言語の定義に含めることには違和感がある

131 :デフォルトの名無しさん:2012/03/03(土) 22:41:56.15
リストは副作用を嫌う関数的プログラミングがLISPから借りてきた実装上の「逃げ」。
末尾再帰最適化でループの代用にしたのと根っこは同じ。

132 :デフォルトの名無しさん:2012/03/03(土) 22:56:45.86
ま、実用を目指したコンピュータ言語なんてものは
全てが実装上の話になってしまうんだけどな。


133 :デフォルトの名無しさん:2012/03/04(日) 01:14:03.00
末尾再帰なんてC言語の教科書で知ったから
関数型言語と結びつけるイメージが全く沸かない

134 :デフォルトの名無しさん:2012/03/04(日) 03:15:06.28
128は本質をついている。
リストは再帰的データ構造を持つので、
再帰を反復の記述にとる関数型とは相性がいい。


135 :デフォルトの名無しさん:2012/03/04(日) 03:45:32.27
関数型言語にとって副作用が無いことは
本質的なことなの?
そうだと言える根拠とかあるの?

MLやHaskellが設計された頃の流行りだった
だけじゃないの?
”副作用は悪”っていう思想は、古いアルゴリズムの
教科書にはよく載ってる

136 :デフォルトの名無しさん:2012/03/04(日) 05:47:41.38
>>134
反復もリストも、圏論の抽象力の前では、単なる実装上の都合だよ


137 :デフォルトの名無しさん:2012/03/04(日) 05:50:20.88
>>125
壁3は本質的じゃないね。それよりも

--- 壁3'. 宣言性(記述順序に左右されない)の壁

を入れたほうが関数プログラミングの本質に近づくと思うのだが。

138 :デフォルトの名無しさん:2012/03/04(日) 09:08:06.01
>>137
宣言という言葉をあまり狭義に使うのはどうかな。
IBMの簡易言語RPG(現在バージョンはIVかな)は
Decision Tableを使って制御を行っているので、
昔は宣言型言語に分類されていた。同じ宣言でも
こうまで異なると問題だ。

139 :デフォルトの名無しさん:2012/03/04(日) 09:23:41.58
定義のことを宣言って言ってるだけじゃね?

英語でどうなんだか知らんけど。

140 :デフォルトの名無しさん:2012/03/04(日) 10:33:53.88
CTMCPすら知らずに妄想する隔離スレか。

141 :デフォルトの名無しさん:2012/03/04(日) 10:43:48.80
抽象度が高いことを示すコードが出てないんだが
pythonに作れなくて、Haskellに作れるものって何がある?
とりあえずHaskellでif関数自作できるとかはよく見かけるが


142 :デフォルトの名無しさん:2012/03/04(日) 11:05:05.88
if関数ったって組み込みの(型クラスを含む)条件分岐機構を使わずには書けんだろ。

143 :デフォルトの名無しさん:2012/03/04(日) 11:39:11.04
>>140知らなかったので、検索して目次を眺めてみたが、スレタイのような議論をするなら読むべきかと思った。

144 :デフォルトの名無しさん:2012/03/04(日) 11:44:07.10
>>142 ARMなら条件分岐なしのコードにコンパイルできるんでね?

145 :デフォルトの名無しさん:2012/03/04(日) 11:48:48.15
>>142
へ?
パターンマッチとガードでごく普通の関数として書けるけど
型クラスなんて大仰なもん使わんよ
と言うか、ifが普通に書けるのが遅延評価と関数もファーストクラスの値っていう特徴の賜物じゃないか

if flg t f | flg == True = t
      | flg == False = f

関数型言語は必ず値を返すって性質上、if elseしか許されないが

先行評価のだと、両方とも関数を受け取った時点で評価前に実行されちゃうから正しく動かない
(評価前に両方実行されて、評価後にどちらかが実行される)



146 :デフォルトの名無しさん:2012/03/04(日) 12:02:53.04
つーか、関数型言語の利点と言えば、バグが無いことを保障できるって事じゃね?
数学の証明で公式が永遠に正しいことを保障するのと同じで、関数にバグが無いこと保証できれば、その関数の使い方を間違わなければ、その関数が原因のバグは無いと保証できる



147 :デフォルトの名無しさん:2012/03/04(日) 12:08:56.91
分岐を関数で表現するのは難しくない。
T(x,y)=x
F(x,y)=y
IF(c,x,y)=c(x,y)
最後のは糖衣構文で、cはTかFが入る。

問題はこれを先行評価すると、
xの評価、yの評価、どっちかの選択と
進行してしまい、無駄な評価またはやっては
ならない評価をしてしまうことになる。

遅延評価では必要になるまで引数は評価されず、
c(x,y)にはxかyの一方しか含まれないので、
上記の問題は起こらない。

148 :デフォルトの名無しさん:2012/03/04(日) 12:10:17.75
すでにコメントされていたか。

149 :デフォルトの名無しさん:2012/03/04(日) 13:14:45.06
元ネタ書いたの誰か知らんが >>125 は酷すぎる。
上下に並べている壁が、それぞれ軸が違う。
壁2は型システムの問題だろ。
壁4も意味不明。
末尾再帰最適化の有無を越えられない壁とか書いてるのもアホ丸出し。
末尾再帰になるような処理は手続き型なら最初からループで書く方が自然。
だから要らないだけ。

150 :デフォルトの名無しさん:2012/03/04(日) 13:24:51.24
型推論とオブジェクトの相性の悪さが問題だな
誤解を恐れずざっくり切るなら、
オブジェクト指向が適している分野に関数型言語は不適。

151 :デフォルトの名無しさん:2012/03/04(日) 14:09:20.29
せんせー、OCamlさんが泣いてます

152 :デフォルトの名無しさん:2012/03/04(日) 14:12:58.24
>>145
パターンマッチがすでに条件分岐機構なんだが…
条件分岐機構使って条件分岐書き換えてドヤ顔されてもな。

153 :デフォルトの名無しさん:2012/03/04(日) 15:30:46.23
>>147
Smalltalkの宣伝乙w

154 :デフォルトの名無しさん:2012/03/04(日) 16:33:15.37
一般論を書いたつもりだがどの部分がsmalltalk?


155 :デフォルトの名無しさん:2012/03/04(日) 16:34:41.05
一般論を書いたつもりだがどの部分がsmalltalk?


156 :デフォルトの名無しさん:2012/03/04(日) 17:05:02.03
T(x,y)=xがTrueクラスの定義
F(x,y)=yがTrueクラスの定義
IF(c,x,y)=c(x,y)がメソッドの動的束縛に相当した実装になっている。

具体的には、if式はifTrue:ifFalse:というメソッドで実装されている。
これがTrueクラスでは、第1引数のクロージャを評価するよう定義されていて、
Falseクラスでは、第2引数のクロージャを評価するよう定義されている。

クライアントコードでは例えば
x = y ifTrue: [do something] ifFalse: [ do something else]
というメッセージ式を評価する時に、
x=yがtrueならTrueクラスのifTrue:ifFalse:が束縛されて
第1引数の[do something]が評価される。([ ]で囲まれたものはクロージャ)
x=yがfalseならFalseクラスのifTrue:ifFalse:が束縛されて
第2引数の[do something else]が評価される。


157 :デフォルトの名無しさん:2012/03/04(日) 17:09:34.66
>>154
Smalltalkで勉強したからそう言っただけだろ
プログラム言語が開発される以前に、ラムダ理論で
既に知られていたなんて知らなんだろ

158 :デフォルトの名無しさん:2012/03/04(日) 17:15:42.28
>>157
いや、知ってたよ。
つーか、俺自身がSmalltalkより先に型なしラムダ計算やってたし。

現代の実用言語では>>147の定義の実装がSmalltalkに色濃く残っている
というだけの話にそこまで突っかかるかね?
関数型の人(特にLISP系とHaskell系)ってそうやって上から目線で小馬鹿にするから
逆に相手から冷笑されるんだよ。

159 :デフォルトの名無しさん:2012/03/04(日) 17:58:15.02
悪いけどJava屋の俺からするとSmalltalkの人も同じだよ。
>上から目線で小馬鹿にする


160 :デフォルトの名無しさん:2012/03/04(日) 18:26:49.16
どっちも原理主義者で純血主義者ですもんね

161 :デフォルトの名無しさん:2012/03/04(日) 18:31:16.56
ハスケラやSmallTalkはわかるがLISPerは純血主義の対極だろw


162 :デフォルトの名無しさん:2012/03/04(日) 18:32:18.55
LispもHaskellも習得のコストさえ無視できれば
言語自体には使う価値があるけど
Smalltalkには何も無い

163 :デフォルトの名無しさん:2012/03/04(日) 18:35:31.08
よほどSmallTalkに叩かれた暗い過去があるんだねw
もしかしてIDEスレじゃね?ぷぷぷ あのスレのジャバ厨は悲惨だったww

164 :デフォルトの名無しさん:2012/03/04(日) 18:38:27.75
そんなにスモールトーク叩きたければ別スレ立てれば?

スレ違いウザw よほど悔しかったんだねww

165 :デフォルトの名無しさん:2012/03/04(日) 18:52:32.40
Smalltalkを頭ごなしに馬鹿にする奴でSmalltalkをまともに使ったことある奴を見たことがない。

166 :デフォルトの名無しさん:2012/03/04(日) 18:52:47.01
Pharoがゴミ過ぎて笑える
玩具で喜んでて滑稽

167 :デフォルトの名無しさん:2012/03/04(日) 19:25:33.87
負け犬>>166の遠吠え

168 :デフォルトの名無しさん:2012/03/04(日) 19:31:38.94
「俺は世間の奴らとは違う」という自尊心を満たすために
マイナーなものを選択するという変な層がいるから性質が悪い。

そういう人にとっては「世間はJava」でなければ困るわけだ。
「RubyでもJavaScriptでも普通に関数的にも書ける」と言われると

「中には手続き型言語で関数的に書いている人もいるだろうが、
それは(俺と同じ)一部の先進的な層で、世間一般はJavaだろ」

という主張をしてくる。自分が特殊でありさえすれば何でもいいというね。


169 :デフォルトの名無しさん:2012/03/04(日) 19:32:43.55
自己紹介乙としか言いようがないw

170 :デフォルトの名無しさん:2012/03/04(日) 19:36:03.72
関数型言語由来の機能で便利なところってのはクロージャとラムダ。
それはもう手続き型言語で普通に使える。

関数型言語の便利な機能は、
既にメインストリームである手続き型言語に取り込まれ、
今では世間一般のプログラマも当たり前に関数的な書き方をするようになっている。
めでたしめでたし。

現実的には、もうこれで終了してる話だろ。

171 :デフォルトの名無しさん:2012/03/04(日) 19:40:26.99
パターンマッチは便利なので手続き型言語にも取り込んでほしい

で、パターンマッチは再帰と相性良いので、
ついでに末尾再帰最適化も取り込んでほしい

汎用的な関数から具体的な関数を定義するのに
カリー化は便利なので是非とりこんで欲しい

172 :デフォルトの名無しさん:2012/03/04(日) 19:44:07.49
>>171
末尾再帰最適化はC/C++でやってるし
上でも出てるけど関数型とは無関係

173 :デフォルトの名無しさん:2012/03/04(日) 19:45:55.21
>汎用的な関数から具体的な関数を定義するのに
>カリー化は便利なので是非とりこんで欲しい

こういう奴にカリー化という包丁を渡すと
オレオレ高階関数ライブラリを作り始めて
メンテナンス不可能なコードを量産されるのがオチ。

174 :デフォルトの名無しさん:2012/03/04(日) 19:46:26.79
逆にダックタイピングは便利なので関数型言語にも取り込んでほしい


175 :デフォルトの名無しさん:2012/03/04(日) 19:46:46.00
あ、型推論できないから取り込めませんね。失礼

176 :デフォルトの名無しさん:2012/03/04(日) 20:08:21.74
>>175
構造的部分型で良ければOCamlで出来るけどな > ダックタイピング
もちろん型推論もできる

177 :デフォルトの名無しさん:2012/03/04(日) 20:09:50.08
>>174はダックタイピングの誤用だな

178 :デフォルトの名無しさん:2012/03/04(日) 20:10:17.57
>>172
パターンマッチ無いのに末尾再帰最適化だけ出来ても
正直そんなに嬉しくない

179 :デフォルトの名無しさん:2012/03/04(日) 20:13:10.92
パターンマッチと再帰は無関係だし
視野が狭すぎ

180 :デフォルトの名無しさん:2012/03/04(日) 20:13:25.44
代数的データ型使わないのにパターンマッチがあっても何も嬉しくない

181 :デフォルトの名無しさん:2012/03/04(日) 20:34:02.85
代数データ型と再帰構造は直交する概念だろw
どこまで視野が狭いんだかw

182 :デフォルトの名無しさん:2012/03/04(日) 20:41:34.43
>代数データ型と再帰構造は直交する概念だろw
>どこまで視野が狭いんだかw

何それ?
代数データ型を使って
再帰構造を表現することはできないって事?


183 :デフォルトの名無しさん:2012/03/04(日) 20:52:20.17
便利な機能が全部ある言語を選んだらHaskellになった

184 :デフォルトの名無しさん:2012/03/04(日) 20:56:43.28
いらない機能を全部つめこんだらSmalltalkになった

185 :デフォルトの名無しさん:2012/03/04(日) 21:41:23.88
>>181
パターンマッチと再帰は直交する
代数的データ構造と再帰は直交する
パターンマッチと代数的データ構造は直交しない


186 :デフォルトの名無しさん:2012/03/04(日) 21:48:35.10
>>156
ありがとうございます。
Smalltalkって、C++やJavaの先祖くらいにしか思っていなかったけれども、
結構おもしろいですね。FPとOOPはレイヤーを積み重ねると互いに相手を
模倣できるという話を聞いたことがあるが、Smalltalkを学習すると
その意味がわかるのではないかという気がした。

187 :デフォルトの名無しさん:2012/03/04(日) 21:58:32.05
あちこちのスレを読んでいると、
Smalltalkの説明に対してだけ、丁寧な言葉でお礼が書き込まれることが多い。
この傾向が、とても面白いと思う。

188 :デフォルトの名無しさん:2012/03/04(日) 22:04:24.12
> 関数型言語由来の機能で便利なところってのはクロージャとラムダ。
> それはもう手続き型言語で普通に使える。
体験するにはどういう言語がいい?知っている範囲では、
C++11: lambdaはあるが、スコープにかんするオプションがいっぱいあって
 頭痛がしてきた。
Fortran: Intel拡張に限り、内部手続きが渡せるのでクロージャが部分的に
 はあるといえる。うっかり使ってしまうとSparcマシンに移したときに
 がっくりくる。




189 :デフォルトの名無しさん:2012/03/04(日) 22:25:37.67
結局はどの言語を使うかではなく、関数型的な考え方書き方が出来るかどうか、が問題になってくんだろうかね?

190 :デフォルトの名無しさん:2012/03/04(日) 22:39:54.94
できなくても、ほとんど問題がないのが現実

191 :デフォルトの名無しさん:2012/03/05(月) 00:18:07.30
>>166
Smalltalkといっても、実験的要素の多いSqueakやPharoとかばかりじゃなく、
VisualWorksとかDolphinみたいに商用志向の比較的作り込んである処理系もあるよ。

192 :デフォルトの名無しさん:2012/03/05(月) 01:21:20.77
マルチスレッドでオブジェクト指向型言語の限界が見えてきたから、関数型言語が注目されだしたんじゃなかったっけ
まあ、遅延評価とマルチスレッドプログラミングは相性が悪いらしいので、最適化でマルチスレッドの時だけ正格評価にしようかという話はどっかで見た気がするが

それでも、純粋な関数に関しては


hoge リスト1 リスト2 = (force リスト1) `par`
               (force リスト2) `par`
以下は普通のhoge関数と同じ

force [] = ()
force (x:xs) = x `pseq` force xs

これでおk
※ghcバージョンによって、par/pseq関数を読み込むモジュールの場所がまちまち・・・

マルチスレッドの時だけ正格評価になるなら、force関数書かなくて良くなるだけで、たいした手間でもない
同期もデッドロックも気にしなくて良いのが楽
(スレッド数は実行ファイルにランタイムへの指示として指定する)



193 :デフォルトの名無しさん:2012/03/05(月) 08:59:09.17
>>192
実行ファイル単位でしかスレッド数を決められないのか
イマイチだな…

194 :デフォルトの名無しさん:2012/03/05(月) 10:15:45.33
一応増やせはするんだけど、
一度増やすと今度は減らせないんだよねえ・・・
そのうち改善はされるかもしれないのだけど

195 :デフォルトの名無しさん:2012/03/05(月) 11:03:41.23
一般に一旦プロセスに割り当てたリソースをひっぺがすのは難しい

196 :デフォルトの名無しさん:2012/03/06(火) 00:05:57.69
並列計算でスレッド数をcpuのコア数以外にすることがあまりないので、
よくわからないのだが、OpenMPのようにいったんスレッドを畳んで、
スレッド数を指定して再度スレッドを起動するのは難しいのかな。

リストなので単純にはいかないとおもうが、
!$omp parallel map
ys = map f xs
!$omp end parallel map
とかできるようになると結構うれしい。

197 :デフォルトの名無しさん:2012/03/06(火) 12:16:08.90
ユーザスレッドを駆動するネイティブスレッド数の話だろ?
なら、動的な変更はそれほど必要ないんじゃ?

198 :デフォルトの名無しさん:2012/03/21(水) 18:05:47.79
不毛だな

199 :デフォルトの名無しさん:2012/03/21(水) 18:25:40.67
ふもっふ

200 :デフォルトの名無しさん:2012/03/22(木) 18:21:07.48
catコマンドって、意外と奥が深いんだな・・・
こんなの見つけたんだけど(haskell)、他の言語だとどう書くの?

A cat in Haskell
http://madscientist.jp/~ikegami/diary/20050728.html#p01

ちなみに、このページはここからリンクされてた
Haskell
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=Haskell

cat(オプション付き)って所


201 :デフォルトの名無しさん:2012/03/22(木) 22:41:57.77
>>200
オプション無しの、単純に引数のファイルを繋いで出力するだけのものなら
AWK、Perl、Ruby辺りはアホみたいに短いな
(コマンド名含めて数バイト)
流石に複雑なオプション含むとそこまで差は出ないかも知れんが


202 :デフォルトの名無しさん:2012/03/23(金) 09:05:32.57
>>200

正規表現を並べただけだけど、Perl だとこんなかんじ。
http://ideone.com/BCiGc

とりあえず -u と -v のメタ表示以外サポート(もとの Haskell でも
サポートしてなかったので)。



203 :デフォルトの名無しさん:2012/03/23(金) 12:57:34.26
ちなみに Snow Leopard の cat には -A -E -T が存在しなかった。
Lion 以降?


204 :デフォルトの名無しさん:2012/03/23(金) 13:38:23.23
>>201
オプション無しだとスクリプト言語よりは長いものの、静的型言語としては短いだろうな
と言うか、ここの一番上のruby版catは短すぎてなにやってるのか分からん
下2つのcatコードの方がコードの意図を読み易いな

http://www2.atwiki.jp/kmo2/m/pages/17.html


import System.Environment

main = getArgs >>= mapM readFile >>= putStrLn.unlines

奇しくも、do構文で見えにくい状態移管が見えやすい形になった



205 :デフォルトの名無しさん:2012/03/23(金) 14:00:00.76
とりあえず >>200 のバグ。

1. -v と -t の結果が同じになる。本物の cat は -v では TAB を変更しない。
2. 入力が改行で終わっていないときに、勝手に改行を追加してしまう。
3. -e をつけたときに、入力が改行で終わっていなくても最後に $ をつける。


206 :デフォルトの名無しさん:2012/03/23(金) 14:18:13.40
>>204
いや、静的だろうが何だろうが、この半分の長さで書けるでしょ。
もともとの >>200 が、シンプルに書く気がないみたいだし。


207 :デフォルトの名無しさん:2012/03/24(土) 00:35:00.64
>>204
> while gets do puts $_ end
これのことか?Perlじみた動きをするコードだね

getsは一行入力する
EOFならnil、入力があればそれを文字列型として
グローバル変数 $_ に突っ込むと共に、戻り値としても返す

Rubyの文字列型は必ず真であり、逆にnilは必ず偽なので
while gets は「EOFになるまで毎行を $_ として繰り返す」イディオムになる
あとはそれをputsで出力してるだけ

208 :デフォルトの名無しさん:2012/03/24(土) 02:18:53.77
>>207
それ自体は分かるよ
スクリプトだからなんだろうけど、標準入力とファイル読み込みの区別が無くて戸惑う
どこでファイル読んでるの?って


209 :デフォルトの名無しさん:2012/03/24(土) 03:35:25.94
昔はプログラム側でファイルを開いたりしないものだったので、
たんに伝統的なやり方とも言える。


210 :デフォルトの名無しさん:2012/03/24(土) 13:41:01.22
>>208
? 標準入力とファイル読み込みの区別はむしろしっかりされてるコードだと思うけど…
ファイルからの読み込みならいきなりgetsなんて書かないよ
その場合はファイルを開いて、それに対してメソッド呼ぶのが基本
標準入力から読むからこそいきなりgetsを書く
まあ確かにgetsの読み先をファイルに繋ぎかえることも出来るし
逆に標準入力をIOオブジェクトとしてメソッド呼ぶとかも出来るけど
このコードではそんなことしてないっしょ?

211 :デフォルトの名無しさん:2012/03/24(土) 13:43:10.83
ああ、ごめんそゆことか
標準入力じゃなくてARGFからの読み込みの話だったね

ええとgetsは既定ではARGFから読む
んで、その内容はファイルを渡していないなら標準入力、渡されればそのファイルを全て繋いだものになる

212 :デフォルトの名無しさん:2012/03/24(土) 13:45:09.34
多分Perlの<>辺りがARGFの由来だろうなあ

213 :デフォルトの名無しさん:2012/03/24(土) 14:39:52.21
>>211
HPに説明があったから良かったものの、所見であのコードだけ見てたら混乱してた
個人的には、>>204のページ探してるときに見つけた

http://uch-x40.seesaa.net/article/22908221.html
こっちのページのやり方の方が好きかな

このページのprintをputsにするだけで問題解決するんじゃないか?と思ったので、久しぶりにruby入れて試してみたら、
予想通り解決した

puts ARGF.read

これで、

>ruby cat.rb mycat.hs myecho.hs
import System.Environment
import System.IO

main = getArgs >>= mapM readFile >>= putStrLn.unlines
import System.Environment

main = getArgs >>= putStrLn.unwords

Haskell版と、ちょっと挙動が違うけど・・・
(Haskell版のputStrLnをputStrに変えれば同じになるけど、どっちが正しい挙動なんだろ)


214 :デフォルトの名無しさん:2012/03/24(土) 14:55:21.83
あー・・・ごめん
ruby版、問題解決してないや
EOFで改行されないから、
import System.Environment
import System.IO

main = getArgs >>= mapM readFile >>= putStrLn.unlines[EOF]<-ここにEOFがある

この条件だと下のような表示になる

import System.Environment
import System.IO
↓ここから次のファイルが始まる
main = getArgs >>= mapM readFile >>= putStrLn.unlinesimport System.Environment

main = getArgs >>= putStrLn.unwords


215 :デフォルトの名無しさん:2012/03/24(土) 14:57:07.40
実行結果の書き直し・・・半角スペースは消えるんだった・・・orz

import System.Environment
import System.IO
                                   ↓ここから次のファイルが始まる
main = getArgs >>= mapM readFile >>= putStrLn.unlinesimport System.Environment

main = getArgs >>= putStrLn.unwords



216 :デフォルトの名無しさん:2012/03/24(土) 18:31:27.36
>>213-215
率直に言う

 関数型言語が使える使えないうんぬんの前に、常識的な(日本語の)文章表現を使えるようになれ

単にコードをコピペしただけで、自分の意図が相手に通じると考えるな
まともなヤシなら以下のような推論を自然に行って、それを文章で表現できる

・.... を期待して ..... という条件で (* 仮説1 *)
・..... というコードを試したが.....となり、期待にそぐわなかった -- (* 実験1 *)
・おそらく ..... が原因ではないかと思う (* 帰納1 *)
・そこで、新たに .... を期待して ..... という条件で (* 仮説2 *)
・..... というコードを試したところ .....となり、期待どおりの結果を得た -- (* 実験2 *)

ここまで言って分からなければ、お前さんは重症の「ハスケラ症」患者であり、
本人には自覚できない深刻なコミュニケーション不全の状態にある
とっとと隔離病棟(=Haskell本スレ)に戻ってオナニーでもしてるのがお似合い

217 :デフォルトの名無しさん:2012/03/24(土) 19:37:53.91
このスレが隔離病棟だという認識がない、ってあたりが重症だなw

218 :デフォルトの名無しさん:2012/03/27(火) 06:31:27.90
型は制約 #プログラミング初心者のミス


Zermeloを初心者呼ばわり、ワロスw

219 :デフォルトの名無しさん:2012/03/27(火) 08:06:51.40
型付集合論自体がラッセルの逆説を回避するための制約ですし.

220 :デフォルトの名無しさん:2012/03/27(火) 10:42:27.74
disることでしかアイデンティティを保てない可哀相な奴なんだよ。

221 :デフォルトの名無しさん:2012/03/27(火) 10:47:08.52
オブジェクト指向 #プログラミング初心者のミス ←これとか

222 :デフォルトの名無しさん:2012/03/27(火) 20:07:43.04
いやオブジェクト指向は糞

223 :デフォルトの名無しさん:2012/03/28(水) 15:50:23.80
そうそうクラスとかインスタンスとかメソッドとかの用語を使う言語は100%糞!

224 :デフォルトの名無しさん:2012/03/28(水) 17:07:26.99
いまどきは、組み込みみたいなリソースの厳しい案件でも使うけどな。

225 :デフォルトの名無しさん:2012/03/28(水) 17:35:45.66
オブジェクト指向言語は使わなくても、設計では使うだろ

226 :デフォルトの名無しさん:2012/03/28(水) 21:01:50.69
制御系やっているけど、OSはRedHatなのに、言語はCとアセンブラだ。

227 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/01(日) 18:56:13.23
俺はよく知らんのだが、関数言語アンチとんの連中なの?
twitterやブログでも写真でもいいから見せてくれないか?

228 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/01(日) 18:56:55.71
オブジェクト指向とは別名スパゲティ指向だと言われてる。

229 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/01(日) 19:07:51.16
ねーよ

オブジェクト指向でスパゲティにするような奴は、ループ構文使おうが、例外を使おうが
スパゲティを作るんだよ。馬鹿は何を使っても同じ。

230 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/01(日) 19:34:44.70
gotoやグローバル変数全盛時代、スパゲティコード生産しまくってた連中は
自分達がスパゲティ製造者だという自覚がなかったという

gotoでスパゲティにするような奴は、関数呼び出しを使おうが
スパゲティを作るんだよ、とか言ってね

231 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/01(日) 21:02:29.24
お前ら立派なスパゲティ職人になれよ。
一芸に秀でりゃ食っていける。

232 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/02(月) 05:53:15.86
関数型言語は別名ゴルフ指向言語と言われているなw

233 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/02(月) 07:10:20.20
>>230
>gotoでスパゲティにするような奴は、関数呼び出しを使おうが
>スパゲティを作るんだよ、とか言ってね

いや、まさにその通りだろ。


234 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/02(月) 07:20:22.37
スパゲティで塩やきそばを作ると結構いける

235 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/02(月) 13:11:51.33
>>230
スパゲッティ・コードというのは、ウケ狙いの後付表現に過ぎないからな。

gotoを使ったからスパゲッティになった、なんていう理屈だと、
あと10年くらいして改善された手法が一般的になったら、
今コード書いてる連中は殆どスパゲッティメーカーになってしまう。

236 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/02(月) 19:28:12.79
スゲパティシエ

237 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/02(月) 20:05:39.34
>>235
いや、だから関数型言語使ってる連中がOOP使ってる連中に
「お前等スパゲティコード書いてるぜ」って言ってるんだろ?

238 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/03(火) 12:58:40.32
スパゲティコードは読み辛く、読み解ける人は限られていた
一方、関数型言語のコードはそもそも読める人が限られていた

広まるといいですね関数型言語

239 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/03(火) 13:30:15.51
関数型だって普通にスパゲッティになるしw

240 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/05(木) 12:51:22.26
haskellのdo内はなぁ。。。 関数型スパゲティの宝庫だね。
ナポリタンにしますか?ミートソースにしますか?それとも、カルボナーラにします?

241 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/05(木) 20:19:43.36
何故Haskellのdo内でスパゲティになるか
理由を>>240は説明できないだろう

242 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/05(木) 21:01:04.36
関数型言語に馴染まないものを無理に突っ込んだ悪足掻きだからさ
生まれ付いての汚れ役だね

243 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/05(木) 21:07:23.34
doはただの関数合成の構文糖なんだが
関数の合成が関数型言語に馴染まないとは面白いことを言うなぁ

まあ、>>242はdo構文を普通の関数合成の表記に
書き直す事すらできないだろうけど

244 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/05(木) 21:14:39.14
流石は関数型言語ユーザー様
上から目線が板に付いてますねw

245 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/05(木) 21:35:11.51
永遠に学習しない態度が板に付いている奴はほんとカスだな

246 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/05(木) 21:43:45.64
>理由を>>240は説明できないだろう
>書き直す事すらできないだろうけど
>永遠に学習しない態度が

決め付けも大好きみたいすねw

247 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/07(土) 01:09:28.66
構文糖衣が必要なのは相性が悪いからじゃないの?

248 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/07(土) 01:20:29.83
良く使うから構文糖が用意されるって話は分かるが
相性が悪いから?なにそれ?

じゃあ何か。C言語で x=x+1 を x++ と書けたり
*(x+1) を x[1] と書ける構文糖が用意されてるのは、
C言語がインクリメントや配列と相性悪いからか?

249 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/07(土) 05:35:33.68
>>248
> じゃあ何か。C言語で x=x+1 を x++ と書けたり

その2つが同じセマンティクスだと思っているのなら
もう二度とコードを書かないほうがいいぞw

250 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/07(土) 06:01:26.63
x86ならおんなじじゃないの?

251 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/07(土) 07:41:13.84
>>249
ああごめん。++xだったね

252 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/09(月) 14:07:02.39
>>251
大分近くなったが、まだセマンティクスは完全に一致してないのだが…
マジでプログラマやめたら?

253 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/09(月) 20:12:07.88
xが整数かポインタかで細かいところは変わるし、そこまでこだわる理由も無いように思うがw

254 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 06:27:34.64
Cリファレンスマニュアル5th edition読む限りでは ++x と x+=1 と x=x+1 は
等しいと読めるし、今手元に無いから記憶だけど規格書でもそうだった気がするが...
xが整数かポインタかで変わる?ありえんだろ

255 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 06:53:56.48
整数ならインクリメント命令にできるが、ポインタだとそうはいかない。

>>249 は x=x+1 において x の評価が 2 回起きる、と言いたいらしいが、
ここでは x は任意の式ではなくて、ただの変数なので、その違いは無い。

結論。>>249 は今すぐプログラマをやめて、一生 2 ちゃんねるもプログラムも書くな。

256 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 06:55:53.83
>>255
ポインタでもできるよ?何言ってんの?

257 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 07:23:12.98
そりゃ 4 増える「インクリメント命令」がありゃ、int を指してるポインタでもできるが。

258 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 07:50:03.25
ん?今は x=x+1と++xの違いの話だろ?
どっちもxがポインタなら sizeof(*x) だけ増加する

259 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 08:51:18.39
>>255
> ここでは x は任意の式ではなくて、ただの変数なので、
なにか鬼畜なマクロかもしれませんよ。小文字一字なマクロは私の好みではありませんが。

260 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 11:46:04.65
仮に (1+1) に展開されたら ++ なんてできない。以上

261 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 12:12:40.99
>>255
ねえ、君、本当にプログラマ?
プログラミングで給料取れるレベルじゃないよ。

262 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 12:14:47.94
>>259
マクロの引数だったりすると、小文字一文字はよくある話だなw

263 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 12:14:53.18
結局具体的には全く反論できないんだなw >>261

264 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 12:27:04.25
セマンティクスの話してるときに
字句レベルの置き換えであるCマクロ持ち出す馬鹿は
プログラマに向いてないから辞めた方が良い
まともに言語規格書読めないだろ

例えば
#define double int
とされてたら double x; でも x はdouble型とは言えない、
とか言い出すレベルでバカなわけで

265 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 13:07:24.91
セマンティクスとしては x の評価を 2 度する、というのは変わらんじゃないのかな。
その評価が状態に対して idempotent かどうかという違いであって。

266 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/10(火) 19:21:01.18
>>249
その2つのセマンティクスの違いって何なの?
そろそろ答え教えてくだしあ

267 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/11(水) 17:15:34.44
結論: 教えてクレクレ君は二度とコード書かないほうがいい馬鹿

268 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/11(水) 17:17:35.36
>>264
> セマンティクスの話してるときに

ダウトw
構文の話をしていた>>248にセマンティクスを持ちだしたのが>>249だwww
あまりにも馬鹿すぎるww

269 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/11(水) 17:33:12.97
>>248
> 良く使うから構文糖が用意されるって話は分かるが
> 相性が悪いから?なにそれ?
> じゃあ何か。C言語で x=x+1 を x++ と書けたり

↓これがいつのまにか

>>264
> セマンティクスの話してるときに
> 字句レベルの置き換えであるCマクロ持ち出す馬鹿は
> プログラマに向いてないから辞めた方が良い

構文糖って「字句レベルの置換え」だよねw

> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い
> プログラマに向いてないから辞めた方が良い


270 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/11(水) 18:16:56.64
構文(syntax)と字句(lexical)の違いも分からないとか
マジ終わってんな
yaccとlexも知らんのか

271 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/11(水) 18:38:20.37
>>267
じゃあ僕が良いこと教えてあげる
>>249のようなレスしても論理的な説明しなかったら説得力0なんだよ^^

272 :営利利用に関するLR審議中@詳細は自治スレへ:2012/04/11(水) 19:55:55.38
教えてクレクレ君とバカにすれば、どんな間違いを言っても逃げきれると思っているバカが一人w

273 :デフォルトの名無しさん:2012/04/12(木) 10:24:22.23
>>270
へー、字句解析に手を入れずに構文糖衣かw
馬鹿が考えることは壮大だねえww

お前、完全にプログラマー失格。

274 :デフォルトの名無しさん:2012/04/12(木) 11:33:51.80
プログラマ失格のバカはどう見てもおまえだw

275 :デフォルトの名無しさん:2012/04/12(木) 18:21:18.92
>>274
いいから涙を拭けよ

見ていて痛々しすぎる
そうやって涙目で必死に弁解するぐらいなら
本当にプログラマー辞めればいいのに

276 :デフォルトの名無しさん:2012/04/12(木) 18:41:52.91
その言葉が自分にあてはまってると気付かないあたり、完全に重篤の患者ですなw

277 :デフォルトの名無しさん:2012/04/12(木) 20:32:23.55
>>276
どうしてプログラマーになろうなんて思っちゃったの?
間違いを正すのは恥ずかしいことじゃないよ。
だから今すぐ辞表を書きなさい。

278 :デフォルトの名無しさん:2012/04/12(木) 20:34:51.24
>>277 >>277

279 :デフォルトの名無しさん:2012/04/12(木) 20:35:37.79
最近の関数型言語は辞表も書けない

280 :デフォルトの名無しさん:2012/04/12(木) 20:37:18.68
そうやって無限退行することしかできないんだな

281 :デフォルトの名無しさん:2012/04/12(木) 20:38:49.61
なんか気持ち悪いのに粘着されてんな

つーか書き込みから漂うドカタ臭で鼻が曲がるから
もうちょっとマトモな職に就いてから書き込んでくれ

282 :デフォルトの名無しさん:2012/04/13(金) 00:56:17.28
pythonpython言ってた人はどこ行ったの?

283 :デフォルトの名無しさん:2012/04/13(金) 01:08:26.21
人口が少ない言語。一人減っただけでとたんに静になる。

284 :デフォルトの名無しさん:2012/04/13(金) 08:48:11.97
結局、蓮ケラはx=x+1とx++の区別がつかないのねwかわいそww

285 :デフォルトの名無しさん:2012/04/13(金) 08:55:01.56
>>265 が理解できないならプログラマやめたほうがいいよ

286 :デフォルトの名無しさん:2012/04/13(金) 17:58:38.11
ところで何故にセマンティクスの話をし始めたの?

287 :デフォルトの名無しさん:2012/04/13(金) 18:47:51.14
構文糖って言葉を聞きかじって、使ってみたかったんだろ。察してやれw

288 :デフォルトの名無しさん:2012/04/13(金) 19:39:06.58
検索してみたらセマンティクスって言い出したのは
>>249のアホじゃん

289 :デフォルトの名無しさん:2012/04/13(金) 22:40:41.13
x=x++++++1

290 :デフォルトの名無しさん:2012/04/13(金) 22:41:46.36
>>289はこう解釈されます

x=((x++)++) + +1


291 :デフォルトの名無しさん:2012/04/14(土) 01:50:55.06
出来るやつならどっちも使える上に、C++のほうを好むと思うがね。

どっちもできるけどC言語のが良いってヤツ存在してんの?

292 :デフォルトの名無しさん:2012/04/14(土) 04:41:53.92
Linus

293 :デフォルトの名無しさん:2012/04/14(土) 05:21:54.94
お前らプログラマなの?

294 :デフォルトの名無しさん:2012/04/14(土) 08:23:34.17
>>290
x++はsequence pointじゃない
ひとつのsequence pointに複数のside effectsを含むのは
未定義動作

295 :デフォルトの名無しさん:2012/04/15(日) 00:50:18.96
>>292

レベルの低いヤツに合わせるためにあえてCを使ってるだけで、Cの方が良いってわけじゃないんでは?

296 :デフォルトの名無しさん:2012/04/15(日) 01:08:19.88
Cの方がいいに決まってるだろw

297 :デフォルトの名無しさん:2012/04/15(日) 01:10:23.80
関数型言語は遅いからね。
C言語に比べて100倍以上遅い。

298 :デフォルトの名無しさん:2012/04/15(日) 01:36:54.44
やっぱりx=x+1と++xは式としてのセマンティクスが違うんだね。
納得。

299 :デフォルトの名無しさん:2012/04/15(日) 01:43:18.55
そりゃそうだろう。

そもそも++というのはなんで存在するか。

まず1追加するというのはプログラムでよく出てくる処理。
ならばそれを高速にしようと、専用のアセンブラ命令(INC)を作った。
足し算はADD

昔のコンパイラは馬鹿だから+1を++に変換するなんてことはしない。
+1と書かれていたらADD、++と書かれていたらINCに
単純に置き換えるのみ。

300 : ◆QZaw55cn4c :2012/04/15(日) 02:04:05.23
さらに、CPU によっては命令の実行ごとにレジスタが自動的にインクリメントされるアドレッシングを備えるものもあった。

301 :デフォルトの名無しさん:2012/04/15(日) 06:45:54.32
んで、ここ何のスレだっけ

302 :デフォルトの名無しさん:2012/04/15(日) 07:05:36.02
>>298>>299
Cとは何かを決めてるのは言語規格書
違うというなら規格書を引用して説明しろよ

303 :デフォルトの名無しさん:2012/04/15(日) 07:31:09.89
こんなトリビアルなピープホール最適化を「昔のコンパイラは馬鹿だから」だなんて
言っちゃうのは、コンパイラのことを全く知らないド素人です、と大声で宣伝するに等しい。

304 :デフォルトの名無しさん:2012/04/15(日) 10:04:49.51
>>302
一番最初にCが作られた時に
言語規格書なんてないよw

規格書は後から作られたものです。

305 :デフォルトの名無しさん:2012/04/15(日) 10:12:53.72
ピープホール最適化なんてのは
Cが一番初めに作られたときはなかったな。

306 :デフォルトの名無しさん:2012/04/15(日) 10:15:32.82
> 規格書は後から作られたものです。

だから何。
規格を作る時に既存の実装を無視して作ったとでも思ってるおバカさん?

307 :デフォルトの名無しさん:2012/04/15(日) 10:21:42.03
>>306
頭が悪いね。

(規格がない時代の)既存の実装がどうしてそうなっているか。
C言語は高級アセンブラと言われるように、
アセンブラを記述する代わりとして使えるように
コンピュータよりで仕様が作られている。ポインタとかね。

で、その一つが++という命令。CPUがインクリメントを速く実行できる
命令があるのなら、それに対応した文法をC言語に持たせるの自然な発想。

Cが作られたのは1971年だぞ。どんだけコンピュータが遅かったか。
その時代に、時間がかかる最適化処理をコンパイラにやらせるわけないじゃないか。
当時は人間が頑張ってC言語上で最適化する時代だったんだよ。


308 :デフォルトの名無しさん:2012/04/15(日) 10:22:23.42
1973年だった。

309 :デフォルトの名無しさん:2012/04/15(日) 10:26:09.65
現時点で規格書があるのに、それを無視して
昔はこうだったと言い出す奴は100%仕事できないだろうな

310 :デフォルトの名無しさん:2012/04/15(日) 10:28:56.98
どうしてそうなっているかという
過去の話をしているのだから、同然だろ。

311 :デフォルトの名無しさん:2012/04/15(日) 10:31:31.41
規格書を引用すればすむ話なのに?

312 : ◆QZaw55cn4c :2012/04/15(日) 10:31:37.81
そうそう企画なんて後付け、企画?

313 :デフォルトの名無しさん:2012/04/15(日) 10:34:03.15
>>311
すむと思うなら自分でやってみれば?

314 :デフォルトの名無しさん:2012/04/15(日) 10:35:11.26
そりゃ違う言い出したほうが出すべきだろ
書いてあるんだろ?違うって

315 :デフォルトの名無しさん:2012/04/15(日) 10:36:19.74
「規格書に書いてある」と言い出した人はだれですか

316 :デフォルトの名無しさん:2012/04/15(日) 10:37:48.97
規格書がない時代から++はあるのに、
規格書で決まってるんだから〜って
言ってる奴は間抜けだなw


317 :デフォルトの名無しさん:2012/04/15(日) 10:38:14.13
規格書に書いてなかったら同じとも違うとも言えんだろ
馬鹿じゃないの?

318 :デフォルトの名無しさん:2012/04/15(日) 10:38:42.04
>>316
>>309

319 :デフォルトの名無しさん:2012/04/15(日) 10:39:20.38
>>317
ほう。つまり君は規格書に書いてあると言いたいわけだな?
引用して見せてよ。

320 :デフォルトの名無しさん:2012/04/15(日) 10:41:39.25
>>319
規格書に書いてなかったら「未定義」だ
でも「違う」と言い切ったんだろ?だったら書いてあるんだろうが

321 :デフォルトの名無しさん:2012/04/15(日) 10:41:54.91
>>318
だからね。規格書がない時代にどうして++が生まれたかの話をしてるんだよ。
規格書は後から作られたもの。

教科書にそう書いてあるから正しいんだとか言うなよ?
恥ずかしいからw

322 :デフォルトの名無しさん:2012/04/15(日) 10:43:55.84
>>320
もしかして「セマンティクス」の意味がわかってないのかな?

323 :デフォルトの名無しさん:2012/04/15(日) 10:46:24.21
>>321
> だからね。規格書がない時代にどうして++が生まれたかの話をしてるんだよ。

>>249から読み直したが、全然そんな話じゃなかったぞ
それとも>>249は規格書がない時代のCの話をしてたのか?

324 :デフォルトの名無しさん:2012/04/15(日) 11:01:45.10
とんでもない間違いを何度も晒されてしまう>>248がかわいそうすぎww



325 :デフォルトの名無しさん:2012/04/15(日) 11:10:47.57
> Cが作られたのは1971年だぞ。どんだけコンピュータが遅かったか。
> その時代に、時間がかかる最適化処理をコンパイラにやらせるわけないじゃないか。
> 当時は人間が頑張ってC言語上で最適化する時代だったんだよ。

嘘八百をご苦労さーんw

世界最初のFortranコンパイラが、「コンパイラなんてそんなものか」と
バカにされないために、最適化に苦心した、という話とか、最適化を
勉強していれば普通は常識。

326 :デフォルトの名無しさん:2012/04/15(日) 11:41:26.16
結局、シンタックスシュガーの話をしているところに
規格書がない時代のセマンティクスの話をしだして
>もう二度とコードを書かないほうがいいぞw
とかドヤ顔で言っちゃったということか

327 :デフォルトの名無しさん:2012/04/15(日) 12:40:56.55
よう、俺に振り回された気分はどうだい?w

328 :デフォルトの名無しさん:2012/04/15(日) 17:13:44.57
事の発端はこれか。確かにこれは馬鹿すぎる。

>>248
> 248 名前:営利利用に関するLR審議中@詳細は自治スレへ [sage]: 2012/04/07(土) 01:20:29.83
> 良く使うから構文糖が用意されるって話は分かるが
> 相性が悪いから?なにそれ?
>
> じゃあ何か。C言語で x=x+1 を x++ と書けたり
> *(x+1) を x[1] と書ける構文糖が用意されてるのは、
> C言語がインクリメントや配列と相性悪いからか?


329 :デフォルトの名無しさん:2012/04/16(月) 08:53:23.07
スレタイすら読めない奴って、他スレで負けて逃げてきた連中だろうな。

330 :デフォルトの名無しさん:2012/04/16(月) 08:55:57.06
自分が負け続きで逃げっぱなしなので、必死でそのように思い込もうとしているのですねわかります

331 :デフォルトの名無しさん:2012/04/17(火) 02:39:26.84
リーナスがこのスレに書き込みしてるのか?

332 :デフォルトの名無しさん:2012/05/11(金) 10:24:30.87
セマンティクスとは「データの意味」のことであり,

333 :デフォルトの名無しさん:2012/05/20(日) 00:55:25.53
適材適所

334 :デフォルトの名無しさん:2012/05/20(日) 02:06:46.69
>>328
これって、聞いた話だと、とあるCPUにレジスタの値を+1するだけの特化命令があって
その命令に対応させるためだけに作った構文なんだってね

むかしは、構文木とかもメモリがないから、一行分づつに作って、マシンコードを生成してたから
そういう命令が必要だったんだとか

335 :デフォルトの名無しさん:2012/05/20(日) 02:07:29.68
>>334
最後の行訂正
命令→構文

336 :デフォルトの名無しさん:2012/05/20(日) 17:39:04.46
とあるも何も、大抵のCPUにはインクリメント命令ぐらいあるだろw
しかも、x += 1はステートメントじゃないしwバカすぎw

337 :デフォルトの名無しさん:2012/05/20(日) 20:50:55.36
最近のCPUは特化命令としてはないんじゃないの?
もちろん、命令デコードの段階で判断して、高速に実行するだろうけど

338 :デフォルトの名無しさん:2012/05/20(日) 22:27:28.71
昔のCPUと違って、アセンブラ用コードに一対一で対応したマシン語で実行してる訳じゃないからなあ。

339 :デフォルトの名無しさん:2012/05/21(月) 10:04:58.26
++とか--が用意されたのは

「アドレスレジスタが指す領域の値を参照/更新したあと、アドレスレジスタをインクリメント/デクリメントする」

「アドレスレジスタをインクリメント/デクリメントしたあと、アドレスレジスタが指す領域の値を参照/更新する」

上記あたりを1命令で実行可能なCPU向けに
最適化とか無しに上記の命令へダイレクトに解釈されるプログラムを書けるよう
用意されたものだと思ってた

340 :デフォルトの名無しさん:2012/05/22(火) 13:51:37.23
大昔のPDP-11の頃はそうだったかもしれない、けど、1980年頃にはどうでもよくなって
たんじゃないかと思うけど。

後置の場合に変化前の値が式の値のなる点を除いて。

341 :デフォルトの名無しさん:2012/05/29(火) 17:23:56.80
-----------まとめ----------
「馬鹿は死なねば治らないのであり、だからこそアナトール・フランスは
『愚かな者は、邪悪な者よりも忌まわしい』と言ったのだ。
 邪悪な者は休むときがあるが、愚かな者はけっして休まないからである。」
(ホセ・オルテガ・イ・ガセット 1883〜1955)

http://toro.2ch.net/test/read.cgi/tech/1336122899/247
>ゲームは作らんから知らんが、
224 == 247 == 704 == 717 == http://logsoku.com/thread/toro.2ch.net/tech/1335361193/46
口癖はコンポジション、ミサイルとホーミングミサイルの設計について1ヶ月間も考え続けてる
http://toro.2ch.net/test/read.cgi/tech/1336122899/772
>ゲーム作らなくてもお前よりマトモ
タスクの実行順序を意識しないとゲームが作れない(笑)
http://toro.2ch.net/test/read.cgi/tech/1336122899/767
敵機 → プレイヤー の順序でタスクを実行するとタスクがぶっ壊れる
OOを得意げに語っているつもりが、やっている事が20年前のC言語だったという事実
バイナリの書き換えがわからない
コンパイラ言語のことをコンパイル言語とか言っちゃう
タイプミスの数々、右手の人差し指と中指をケガしてる模様
http://toro.2ch.net/test/read.cgi/tech/1336122899/190
http://toro.2ch.net/test/read.cgi/tech/1336122899/297
http://toro.2ch.net/test/read.cgi/tech/1325246820/837-839
http://toro.2ch.net/test/read.cgi/tech/1336122899/318-320
http://toro.2ch.net/test/read.cgi/tech/1336122899/332-334
http://toro.2ch.net/test/read.cgi/tech/1336122899/818
http://toro.2ch.net/test/read.cgi/tech/1336122899/956


342 :デフォルトの名無しさん:2012/06/10(日) 15:05:39.81
なんで関数型の人は他パラダイムを全部「命令型」と呼ぶの?
こないだPrologまでリストに含めて「命令型」と呼んでる人がいて
ツナマヨ思いっきり噴いちゃったヨ

343 :デフォルトの名無しさん:2012/06/10(日) 15:40:49.40
そいつが素人あるいはニワカなだけだろ
実際、そのカキコは誰からも相手にされていなかったしね
例外的な馬鹿一人をつかまえて、すべてが同じと考えるのもいかがなものかと

344 :デフォルトの名無しさん:2012/06/10(日) 18:22:24.14
SQLは何言語になるのかね

345 :デフォルトの名無しさん:2012/06/11(月) 00:41:19.97
ドメイン特化言語

346 :デフォルトの名無しさん:2012/06/11(月) 00:54:22.31
確かに関数型言語が汎用である必要は無いのかもね。
汎用言語って括りだと、コンピュータの動作原理を考えても、
やっぱ手続き型が主流になるのは目に見えてるしな。
SQLみたいに何かに特化してしまってよいのかも。

347 :デフォルトの名無しさん:2012/06/11(月) 07:32:22.77
関数型言語はアホには理解できないという意味で
汎用的じゃないな

348 :デフォルトの名無しさん:2012/06/11(月) 10:04:14.07
つまり研究用に細々と使われるのがお似合いということ

349 :デフォルトの名無しさん:2012/06/11(月) 11:01:21.63
>>346
と言うか手続き型で全部やることすら本来なら旧世代の考え方かと
(それが今も濃く残っちゃってるのだけど)
インラインアセンブラみたいな形で
本質的に手順を必要とする部分は手続き型、本質的に式を必要とする部分は関数型、
本質的に論理を必要とする部分は論理型、ごく低レベルな処理を必要とする部分はアセンブラ…

ってやればいいのではないかと思う

350 :デフォルトの名無しさん:2012/06/11(月) 12:21:30.96
普通にCとHaskellを組み合わせて使ってる

351 :デフォルトの名無しさん:2012/06/11(月) 14:36:16.74
バカは、他人がみんなバカということにしないと気が済まないから、
>>348 のような発想を、よくするんだよな。
80年代に、BASICさえ使えれば万全、とか言い張ってた人にそっくりだ。

352 :デフォルトの名無しさん:2012/06/11(月) 14:49:12.37
つまり関数型言語を理解出来ないバカは少数ということ

それなのにユーザーが少ないのは使えない玩具だから

353 :デフォルトの名無しさん:2012/06/11(月) 22:01:54.26
>>352
自分がその少数のバカに属する気分はどう?

354 :デフォルトの名無しさん:2012/06/12(火) 00:21:53.12
へたくそな煽り乙w

355 :デフォルトの名無しさん:2012/06/12(火) 02:45:36.25
ふむ。関数型言語が理解できるって強がり言わないだけ素直でよろしい
バカの上に嘘つきで意地っ張りとか救いようが無いからね

356 :デフォルトの名無しさん:2012/06/12(火) 04:39:45.80
関数型言語が理解できるって言うと、強がりになるの?

357 :デフォルトの名無しさん:2012/06/12(火) 07:30:11.78
理解してない奴が言ったらそうなるだろう
関数型言語に限らずOOPLでも数学でも何でも

358 :デフォルトの名無しさん:2012/06/12(火) 08:07:29.48
理解できない人って居るのかなぁ。
副作用がない分、簡単なんでしょ?

359 :デフォルトの名無しさん:2012/06/12(火) 08:10:37.27
>>358
> 副作用がない分、簡単なんでしょ?

これ疑問系で訊くってことはお前は理解できてないんだろ

だから理解できない奴は居るよ。お前のことだよ

360 :デフォルトの名無しさん:2012/06/12(火) 08:14:49.30
それ言ったらアセンブラだって簡単だよ
概念自体は理解できても、やりたいこと実現するとこまでいけないのが大概でしょ

手続き型でもそういう初心者が居るように
手続き型に慣れてても関数型という新たな概念に触れた人は関数型初心者になる
関数型のコードに慣れない内は「無理!わからん!」になるのは何らおかしくはない

361 :デフォルトの名無しさん:2012/06/12(火) 08:26:28.97
でも関数型って基本的に手続き型から副作用を取ったものだから、
手続き型が出来れば関数型も出来るよ。
むしろ手続き型のほうがあれこれ副作用に頭を悩ませなければならないから
使いこなすのは難しいと思う。
そりゃ関数型で無理に副作用っぽい物を表現しようとすると難しいけど、
それは使い所を間違っているだけだからねぇ。
副作用を狙う箇所は手続きで書けば済む話だし。

362 :デフォルトの名無しさん:2012/06/12(火) 08:49:01.07
ていうか OCaml 使えよ、っていう話だろ

363 :デフォルトの名無しさん:2012/06/12(火) 08:57:59.08
だって、関数型が難しいって論調だったから。

364 :デフォルトの名無しさん:2012/06/12(火) 13:09:44.45
ルーピーで関数型を気取られても

365 :デフォルトの名無しさん:2012/06/12(火) 14:01:51.10
関数型って気取るものなのですか?

366 :デフォルトの名無しさん:2012/06/12(火) 16:42:53.55
手続き型言語での状態書き換えを、「副作用」と呼ぶ事自体が迷走の始まり。
手続き型と同じアプローチで関数型言語を無理やり使おうとすると、関数型言語にとって副作用でしかないものが必要になるだけの事。

367 :デフォルトの名無しさん:2012/06/12(火) 21:14:13.08
おっとScalaを勘違いして採用した現場の悪口はそこまでだ

368 :デフォルトの名無しさん:2012/06/13(水) 08:57:32.35
勘違いして使ってりゃ、悲惨なことになるのは何でも同じだな。

369 :デフォルトの名無しさん:2012/06/13(水) 11:53:02.19
>>367
Twitter社のことか

370 :デフォルトの名無しさん:2012/06/13(水) 15:10:03.54
関数型コミュ、特にハスケラのdisり大好きっぷりを見ていると、
こいつらメジャーになったら速攻で内ゲバ始めるのが目に見えるから
距離を保つことにしたw

371 :デフォルトの名無しさん:2012/06/13(水) 15:43:25.98
距離を保つも何も、お前が近づけたことなど一度も無いだろ

372 :uy:2012/06/13(水) 16:52:14.22
>>9

>関数型言語が普及しない理由 - 偏見プログラマの語り!
http://d.hatena.ne.jp/kura-replace/20111114/1321236695


これ、俺がググって偶然そいつのその記事見つけたとき
> というわけで本稿を書くわけですが(ヤメテ!そんな冷たい目で僕を見ないで!)、
>関数型言語*1についてはよく知りませんので、決して真に受ける事無く、
>オブジェクト指向言語をようやっと使っている底辺プログラマのぼやきということで了解いただければと思います。(ヤメテ!その前置きはズルイとか言わないで!)

この発言にブチギレそうになった奴の記事だわ


なんで>>9は明らかに初心者みたいな奴のブログ引用してんの?
引用に見せかけた晒し?

関数型はやっぱ流行らないな

373 :デフォルトの名無しさん:2012/06/13(水) 17:11:51.61
22 :uy [sage] :2012/06/13(水) 16:53:41.38
 静的言語はゴミでしかない

374 :デフォルトの名無しさん:2012/06/13(水) 17:48:08.37
>>366
手続き型言語には元々、「副作用」なんて無いしな。
あるのは、状態書き換え。

375 :デフォルトの名無しさん:2012/06/13(水) 18:04:43.26
printfが標準出力に出力するのも状態書き換えっていうの?

376 :デフォルトの名無しさん:2012/06/13(水) 18:12:03.08
最終的にはストレージの書き換えやパイプバッファの書き換えになるんじゃね

377 :デフォルトの名無しさん:2012/06/13(水) 18:26:43.46
そこらへんひっくるめて値を返す以外のことは副作用と呼んだらすっきりしていいじゃないか
手続き型であっても有用な概念だ

378 :デフォルトの名無しさん:2012/06/13(水) 20:54:59.93
>>371を読んでしまえば>>370に賛同するしかないだろうよ

379 :デフォルトの名無しさん:2012/06/13(水) 21:13:42.39
>>378
2chで世間が判った気になり始めたら、色んな意味でヤバイな。

380 :Prolog工作員:2012/06/14(木) 04:44:45.70
>>377
Prologをやってる立場から言うと、手続き型の中で副作用なんていって欲しくない。

381 :デフォルトの名無しさん:2012/06/14(木) 14:26:02.56
>>379
2chで世間が判った気になって他人にヤバイなとか言ってるバカw


382 :デフォルトの名無しさん:2012/06/14(木) 14:35:13.94
殴ったら殴り返されただけだろ?
どっちもどっちだよ

383 :デフォルトの名無しさん:2012/06/14(木) 19:41:12.66
どうしてあんなにdisるのが大好きなんだろう?依存症?

384 :デフォルトの名無しさん:2012/06/14(木) 20:41:54.00
uyはどっかのスレで、コテではいかに相手を苛立たせるかに心血を注いで、
普通の内容は名無しで書くみたいなことを言ってたな。
昔は単なる馬鹿だったが、最近は馬鹿の一つ覚えで○○も知らない奴らが〜○○位は当然〜みたいなことを言い出して、ウザさに磨きがかかってきたな。

385 :デフォルトの名無しさん:2012/06/15(金) 08:59:39.61
自己紹介乙

386 :uy:2012/06/16(土) 22:40:20.04
each_slice
transpose
chunk
inject
cycle
すら使えない奴らって生きてる価値ないと思う
例えば
10.times.cycle do |n| p n end
によって0~9をプリントする処理を無限ループなわけだけど、貴様らちゃんと扱えていますか?

387 :デフォルトの名無しさん:2012/06/17(日) 07:27:09.41
mapM_ print $ cycle [0..9]

388 :デフォルトの名無しさん:2012/06/17(日) 17:03:14.91
javaやC#に代数的データ型を導入して欲しい
関数型言語を使う気にはなれないけど、あれの素晴らしさには反論出来ない

389 :デフォルトの名無しさん:2012/08/12(日) 08:51:43.95
関数型の人たちって、どうしてあんなに上から目線でdisるのかな?

390 :デフォルトの名無しさん:2012/08/12(日) 09:10:46.97
静的型付け型の人たちって、どうしてあんなに上から目線で(動的型付けを)disるのかな?

391 :デフォルトの名無しさん:2012/08/12(日) 10:00:09.47
だって関数型言語を批判してる連中(の大部分)って
物凄く低能で、批判も的を射てないんだもん。
しかも批判しといて反論されたら上から目線でdisるな、とか言い出すし。
ホント馬鹿の上に品性まで劣ってるよな。

392 :デフォルトの名無しさん:2012/08/12(日) 10:11:58.73
だって動的型付け言語を批判してる連中(の大部分)って
物凄く低能で、批判も的を射てないんだもん。
しかも批判しといて反論されたら上から目線でdisるな、とか言い出すし。
ホント馬鹿の上に品性まで劣ってるよな。


393 :デフォルトの名無しさん:2012/08/13(月) 14:42:55.21
排他的なのは大抵ニワカ

394 :デフォルトの名無しさん:2012/08/14(火) 13:10:19.50
上から目線とか言っちゃう人は、永遠に底辺にいればいいと思うんだ。
向上心が欠片もない人間を引き上げてやる義理は無い。

395 :デフォルトの名無しさん:2012/08/14(火) 18:35:06.90
引き上げてやるだってwおもしろすぎww

396 :デフォルトの名無しさん:2012/08/14(火) 18:50:19.67
自分の脳味噌を観察したほうが面白いと思うぞ

397 :デフォルトの名無しさん:2012/08/16(木) 22:37:33.92
「上から目線」って言葉を聞いて「自分は上なんだ」と思うのがおもしろいんだが、そこが分からないとは…

398 :デフォルトの名無しさん:2012/08/16(木) 22:48:13.95
上から目線と言い出す奴は
自分より下に居るんだなぁ、と思うだけだが

399 :デフォルトの名無しさん:2012/08/17(金) 00:14:01.93
争いは同レベルの相手同士でなければ起き得ない(AA略

400 :デフォルトの名無しさん:2012/08/17(金) 00:57:37.01
>>398
その発想が興味深いんだよ

401 :デフォルトの名無しさん:2012/08/17(金) 18:52:27.57
バカが言う「興味深い」って、単に理解できてないだけだよなw

402 :デフォルトの名無しさん:2012/08/18(土) 01:36:10.82
>>401
この場合の「上から目線」ってのは、馬鹿にされてるんだよ

403 :デフォルトの名無しさん:2012/08/18(土) 07:43:41.89
バカに馬鹿にされても、何とも思わないけどな

404 :デフォルトの名無しさん:2012/08/21(火) 19:37:20.38
バカにされているのは>>403だということに気付けw

405 :デフォルトの名無しさん:2012/08/21(火) 19:50:03.82
ズレてね?

406 :デフォルトの名無しさん:2012/08/21(火) 19:58:11.26
ズレてるよなw

407 :デフォルトの名無しさん:2012/10/21(日) 08:24:20.80


408 :デフォルトの名無しさん:2013/04/04(木) 12:53:10.94
軽量動的言語から来たけど
letとかのバインド?が何のために必要なのかわからない。
せっかく型推論で型記述しなくてすむのに意味なくない?

409 :デフォルトの名無しさん:2013/04/04(木) 13:26:13.63
値の再利用と表現の簡潔化でしょ。
Don't Repeat Yourself的に。

letでも型の記述は(型推論できる式なら)いらないし。

410 :デフォルトの名無しさん:2013/04/04(木) 13:38:08.65
何度も評価するより1度の評価で済むほうが速いだろw

411 :デフォルトの名無しさん:2013/04/04(木) 23:30:06.56
一文字でも少なくタイプしたいなら ruby やってろ
っていう話じゃないの

412 :デフォルトの名無しさん:2013/04/05(金) 00:10:33.03
let無しだと構文解析のルールがとても複雑になるんだな〜

413 :デフォルトの名無しさん:2013/06/20(木) 19:42:10.61
関数型言語ってループは末尾再帰で書くんですよね?
それってループするために関数定義の為に名前を消費する必要があるってことですか?
その、べつにそれがいいとか悪いとか言うんじゃなくて、単純に気になっただけなんですけど。

414 :デフォルトの名無しさん:2013/06/20(木) 20:25:36.29
たいていは通用範囲がローカルなかたちで名前をつけることができるから問題ない

415 :デフォルトの名無しさん:2013/06/20(木) 21:24:23.61
>>413
>関数型言語ってループは末尾再帰で書くんですよね?

関数型言語の原理、というか計算モデルという視点であれば、その認識は正しい

>それってループするために関数定義の為に名前を消費する必要があるってことですか?

関数型言語では(数値や文字列と同様に)関数そのものも式の要素になる
言い換えると、関数の引数として関数を渡したり、関数の戻り値も関数として定義でき、
こういった関数の使い方は「高階関数」と呼ばれている

一般に関数型言語には、この高階関数を応用したライブラリが標準で付属しており、
このライブラリ関数を利用する事によって、多くのケースでは関数再帰を意識せず
(手続き型言語における)ループ処理をプログラミングできるし、無駄な名前の消費も無い

高階関数の代表例にはリスト処理を提供する List.map, List.filter, List.fold があり、
たとえば Ruby では以下に示すようにモジュール Enumerable のメソッドとして定義されている

・List.map -> Enumuerable#map
・List.filter -> Enumerble#select, Enumerable#reject
・List.fold -> Enumerble#inject

416 :デフォルトの名無しさん:2013/06/20(木) 21:58:56.06
ある集合の各要素へ、ある関数を適用した場合の、新たな集合を知るのがループの目的であるならば、
最初の集合と適用する関数を記述するだけで結果の集合を得られるので、他の言語のように何をするにもforループを書く的な書き方はあまりしない。

417 :415:2013/06/20(木) 22:09:07.44
>>415では肝心な事を書き忘れていたので追記する

>>413も知っているように関数には名前を付けることができて、
これは「関数を定義する」と呼ばれることが多い
同時に、関数型言語には「無名関数」と呼ばれる概念があり、
「ラムダ式」あるいは「関数式」とも呼ばれる
つまり、(>>415で述べた)高階関数へ渡す関数や戻り値としての関数には
この無名関数を使えばいいから、無駄な名前を消費せずにプログラミングできることになる

たとえば Standard ML という関数型言語では、無名関数の文法は「fn <引数> => 式」であり、
その無名関数をリスト処理関数 map へ渡すサンプルコードは以下の様になる

 - map (fn x => x + 1) [1, 2, 3];
 > val it = [2, 3, 4] : int list

Ruby であれば、以下のように書く

 irb(main):001:0> [1, 2, 3].map { |x| x + 1 }
 => [2, 3, 4]

418 :デフォルトの名無しさん:2013/06/21(金) 00:40:31.57
>>414-417
回答ありがとうございます。

>>417
自分も無名関数についてはある程度知っていました。
Cのqsort関数なんかを使う時に、lambdaで直接関数を渡せたらいいななんて思うこともあります。
まあ、Cをアセンブリ言語のマクロと考えれば、欲張らない仕様の方がいいんでしょうけど。

そんなことを考えている時に、無名関数という仕様を持っている関数型言語でさえ、結局のところ、
余計な名前を使わなきゃならない場面があるのかと疑問に思って質問させて頂きました。
# 自分は関数名を考える作業があまり好きではないので。

>>414さんや>>416さんの話で関数型言語を使う人の意識というか感覚みたいなものが多少判ったような気がします。
「そんなことを気にする場面ってあんまりないよ」ってことだと思うのですが、それは

> 一般に関数型言語には、この高階関数を応用したライブラリが標準で付属しており、
> このライブラリ関数を利用する事によって、多くのケースでは関数再帰を意識せず
> (手続き型言語における)ループ処理をプログラミングできるし、無駄な名前の消費も無い

ということだからってことですね。
いろんな観点でのコメントがもらえて勉強になりました。
ありがとうございました。

419 :デフォルトの名無しさん:2013/06/21(金) 01:28:15.65
lambda だけで再帰はむりかと

420 :デフォルトの名無しさん:2013/06/21(金) 04:09:08.96
でもYコンビネータなら?

421 :デフォルトの名無しさん:2013/06/21(金) 10:44:44.88
(λf . (λx . f (x x)) (λx . f (x x)))

422 :デフォルトの名無しさん:2013/06/21(金) 11:37:03.55
>>420
評価器による。正規なら記述可能。

423 :デフォルトの名無しさん:2013/06/22(土) 17:48:31.52
>>422
> >>420
> 評価器による。正規なら記述可能。

CurryのYコンビネーター(そのλ式による表現は421にある通り)はどんな評価戦略でもリダクションだけでは進まない(逆向き、つまり一般のconversionが必要)。
しかし例えばTuringのΘコンビネーター(詳しくはBarendregtの百科事典を見ろ)ならば評価戦略がnormal orderの場合にはリダクションで再帰を表すことができる。
更にapplicative orderのリダクション戦略(かつλ束縛の本体にはリダクションが入らないweak戦略)という通常のcall-by-value関数的プログラミング言語の
評価戦略でも、λ束縛つまり高階関数によって再帰を表現する事は可能。FriedmanらのSeasoned Schemerに答えが書いてある。
つまり現実のSchemeを用いた関数的プログラミングで再帰呼び出しを完全に消しさることは実際に可能ってことだ。

424 :デフォルトの名無しさん:2013/06/22(土) 20:12:46.50
>>423
「リダクションだけでは進まない」って何を指して言ってる?
y fを評価していってもf (y f)と構文的に同じにならないってこと?
再帰を記述するのが目的ならそれは別に必要ないんじゃね

import Unsafe.Coerce

main = print $ y (9:)

y :: (a -> a) -> a
y = \f -> (\x -> f (unsafeCoerce x x)) (\x -> f (unsafeCoerce x x))

425 :デフォルトの名無しさん:2013/06/23(日) 18:49:02.67
>>424
> >>423
> 「リダクションだけでは進まない」って何を指して言ってる?
> y fを評価していってもf (y f)と構文的に同じにならないってこと?

(λx..M)N → Mの中の自由なxをNで置き換えた項

という一種の書き換えによって左から右へと進めるのがリダクション。
この左から右への向きだけではYfからスタートしてf(Yf)は得られないということ。

カリーのYでなくチューリングのΘを用いて最左最外のリデックスをリダクションする正規戦略ならば
Θfからスタートしてf(Θf)までリダクションだけで辿り着くことが可能。

426 :デフォルトの名無しさん:2013/06/23(日) 19:48:23.59
>>425
再帰をするのが目的ならf (Y f)を得る必要はないよね
なんか適当な意味論のもとでY fがf (Y f)と同じになればいい

427 :デフォルトの名無しさん:2013/08/28(水) NY:AN:NY.AN
プログラム言語における関数型言語っていうのは
OSにおけるLinuxみたいなものだと思っている

何年も前からユーザは「これからは関数型言語(Linux)の時代」と連呼しているのに
まったく流行しない。またユーザーは関数型言語(Linux)を使う事がカッコいいと信じているw

428 :デフォルトの名無しさん:2013/08/28(水) NY:AN:NY.AN
Windows信者のバカ君が今度はココに沸いたw

429 :デフォルトの名無しさん:2013/08/28(水) NY:AN:NY.AN
LinuxじゃなくてMacみたいな感じをうけるけどな

430 :デフォルトの名無しさん:2013/08/29(木) NY:AN:NY.AN
今時Mac信者で、Mac OSとLinuxが、どちらもUnix系という同類であることを知らないなんて、
相当のバカだぞ?

……相当のバカなのかw

431 :デフォルトの名無しさん:2013/08/29(木) NY:AN:NY.AN
おまえはなにをいっているんだ

432 :デフォルトの名無しさん:2013/08/29(木) NY:AN:NY.AN
そんなわかりきったことをドヤ顔で講釈する>>430って…

433 :デフォルトの名無しさん:2013/09/02(月) 10:09:50.80
>>427
手段と目的を履き違える奴は
関数型言語には(Linuxもか)向いてない

434 :デフォルトの名無しさん:2013/09/02(月) 14:43:34.87
で、流行でしかモノを判断できない奴の使っている言語はなんなんだ?

435 :デフォルトの名無しさん:2013/09/02(月) 15:56:05.57
サンデープログラマーだから
業界で関数型が流行ってるって事すらわからん

436 :デフォルトの名無しさん:2013/09/02(月) 16:01:31.04
JavaScriptって関数型言語とも見れる???

437 :デフォルトの名無しさん:2013/09/02(月) 16:10:50.92
>>436
そんなこと言い出したらCでも関数型プログラミングはできる

438 :デフォルトの名無しさん:2013/09/02(月) 16:18:46.45
いや、そういうマクロ的屁理屈じゃなくて
ラムダ式とか第一級関数とか、前向きな機能揃ってるんじゃないかなあと思って

439 :デフォルトの名無しさん:2013/09/02(月) 16:21:38.70
>>436
いまさら

440 :デフォルトの名無しさん:2013/09/02(月) 16:21:53.27
関数型プログラミングならどの言語でもできる
関数型言語と呼ばれるのは関数型プログラミング「しか」できない言語だ
だから「使えない」と烙印を押される
JavaScriptはそうじゃないだろう?

441 :デフォルトの名無しさん:2013/09/02(月) 16:23:20.07
また意味不明な論理が来ました。

Haskell以外に『関数型プログラミング「しか」できない言語』ってあるか?

442 :デフォルトの名無しさん:2013/09/02(月) 16:24:26.89
>>441
屁理屈乙
お前は0か1かしか考えれんのか

443 :デフォルトの名無しさん:2013/09/02(月) 16:38:50.97
度合いを日本語で語るとかプログラマの恥。
勘違いして欲しくないんなら数値で語れ。

444 :デフォルトの名無しさん:2013/09/02(月) 16:40:41.13
言語を作った人が「これは関数型だ」と言い張れば関数型になる。
そうでないなら外野があれこれ言うのは野暮というものだろう。

445 :デフォルトの名無しさん:2013/09/02(月) 17:00:37.50
関数型は使えないというタイトルなんだから、そんな結論じゃダメでしょ。
関数型だとアピールしてる言語はクソが多いってことなら問題ないけど。

……あ、もしかしてそういう話?

446 :デフォルトの名無しさん:2013/09/02(月) 17:40:30.44
関数型言語の問題点は「汎用的すぎる」って点にあると思う

低レイヤ…C
ゲーム…C++
言語処理系…C++
統計…R
CGI…Perl
Webアプリ…PHP
ブラウザ…JavaScript
Windowsアプリ…C#
iPhone…Objective-C
汎用スクリプト…Python, Ruby
業務システム…Java

「この用途ならこの言語」って言えるような分野って関数型言語にある?

447 :デフォルトの名無しさん:2013/09/02(月) 18:07:41.26
なんか書き込みが多いと思ったら、どうでもいい書き込みばかりだな

448 :デフォルトの名無しさん:2013/09/02(月) 21:59:22.67
関数型言語でググレカス

449 :デフォルトの名無しさん:2013/09/02(月) 22:05:32.41
関数型ってGUIもI/Oも苦手分野じゃん。
いったいどうしろってんだ。

450 :デフォルトの名無しさん:2013/09/02(月) 22:23:05.16
苦手なの?
手続き型みたいにかけるけど

451 :デフォルトの名無しさん:2013/09/03(火) 07:18:29.13
それはもはや関数型プログラミングではない

452 :デフォルトの名無しさん:2013/09/03(火) 17:12:46.33
モナドを持て囃している時点で、関数プログラミングは負けを認めたようなものだな。

モナドはマルチパラダイムだ、などと言い訳しているようだが、
結局は関数プログラミング単独では実用プログラムは書けない。
関数だけでなく、逐次実行と状態書き換えを導入しなければ使い物にならない。
そう認めたようなものだ。

453 :デフォルトの名無しさん:2013/09/03(火) 18:02:29.25
>>452
>関数だけでなく、逐次実行と状態書き換えを導入しなければ使い物にならない。
いくら抽象的に書こうが実行できなければ使い物にならない、
と言ってるぐらい当たり前の話すぎてどう反応したらいいか。

454 :デフォルトの名無しさん:2013/09/03(火) 18:42:50.03
IO型があるのは、単にプリミティブ型とボックス型を厳密に区別してるのとたいして変わらないのに、
モナドモナドモナドー、って叫んじゃうのが初心者なんだよねw

455 :デフォルトの名無しさん:2013/09/03(火) 18:44:40.59
>>452
その通りだよ
いわゆる「関数型言語」は、言語全体を見て初めて便利なのであって、
関数プログラミングはできることの一つでしかない

456 :デフォルトの名無しさん:2013/09/04(水) 04:40:23.07
>>453
実行メカニズムと言語表現の区別ぐらいつくようになってから出直してくださいまし。

457 :デフォルトの名無しさん:2013/09/04(水) 07:05:14.29
>>454
全然違う

458 :デフォルトの名無しさん:2013/09/04(水) 23:24:13.96
>>456
どういう意味だよ。現実に書けるだろ。

レスそれ自体は要求した事を行わなければ、
要求を満たす事はできないっていう言葉遊びだ。
無理な前提を想定して適用してるのだから無理に決まってる。

プログラムの実行を考えない実用性を含むなら、
定理証明支援系という使い道もあるから間違い。

459 :デフォルトの名無しさん:2013/09/05(木) 01:50:32.92
俺的には関数型とかどうでもいいけど副作用の制限は制御したい

460 :デフォルトの名無しさん:2013/09/05(木) 01:59:36.31
結局関数プログラミングとかは方法であって目的ではない
これに尽きる
目的にすり替わってしまったら、そりゃダメだろ

461 :デフォルトの名無しさん:2013/09/05(木) 02:10:37.52
とりあえずjavaつかって
関数型プログラミングしたいところだけラムダ式だのなんだの使ってそれっぽくやればそれでいいじゃん。
最初から関数型言語を使う意義なんて無いね。

462 :デフォルトの名無しさん:2013/09/05(木) 05:03:35.90
>>458
わからないんならいいよ。プログラミング言語意味論でも勉強して出直してきなw

463 :デフォルトの名無しさん:2013/09/05(木) 13:04:21.73
>>462
言葉で飾るだけ飾ってるが一つも中身を語ってないな。
こんな阿呆に構った俺が馬鹿だった。

464 :デフォルトの名無しさん:2013/09/05(木) 16:45:39.95
自分のレベルが果てしなく下であることがわからない奴ってたまにいるよなw

465 :デフォルトの名無しさん:2013/09/05(木) 17:12:08.22
なんだこりゃ単語の関連の重みで文章を作成し無意味なことを言っている人工無能みたいな奴がいるw

466 :デフォルトの名無しさん:2013/09/05(木) 17:33:42.12
> 関数型プログラミングしたいところだけラムダ式だのなんだの使ってそれっぽくやればそれでいいじゃん。
> 最初から関数型言語を使う意義なんて無いね。

MLなりHaskellなり、現代において普通に「関数型言語」だと認められるものも全く知らないことが丸出しw

467 :デフォルトの名無しさん:2013/09/06(金) 03:04:27.46
リストと高階関数を使うことを関数型プログラミングと思ってる奴は多いな

468 :デフォルトの名無しさん:2013/09/06(金) 08:10:18.30
えっ?lリストって関数型にしか無いの?
配列は?タプルは?ストリームは?

469 :デフォルトの名無しさん:2013/09/06(金) 09:45:16.04
批判はしても具体的な主張はしない。
それが2ちゃんねらー

470 :デフォルトの名無しさん:2013/09/06(金) 09:53:28.43
具体的に主張したら論破されちゃうからな
批判だけしていれば致命的に論破される可能性は低くなる

471 :デフォルトの名無しさん:2013/09/06(金) 12:04:47.07
例えるなら文系(命令型)社長が
理系(関数型)社員を使いこなせてない状況に似てる

理系社長だと
理系社員で固めるから
そもそも使えないと言う評価が存在しなくなるしな

472 :デフォルトの名無しさん:2013/09/06(金) 12:57:55.41
命令型が好きな奴は
仕様書の命令に従うのもお手の物

俺は命令するのもされるのも嫌いだ

473 :デフォルトの名無しさん:2013/09/06(金) 13:15:25.15
2ちゃんねら(レス) : 批判
=> ...

474 :デフォルトの名無しさん:2013/09/06(金) 13:19:40.75
所属 = function
 | 批判 -> 2ちゃんねら
 | _ -> 一般

475 :デフォルトの名無しさん:2013/09/06(金) 17:48:37.59
文系理系って馬鹿だろw

476 :デフォルトの名無しさん:2013/09/06(金) 19:43:09.98
この世は文系理系じゃなく体育会系とその他で分かれてるからな

477 :デフォルトの名無しさん:2013/09/07(土) 05:40:06.35
このスレの流れでは
非関数型=手続き型=命令型=体育会系型
ってことかね。

478 :デフォルトの名無しさん:2013/09/07(土) 06:48:28.75
そう思ってる関数型の人は多いよね。

479 :デフォルトの名無しさん:2013/09/12(木) 16:20:46.29
文系と理系というより自民と民主だな
関数型言語は20年くらい前の民主

現政権の手続き(命令)型言語には嫌なところがたくさんあるが実稼働してるという実績があり
なにより関数型言語のいいところを貪欲に取り入れるという動きもあり好印象
関数型言語はお花畑気分が抜けずチャンス与えるのすら怖い
って感じ

むしろ共産党か

480 :デフォルトの名無しさん:2013/09/12(木) 16:27:15.89
出発点のLISPは共産主義者が作ったしな

481 :デフォルトの名無しさん:2013/09/12(木) 16:28:16.68
手続き型はそのうち取り返しのつかない事をやってしまう
原発は安全です(キリッみたいなw

482 :デフォルトの名無しさん:2013/09/12(木) 16:54:54.84
それに比べて関数型は核融合炉のように安全

483 :デフォルトの名無しさん:2013/09/13(金) 18:12:18.29
>>435
javaやPHPなんて仕事があるから選ぶだけで、日曜プログラマこそ関数型言語を使うべきだよ

484 :デフォルトの名無しさん:2013/09/13(金) 18:51:54.73
>>483
だよな
何が楽しくてjavaやるのかわからん
マゾかな?

485 :デフォルトの名無しさん:2013/09/13(金) 19:04:33.60
>>483-484
どの言語でどんなソフトウェアを作ってるのかも知らずに関数型を押し付けてる時点で
お前らが厨二病患ってるだけの素人だってわかるよ

486 :デフォルトの名無しさん:2013/09/13(金) 19:09:08.90
素人とかそりゃそうだろw
サンデープログラマーなんだから
流石、手続き型は論理的でない馬鹿な事を言う

487 :デフォルトの名無しさん:2013/09/13(金) 19:11:44.12
えっ

488 :デフォルトの名無しさん:2013/09/13(金) 19:25:45.86
Javaは関数型言語だろ
ラムダ式あるし

489 :デフォルトの名無しさん:2013/09/13(金) 19:34:57.88
ググったらマジだったw
javaも関数型の軍門に下ったか

490 :デフォルトの名無しさん:2013/09/13(金) 20:14:10.24
リリースもされてないものを何言ってるんだ

491 :デフォルトの名無しさん:2013/09/13(金) 20:44:05.01
Javaのはラムダと言ってもかなり制限されてるからな

492 :デフォルトの名無しさん:2013/09/13(金) 22:43:53.45
>>491
ラムダありゃいいってもんじゃねーだろw

493 :デフォルトの名無しさん:2013/09/14(土) 01:06:39.03
>>488
素の状態では変数の書き換えが出来ないのが関数型言語だと思うの
ごにょごにょすれば、関数型言語でも書き換えが出来るけど、手続き型よりは手軽じゃないって意味で

494 :デフォルトの名無しさん:2013/09/14(土) 06:58:59.93
お前ら向きの最強言語教えてやるよ。Dだ。

495 :デフォルトの名無しさん:2013/09/14(土) 08:01:42.47
「その辺の言語のよさそうな機能をぜんぶ集めてみました」みたいな言語って
美意識のカケラもないと思うの。

496 :デフォルトの名無しさん:2013/09/14(土) 09:26:02.00
>>495
なんでそこだけオカマ口調なんだ

497 :デフォルトの名無しさん:2013/09/14(土) 21:07:22.00
フフフ、いいわね、子どもって
あたしにもそんな純粋な頃があったわ

498 :デフォルトの名無しさん:2013/09/15(日) 11:31:04.95
グフフ、いいわね、子どもって

499 :デフォルトの名無しさん:2013/10/25(金) 17:49:17.08
生産性100倍スレがブレイクしてんな
こっちも盛り上げようぜwww

500 :499:2013/10/25(金) 17:50:06.58
>>498>>499
この間に1スレ消化してるからなあっち

501 :デフォルトの名無しさん:2013/10/25(金) 18:42:45.06
煽り力が足りない

502 :デフォルトの名無しさん:2013/10/26(土) 17:05:44.89
age

503 :デフォルトの名無しさん:2013/10/26(土) 20:34:14.04
生産性100倍スレはpart1が
2013年の3月に立って756まで一気に消化。そこそこのヒットスレではあった。

そこから伸びが鈍化してたが
10月になって837からまた急に伸びだしそのまま1000。
そして勢いはとどまらずpart2をまるまる消化。
いまいちきっかけがよくわからん
暇があったらまとめてみるか

504 :デフォルトの名無しさん:2013/10/26(土) 20:35:04.98
対となるこのスレももっと盛り上げないとバランスとれない

505 :デフォルトの名無しさん:2013/10/26(土) 20:55:20.40
俺、いつも上げるだろ、
そこから顔真っ赤にした戦いが始まるんだよ。
戦いはいらないから、俺の書き込みにレスしろって話。
何勝手に戦っちゃってんの。
あと、夜中に盛り上がるのやめてくれる?
勝手に盛り上がるなら次の日まで続けろよな。

506 :デフォルトの名無しさん:2013/10/26(土) 21:21:05.36
コンパクトな六尺コピペかと思った

507 :デフォルトの名無しさん:2013/10/26(土) 21:42:47.70
イイエ違います。
魂の叫びです。

508 :宇宙人:2013/10/26(土) 22:21:30.05
宇宙人だけど何か質問ある?

509 :デフォルトの名無しさん:2013/10/26(土) 22:36:42.91
宇宙のどこ出身?

510 :宇宙人:2013/10/26(土) 22:56:16.49
>>509
地球

511 :デフォルトの名無しさん:2013/10/26(土) 22:58:28.55
足のサイズ何インチ?

これ三個の質問で個人を特定するメソッドだけどいい?

512 :宇宙人:2013/10/26(土) 23:06:17.27
>>511
26.5

513 :宇宙人:2013/10/26(土) 23:12:18.66
つうか板違いな質問はご遠慮願います。

514 :デフォルトの名無しさん:2013/10/26(土) 23:23:29.46
673.1pってことだよね?

515 :デフォルトの名無しさん:2013/10/27(日) 00:01:11.69
足のサイズと行ったら足の長さのことに決ってるよな

516 :宇宙人:2013/10/27(日) 00:10:20.14
26.5*2^-60光年

517 :デフォルトの名無しさん:2013/10/27(日) 06:21:27.15
あっちのスレは
動的型付き言語派のほうが静的型付けをよく知っている奴が多い
という冗談みたいなスレだから。
TAPLも読んでないJaverに静的型付けを語られても迷惑なんだよ。

518 :デフォルトの名無しさん:2013/10/27(日) 14:33:58.10
関数型言語のエッセンスのいいとこ取りしてあとはポイすればいいということだが
根幹の静的型づけというのがどうにもならないのでそれは無理だということだろう

519 :デフォルトの名無しさん:2013/10/27(日) 16:01:39.26
>>517
こんなところで愚痴ってないで率直に反論しろよw負け犬w

520 :デフォルトの名無しさん:2013/10/27(日) 16:13:01.48
あのスレの負け犬はJS馬鹿だろ

521 :デフォルトの名無しさん:2013/10/27(日) 16:32:00.52
>>519
こんなところで愚痴っていないで、素直に
「Null値のデータ型は何か?」
について答えてみろよw負け犬w

522 : ◆QZaw55cn4c :2013/10/27(日) 16:36:11.93
いや動的型付け言語でも別にかまわないけど
option explicit
はほしい、通さないと typo がわからないとか勘弁

523 :宇宙人:2013/10/27(日) 17:07:11.80
nullは型不明だろ。premitive以外の型というのが地球では普通の認識だろ。
宇宙ではnullは連結リストの末尾型として定義される。

524 :宇宙人:2013/10/27(日) 17:09:33.32
CやC++ではnullは0という数値だけどこれはどうかと思う。

525 : ◆QZaw55cn4c :2013/10/27(日) 17:24:09.31
>>524
必要なとき(C/C++いずれにもある)には (void *)0 とキャストして型情報を附し無問題
C/C++は静的片付けだしオールマイティは無理なのでは?

526 :デフォルトの名無しさん:2013/10/27(日) 17:45:38.86
地球ではnullやnilの語源は無だから0ってことになっているけど
宇宙では0である必然性はなくてアドレス0にあるオブジェクトの機能は無しとも考えられる
宇宙では「無」ではなくリンクリストの末尾型オブジェクトとして定義されている。
Cでは
while(a!=NULL){...}を
while(a){...}と簡略化できた記憶があるが、while(ゼロ以外)ということだろう
そういう便利さがあるから0ってことになってるけど、
while構文自体が無い宇宙では別の認識になる。

527 :デフォルトの名無しさん:2013/10/28(月) 00:14:18.55
過去の遺産などは捨ててしまおうホトトギス
作りなおせばいい

528 :デフォルトの名無しさん:2013/10/28(月) 09:39:26.52
>>521
型なんて無いだろバーカ

529 :デフォルトの名無しさん:2013/10/28(月) 13:59:01.15
c++ではstd::nullptr_tっていう型

530 :デフォルトの名無しさん:2013/10/28(月) 15:40:52.29
それ定義が逆やから。

531 :デフォルトの名無しさん:2013/10/28(月) 16:50:51.61
>>528
知らないんだね。かわいそうに。

532 :デフォルトの名無しさん:2013/10/28(月) 17:05:29.03
>>531
ではどの言語でも通じる一般的なnullの型をどうぞ。

533 :デフォルトの名無しさん:2013/10/28(月) 17:57:43.96
言語により名前は変わるけど、どれもbottom typeだな。

534 :デフォルトの名無しさん:2013/10/28(月) 19:44:46.56
>>533
nullは値があるからbottom typeではない。
ではどの言語でも通じる一般的なnullの型をどうぞ。

535 :デフォルトの名無しさん:2013/10/28(月) 20:17:35.28
ああ、正確にはBotだな。

536 :デフォルトの名無しさん:2013/10/28(月) 21:08:22.67
nullの型って、
[a] -> Bool
とか、
(FUNCTION (T) BOOLEAN)
とかじゃないの

537 :デフォルトの名無しさん:2013/10/29(火) 00:34:50.15
はいはい部外者は黙ってね

538 :デフォルトの名無しさん:2013/10/29(火) 00:41:00.30
boolは型を持たない値だろ
言語によっては0でもあるんだろ

539 :デフォルトの名無しさん:2013/10/29(火) 19:13:28.77
nullって直積でどうやって定義する?

540 :デフォルトの名無しさん:2013/10/29(火) 20:00:00.88
希望を持てるのは羨ましい

541 :デフォルトの名無しさん:2013/10/29(火) 20:32:20.36
>>538
だからnullはPierceのBotだって言ってるのに

542 :デフォルトの名無しさん:2013/10/30(水) 00:31:14.65
nullはNull型だろ?

543 :デフォルトの名無しさん:2013/10/30(水) 16:37:49.76
実務関係なしに、未知の展望を語るのは楽しいからな

544 :デフォルトの名無しさん:2013/11/01(金) 04:45:46.28
実務(爆笑)

545 :デフォルトの名無しさん:2013/11/01(金) 05:29:24.78
>>543
こういうこと言うやつってプライドが無駄に高いから分からないことがあっても人に聞かず、
知識はあっても実際のプログラミング能力がプライドほど高くないからソースが書けない
職場にいたら迷惑な存在だよな

546 :デフォルトの名無しさん:2013/11/01(金) 14:08:45.76
ライブラリが一向にそろわないから使えない

547 :デフォルトの名無しさん:2013/11/01(金) 16:44:20.90
プログラミングなんて知識があれば能力高いだろ
勉強をおろそかにして糞ソース量産してる奴のが多いわ

548 :デフォルトの名無しさん:2013/11/01(金) 21:07:10.21
勉強w

549 :デフォルトの名無しさん:2013/11/01(金) 21:29:54.78
>>547
言ってる意味がわからない

550 :デフォルトの名無しさん:2013/11/01(金) 21:39:32.80
>>545
ジャバ入門は読み終わったか?

551 :デフォルトの名無しさん:2013/11/01(金) 21:55:41.49
ラムダってムダだと思うんだ。

552 :デフォルトの名無しさん:2013/11/02(土) 04:47:30.92
>>548
笑ってる時点で向いてない

>>549
普段から新しい効率の良い方法を得ることを考えず、
経験だけ積むだけで学んだ気になる馬鹿がどれだけ多いか

553 :デフォルトの名無しさん:2013/11/02(土) 09:01:45.88
>>552
日本語まず勉強しろよ…
元の、そういう意味だと理解できんぞ

554 :デフォルトの名無しさん:2013/11/02(土) 09:17:53.34
>>553
何がだ?
プログラミングは知識量が物を言うと言ってるんだよ
経験で培われるのは主に業務知識とその感覚であって
プログラミング能力とは全くの別だ

555 :宇宙人ミ☆:2013/11/02(土) 09:50:03.25
ははは見ろ人がゴミのようだ。

556 :デフォルトの名無しさん:2013/11/02(土) 09:50:08.48
いや、業務知識とか関係なく、プログラミングの技術に実践は欠かせないよ。

557 :デフォルトの名無しさん:2013/11/02(土) 09:50:13.50
それは不真面目すぎる
お前さんのイメージより皆普段の業務で一生懸命頑張って成長してる

558 :デフォルトの名無しさん:2013/11/02(土) 09:51:02.04
ははは見ろλがゴミのようだ。

559 :デフォルトの名無しさん:2013/11/02(土) 09:52:23.78
ラムダこりゃ

560 :デフォルトの名無しさん:2013/11/02(土) 10:04:01.50
よーし次いってみよう

561 :デフォルトの名無しさん:2013/11/02(土) 10:07:07.96
>>554
プログラミングなんて…簡単だろ ならともかく、プログラミングなんて…能力高い とかイミフ。

562 :デフォルトの名無しさん:2013/11/02(土) 10:55:12.26
>>552

563 :デフォルトの名無しさん:2013/11/03(日) 01:04:10.99
SICPやその他の本で散々「技工じゃなくて科学だぞ」と啓蒙してても、
職業マの大半はこの程度の認識だからな

ま、経験的技能だと思ってる馬鹿はそのうち入り口すら入れなくなるだろ

564 :デフォルトの名無しさん:2013/11/03(日) 01:27:04.85
>>563

565 :デフォルトの名無しさん:2013/11/03(日) 02:16:36.36
まあ本当にそうなるとしたらプログラマー人口が数百分の1に激減した時代だろう

566 :デフォルトの名無しさん:2013/11/03(日) 06:56:36.02
>>563
科学にも経験が必要だということも知らないわけ?なんともはや…

567 :デフォルトの名無しさん:2013/11/04(月) 23:30:33.38
ライブラリはよ

568 :デフォルトの名無しさん:2013/11/04(月) 23:33:15.43


569 :デフォルトの名無しさん:2013/11/05(火) 08:13:34.62
>>552
効率w

570 :デフォルトの名無しさん:2013/11/05(火) 17:41:26.84 ?2BP(0)
http://rfi.a.la9.jp/sateweb/scurl/znsc.html
お世話になります。
私、責任者の加茂と申します。以後、宜しくお願い致します。
http://www.karilun.com/img_shop/15/ss52_1368685958.jpg
浪速建設様の見解と致しましては、メールによる対応に関しましては
受付しないということで、当初より返信を行っていないようで、今後につい
てもメールや書面での対応は致しかねるというお答えでした。
 
このように現在まで6通のメールを送られたとのことですが、結果一度も
返信がないとう状況になっています。
 
私どものほうでも現在までのメール履歴は随時削除を致しております
ので実際に11通のメールを頂戴しているか不明なところであります。
 
弊社としましても今後メールでのやり取りを差し控えたく、浪速建設様
と同行の上でお会いさせていただきたい所存です。
http://rfi.a.la9.jp/hn203/set/Avatar_set/Avatar_set.html

571 :デフォルトの名無しさん:2013/11/07(木) 19:15:20.31
haskellでperl6が作られて話題になったことがあったが
今考えればあれは何だったのか?
狐に包まれたように思うのだ

572 :デフォルトの名無しさん:2013/11/07(木) 20:27:59.89
狐に包まれるって一定数あるのか
つままれるしか出会ったことなかったが

573 :デフォルトの名無しさん:2013/11/07(木) 20:42:44.73
狐煮つつままれもん

574 :デフォルトの名無しさん:2013/11/08(金) 01:38:03.63
haskellで書いたら10年以上経っても完成せず放置、という壮大なネタか。

575 :デフォルトの名無しさん:2013/11/09(土) 02:36:54.11
ageちん

576 :デフォルトの名無しさん:2013/12/10(火) 06:40:19.22
勉強とか言うのって、どうでも良いFrameworkやAPIレベルの使い捨て土方だろw
プログラマって、OSやコンパイラ、ゲーム、論理パズル的なものを解く連中だって

577 :デフォルトの名無しさん:2013/12/10(火) 06:44:15.52
>>563
ロボティクス用のApplicationがあるとかでpythonに移行してなかった?
おまけに、Railsを教える始末。
lispでgimpを書いてた時代の方が、遥かに高度なことしてる印象。

578 :デフォルトの名無しさん:2013/12/10(火) 06:47:58.94
>>547
実際にコード書いて言えよバーカ
知識詰め込むだけ上手くいくわけねーだろ
試行錯誤繰り返してる過程で、はじめて身に付くのに

579 :デフォルトの名無しさん:2013/12/10(火) 09:51:19.74
>>577
gimpってlispで書かれてたの?
CAD系で使ってたのは良く聞くけど、それももう置き換えられたよね。

lispでgimpを書いてた時代とやらよりも、現在の方がずっと高度なアプリが多いよね。
そのギャップについて考えてみたら?

580 :デフォルトの名無しさん:2013/12/13(金) 01:05:55.64
>>579
今でもgimpの一部はlispだと思う。
プラグインはlisp(の一種)で書けるし。

581 :デフォルトの名無しさん:2014/02/25(火) 11:56:03.68
関数型とLambda expressionって、
関係あるのでしょうか?_・

582 :デフォルトの名無しさん:2014/02/25(火) 21:19:28.36
関数を引数として渡せないと関数型で無いような・・・

583 :デフォルトの名無しさん:2014/02/26(水) 09:51:20.68
あ、関数型言語ってのは、関数を引数で渡せるのね。
ウィキ読んでも、ITニュースサイト読んでも分からなかった。。。

Lambda expressionてのは、中途半端な引数表現であって、関数型言語には不要となる?_?

584 :デフォルトの名無しさん:2014/02/26(水) 09:53:15.70
>Lisp VS 関数型言語

という優位性の戦い的にはどうなのでしょう?

585 :デフォルトの名無しさん:2014/02/26(水) 10:21:14.32
>>583
その理解不十分だから(´・_・`)

586 :デフォルトの名無しさん:2014/02/26(水) 11:04:45.61
Haskellにラムダ式があるというのに...ラムダ式が中途半端であるものか。

あと、関数がファーストクラス、という表現がよく使われるけど、
プログラミング言語において、ファーストクラスである、と言った場合、
・変数の値にできる
・関数の引数にできる
・関数がその値を返すことができる
の全部を満たすものを言う。

587 :デフォルトの名無しさん:2014/02/26(水) 11:10:24.04
λ式リテラルがない純粋関数型言語もあるから半端といえば半端だな。

588 :デフォルトの名無しさん:2014/02/26(水) 12:21:14.62
SKIのこと?

589 :デフォルトの名無しさん:2015/02/28(土) 17:01:13.96 ID:YgrnGK1O
>>517
あっちのスレってどこ?

590 :デフォルトの名無しさん:2015/03/01(日) 07:18:55.48 ID:DUU6fIvY
「TaPLも読んでないJaver」などと決めつけているのを見ると
関数バカは妄想世界の住民だということがよくわかる。

591 :デフォルトの名無しさん:2015/03/01(日) 07:22:00.52 ID:DUU6fIvY
関数バカはJavaを敵性言語にしたがるけど
Javaは静的型付言語だし関数プログラミングもできるという罠。

592 :デフォルトの名無しさん:2015/03/01(日) 07:24:09.27 ID:DUU6fIvY
Javaを身内と認めるには意識高いエリート意識が邪魔をするw

593 :デフォルトの名無しさん:2015/03/02(月) 13:29:46.42 ID:UbvPkyEF
自己紹介3連投乙wwww

594 :デフォルトの名無しさん:2015/03/08(日) 17:02:57.91 ID:h/xKbxWo
>>586みたいなバカ信者がHaskellをバカ言語にするw

595 :デフォルトの名無しさん:2015/03/31(火) 12:46:01.35 ID:yCteYCWo
LISPもHaskellもバカはお断りだもん
最近LISPの罠?からHaskellがなぜ理解できないかやっと理解できた
基本HaskellもLISPの構文糖衣でLISTの構造を認識しながら
LISPなりHaskellなりでプログラムを組めない奴は
複雑なプログラムをLISPやHaskellで組めないし読んで理解することも難しい
一言で言うオレはバカと言うことが理解できた
罠と言うとシンプルなLIST構造を処理するプログラムが例に上がるけど
現実はシンプルなLIST?何それだろ

596 :デフォルトの名無しさん:2015/04/04(土) 13:14:22.44 ID:CCIpT+OI
>>595
案に Computer Science 向けだと言いたいのか。
もしそうなら、お前さんの言う「バカお断わり」ということはないと思う。
教科書や入門書はたくさんある。

お前さんは、むしろ、独学でプログラムを学べたのだろうからすごいと思うがどうだろうか。

597 :デフォルトの名無しさん:2015/04/04(土) 16:42:50.74 ID:vnA/3gIx
はぁ?
schemeなんて、エディタの使い方を覚えながら最初に学ぶ言語だぞ

598 :デフォルトの名無しさん:2015/04/08(水) 12:14:56.80 ID:cDkL0Wby
2ちゃんねるの「なんちゃって関数型クラスタ」ども、これ読んで学び直せ

悔しかったらおまえらも本を出してみな?


http://www.amazon.co.jp/dp/4798043761

599 :デフォルトの名無しさん:2015/04/09(木) 00:32:21.40 ID:JouQxtnc
毒電波www

600 :デフォルトの名無しさん:2015/10/06(火) 17:35:00.47 ID:ZA2UYVtv
大人の玩具なんだよなあ・・・

601 :デフォルトの名無しさん:2016/01/16(土) 21:03:20.30 ID:0sqpR6Ox
>>598
このラノベどうなったの?

602 :デフォルトの名無しさん:2016/01/17(日) 08:20:41.94 ID:uDJuib3V
>>601
版元品切れ再販せず電子化せず、でこのまま消滅の流れ。
めでたしめでたし。

603 :デフォルトの名無しさん:2016/01/17(日) 09:37:47.38 ID:402lz3vg
あんな糞本売り切ったのかよ毛の壁wwwwww商売巧いなぁ

604 :デフォルトの名無しさん:2016/05/01(日) 17:03:07.87 ID:tKi6j9CT
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?

Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
1う

605 :デフォルトの名無しさん:2016/05/11(水) 12:18:41.22 ID:Knti35lY
ドカタ以下の素人なんですが
式を並べてる時点で手続き要素はあるわけですよね?
単体のロジックは洗練されて(理解出来ないけどw)書けるみたいですが
手続き要素を効率的に扱うには向かない言語って事なんでしょうか?

606 :デフォルトの名無しさん:2016/05/11(水) 13:44:24.99 ID:KjfMjcYu
関数型だと向かない手続き型の記述って何かあるかね?

607 :デフォルトの名無しさん:2016/05/11(水) 16:45:01.39 ID:Ve1vbrOx
>>605
モナド!モナド!

608 :デフォルトの名無しさん:2016/05/11(水) 19:33:00.70 ID:ImYRRnyG
>>606
値の破壊的操作とか?

609 :デフォルトの名無しさん:2016/05/11(水) 22:25:17.30 ID:KjfMjcYu
>>608
えーと、純粋なら出来ないんだから記述もクソもないわな?
純粋でないならいくらでも好きにしろ

610 :デフォルトの名無しさん:2016/05/12(木) 12:45:56.31 ID:58XsWeCT
ゲームみたいに状態遷移が中心のプログラムだと書けるのは書けるんだろうけど
あんまメリットが少ない気がする

数学シミュレータみたいな印象受けるんだけど、数学苦手だと全体の見通しが非常に難しいよコレw

611 :デフォルトの名無しさん:2016/05/12(木) 13:22:05.98 ID:ioFrpPF7
参照透明性の利点が分からないんだったらもういいんじゃねーの?
好きなだけバグだらけのもの書いてればいいじゃん
どうせその辺は自分で体験しないと頭で想像できないバカにはいくら言っても伝わらん

612 :デフォルトの名無しさん:2016/05/12(木) 14:03:54.38 ID:58XsWeCT
きちんと組めれば透明性が有利なんだろうけど
きちんと間違った動作のプログラム組んじゃいそうだよ

613 :デフォルトの名無しさん:2016/05/12(木) 21:17:01.69 ID:wtk4J6jy
馬鹿はOOPやってれば良いだろ・・・と言いたいところだけど、次世代の言語は
Haskell一択になるからね。
馬鹿でも使えないといけない。
使えるようにならなければ廃業するしかない。

614 :デフォルトの名無しさん:2016/05/12(木) 22:52:47.25 ID:8TC1mk7E
純粋な関数型言語でも破壊的操作できるしな
Strefとか

615 :デフォルトの名無しさん:2016/05/12(木) 23:10:15.34 ID:zYz5PexE
>>614
それは純粋…なのか?

616 :デフォルトの名無しさん:2016/05/13(金) 00:06:04.14 ID:aPWpKB+z
STRefやSTArrayを使ってもIOと同じく純粋なんじゃない?
unafePerformIoは流石に純粋な関数じゃないけど

617 :デフォルトの名無しさん:2016/09/02(金) 11:30:53.61 ID:D4RF+Hn1
純粋てそんなに大事か?

618 :デフォルトの名無しさん:2016/09/07(水) 03:49:40.44 ID:9Lt8mKWi
関数型に習熟する程、コードが難読暗号化していくんだよね
結局、人間の脳の思考は手続き型なので、相容れない

619 :デフォルトの名無しさん:2016/09/07(水) 08:57:13.44 ID:a2mDvCkE
文系バカは黙ってろよ

620 :デフォルトの名無しさん:2016/09/07(水) 11:54:58.12 ID:a0LGmt6T
バカでもつかえる言語がいい

621 :デフォルトの名無しさん:2016/09/07(水) 13:38:27.31 ID:jchB9RaR
状態のある関数を避けようとしても結局最後には必要になるんだよな

622 :デフォルトの名無しさん:2016/09/07(水) 14:11:30.18 ID:puejZ238
関数型は状態を扱う箇所を局所化しやすいだけでそりゃ状態はどっかで扱うよ

623 :デフォルトの名無しさん:2016/09/07(水) 16:43:13.31 ID:jchB9RaR
純粋関数支持者は理想の世界だけで生きててなかなかそこから抜け出さないんだよな
現実のどろどろした世界は一切触れようとせず、最後の最後でどうしても必要に
なると初めて触れるんだよ

624 :デフォルトの名無しさん:2016/09/08(木) 00:39:46.00 ID:UIDqcnzL
4年前のスレか
まだ生きてるのか

625 :デフォルトの名無しさん:2016/09/08(木) 00:40:58.48 ID:UIDqcnzL
>>581>>583はtanakhか?

626 :デフォルトの名無しさん:2016/09/08(木) 01:09:27.51 ID:5Hkt65M1
>>623
それでアプリ動くならいいんじゃねーの

627 :デフォルトの名無しさん:2016/09/09(金) 21:09:27.70 ID:oMlYA35z
逃げてるからいざさわると不自然になる

628 :デフォルトの名無しさん:2016/09/10(土) 18:41:34.87 ID:7WgbQe9V
モナドが汚い部分を全部吸ってくれる
空気清浄機のフィルター的な存在

629 :デフォルトの名無しさん:2016/09/10(土) 20:15:01.99 ID:vL431mpn
クソが詰まってる感じ?

630 :デフォルトの名無しさん:2016/09/19(月) 10:59:05.14 ID:VmTCwx9N
聳え立つ糞
mtl

631 :デフォルトの名無しさん:2016/11/15(火) 20:14:40.42 ID:q7LJNjlP
たまにコンビニでモナド買って食べたくなるよな。

632 :デフォルトの名無しさん:2016/11/17(木) 02:07:42.46 ID:zLkSWGjU
競技プログラミングの問題だとHaskellでエレガントに書ける場合が多い…気がする
現実の入出力の多いシステムの開発でどこまで役に立つかは知らん

633 :デフォルトの名無しさん:2016/11/17(木) 02:48:09.51
いや、競技プログラミングだと書きにくい。
最初の一問目だと条件緩いから良いんだけど、三問目くらいからかなりキツくなる
Haskellは油断するとオーダー滅茶苦茶嵩むので簡単にTLEするし、非道いときには想定解で実装してもギリギリ時間切れ喰らうこともある。
最悪なのはHaskellで最適化するのはかなりのウルトラCを要求され、超絶技巧コーディングを試験時間内に気づくのは困難を極める点。
競技プログラミングの条件はC言語で解くことを前提に作問されていて時間やメモリ使用制限が厳しい
Haskellでの参加者は大体前半までの正解者はいるが、後半の問題は提出者は僅かにいても正解者はほぼいない惨状
有名Haskellerでも競技プログラミングはC++で参加してるのが普通

634 :デフォルトの名無しさん:2016/11/17(木) 03:09:31.83 ID:zLkSWGjU
>>633
はぇ〜そうなのか
Haskellだと記述は楽なのだがそういう問題があったか
関数型言語は計算機の低レベルのアーキテクチャと大きくかけ離れてるから
同じコンパイラ型言語だと実行速度の最適化は手続き型言語に比べて限界があるのかもしれんな

635 :デフォルトの名無しさん:2016/11/17(木) 07:58:20.07 ID:p/1dirVW
OCamlならいいんじゃね

636 :デフォルトの名無しさん:2016/11/18(金) 19:51:19.73 ID:SgtZza8z
前スレの>>1の意見を見ると、商業主義に魂を売ってるのが分かる。
プログラミングの過程における新たな発見みたいな価値を全て
否定しているんだな。
玩具でもよくできた玩具ならそれだけで価値はある。
金になるかならないか考えるならプログラミングする必要はないし、
人を雇えばいい。他人にコードを書かせて一番儲かるプログラミング
方法を強制すればいいし、ほかには金を投資する事と営業する事だけを
考えればいい。
コンピュータ使って自分自身で何か作る必要ないじゃないか。

637 :デフォルトの名無しさん:2016/11/18(金) 20:13:59.76 ID:LccmGd/F
>>633
>Haskellは油断するとオーダー滅茶苦茶嵩むので簡単にTLEするし、

これはない
定数部分が遅くなってもオーダーが間違ってるのはHaskellのせいじゃない

> 非道いときには想定解で実装してもギリギリ時間切れ喰らうこともある。

これはよくある

638 :デフォルトの名無しさん:2016/11/19(土) 14:19:16.69 ID:ygHmZoSw
Haskellはうっかり!!!プログラマのせい!!!で計算量を読み違えがちなので競技プログラミングには扱いにくい

参考
http://d.hatena.ne.jp/nishiohirokazu/touch/20100622/1277208908

639 :デフォルトの名無しさん:2016/11/19(土) 14:36:49.50 ID:leXZmGhT
余再帰のコードは必然的に遅延評価絡みなので空間(ときどき時間)のオーダーを読み間違う
遅延評価ならではのコードを書かない限り気にする必要はない
あとは自己責任

640 :デフォルトの名無しさん:2016/11/19(土) 14:37:58.17 ID:leXZmGhT
つうかそもそも競プロコード書いてるときに余再帰コード書くやつは根本的に色々間違ってるだろ

641 :デフォルトの名無しさん:2017/01/10(火) 22:20:35.26 ID:OXhzJIwU
そもそもHaskellは速いコード書く様な言語じゃないと思う。
reverse関数とかは配列と破壊的代入がある方が関数型の半分で済む。

ただ、手続き型より数学に近い言語だからコンピュータの仕組みが理解出来ない人にもプログラミング教えやすいとは思う。
(実際、変数に値を代入する(コピー)って感覚がわからない人はいた)

あと、参照透明だから、入力に依存しない関数はコンパイル時実行とか導入すれば速くなりそう。
去年知ったけど、いつの間にか普通の再帰が自動で末尾再帰最適化(ループへ変換)されてたから、Haskellもまだ最適化の余地は沢山あると思う。
(元々参照透明の強みは積極的な最適化だと言われてる)

今のHaskellみたいに並列処理に特別な関数や型を使うんじゃ無くて、普通に書いたらまんま並列処理できる様にもなって欲しい。
(参照透明の利点。ただ、効率的な並列がやりにくいとも)

それに、現行コンピュータのアーキテクチャから切り離されてるから、量子コンピュータとかにも使えそうとか、家にPCが無くても紙と鉛筆でプログラミング勉強しやすいってのはある。

642 :デフォルトの名無しさん:2017/01/11(水) 00:22:39.53 ID:co962JBH
え、Haskellの実行速度、十分早いんじゃないの

643 :デフォルトの名無しさん:2017/01/11(水) 00:56:53.12 ID:4yaLCJvM
十分速いの定義が曖昧です

Java程度の速度は出ることが十分速いというのなら十分速いのでしょう
しかしC++/Cにはどうしても及びません

それから、この文脈のはやいは早いでなく速いがより適切です。

644 :デフォルトの名無しさん:2017/01/11(水) 01:30:51.23 ID:co962JBH
とりあえず2chで誤字脱字の指摘はせんでえーよ。
変換間違えてもめんどいからそのまま書き込むし

645 :デフォルトの名無しさん:2017/01/11(水) 04:54:14.36 ID:qB6hV9pT
充分速いけど、手続き型よりコンピュータの特性活かしたコードにならないから。。。
単純に速さ求めるなら手続き型に敵わない。
保守性の高さとか、並列処理の書きやすさとかが関数型の利点。
万能だとは思わない方がいい。
(単純に関数型ならではの最適化を実装出来てないだけかもだけど)

いあ、ある程度の速度低下を許容出来るほど書いてて気持ちいいが。

646 :デフォルトの名無しさん:2017/01/11(水) 08:14:15.91 ID:co962JBH
んー配列上のいくつかを入れ替えるってんならそりゃCの方が速いよね
がもうちょっと高度なロジックとかで遅延評価なども生きた時にともすればCを上回る時ガーって無いのかと。
いやじゃあその遅延評価もCで実装すればとかになっちゃうので結局人間のある程度の最適化+コンパイラの最適化でこの規模のこういう奴だとHaskellの方が速かったって事例があるかって話になると思うのだけど。
まあそれよりも生産性の高さとかが土俵ってのは認識してる

647 :デフォルトの名無しさん:2017/01/11(水) 11:20:16.02 ID:Q05JSKiv
取り敢えずC#には勝ちたい

648 :デフォルトの名無しさん:2017/01/13(金) 06:50:42.54 ID:tNTQooLV
>>646
安全性、生産性、速度が欲しいなら、素直にML使えよ

649 :デフォルトの名無しさん:2017/01/13(金) 08:10:23.06 ID:8MbrIHvk
F#でおけー

650 :デフォルトの名無しさん:2017/04/04(火) 12:35:32.05 ID:yB9dvwaO
ここまでC#圧勝

651 :デフォルトの名無しさん:2017/05/22(月) 00:29:15.41 ID:MWG7Yl6s
x = x + 1
やっぱりこの式不自然なんだよ
確かに最初は漏れも違和感はあったさ

慣れちゃったけどw

652 :デフォルトの名無しさん:2017/05/22(月) 04:32:34.68 ID:DJqDUcnH
n
Σ f(i)
i=1
も不自然か?

653 :デフォルトの名無しさん:2017/05/22(月) 11:59:31.98 ID:N2jskJZQ
Σ f(i)
i ∈ {1,2,..,n}

でないと不自然だと思う派

153 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)