一般的な処理を関数型の書き方をすると遅い
■ このスレッドは過去ログ倉庫に格納されています
関数型に適した問題を、
関数型に特化した言語でやって
どうにか速い例が見つかる程度。 副作用を起こさないから、配列を処理して配列に入れなおしてって
やってるから、メモリコピーのコストかかるし、メモリ使用量も増えるしね。 普通にループで書いてブロックの中に処理書けばいいのに、
関数呼び出しにしてしまうからその分のコストもかかる。 >>4
その辺は最適化次第な気がする。
まあ、それを前提にしてる言語(Haskellとか)でないとそういう最適化もやりづらいだろうけど。 意味分からん。
Rubyの時点で遅いだろ。
無理せずC/C++を使えよ。 次から次へと自分の無能を宣伝するスレを立てて嬉しいのかこのバカは? 「一般的な処理を関数型の書き方をすると遅い」
それは体感とか実測からくる事実なんだろう
しかし、それだけなら関数型の書き方にできる機能など誰も盛り込まないはず
速度を失った代わりに得たものがあるんじゃなかろうか
たまたまそれが >>1 にとってメリットに感じなかっただけで
だから、考えもしないでやめればいいのにというのは安直だ
ところで、関数型の書き方って何? はっきりした定義はないけど…たぶん >>1 が例に出したRubyでなら
生のループ文を使わず、再帰やcollect/select/detect/inject/rejectなどを使い
ifやcaseの分岐は文ではなく式として用いて
変数への再代入をしないプログラミング…って感じじゃね? 関数を一級のオブジェクトとして扱うのが関数型の書き方に決まってるだろ
それ以外あるのか >>15
ループの代わりに再帰を使うとか、副作用がないとか >>15
そこでいう「関数」が何を指すかが問題だ
数学的な関数に近い意味での関数表しているのか、
C言語みたいなプロシージャに近い意味での関数を表しているのか
前者なら、関数を一級のオブジェクトとして扱うだけじゃ
関数型の書き方というには足りないと思う >>17
まったくわかってない
再帰は手続き型言語でも普通に使うし
対象が数学的関数なら手続き型言語で書いたって副作用はない
例
int fib(int n) {
return n < 2 ? n : fib(n-1) + fib(n-2);
} >>21
うん、でも関数型でよく使われるものでしょ。
だからそれを関数型の書き方と言ってるのかもしれないと
予想できるでしょ。文章を理解する時ってそういうふうに
推理するものだよね。相手が言ってることを偽になるように解釈して
いったら辿り着く先は誤解でしかないと思うけどなあ。 >>22
でももへちまもないよ。おまえの理解は間違ってる
関数型言語の特徴は高階関数を使うことだっていってんの
そのために一級にしてるんだから >>23
間違ってるかどうかは言った本人に聞かないとわからないでしょ。
あなたが判断することではないし、あなたが判断できることでもないよ。
だからあなたが何言おうと無駄だと思うけどなあ。
自分の解釈が絶対正しいんだーなんてのは思い込みだよ。
世の中に絶対なんてことはないんだ。常に自分を疑うべき。 そういうメンドクサイ哲学的な話に興味ないからもういい
俺が言いたいのは、再帰や副作用なしってのは関数型言語と関係ない
ということだけ メンドクサイことは好きなんだろ
くだらない日曜夕方の雑談に花咲かしていけよ >>25
そういう解釈ができるってだけの話だね。
相手の言うことを理解するときに自分の物差しで
測ってどうこう言ってもしょうがないと思うけどなあ。
そういうことやって周りの人間とうまく関係を構築できるものなのかなあ。
あなたの人生が心配です。 遅いかどうかの話。
関数型に適していない問題を
書き比べてみればいい。 時々関数型言語は速いなんて反論を見るけど、
それ一部の処理を省略することができる問題を
関数型言語では省略して、
手続き型・オブジェクト指向言語では、省略しないで
不公平なコードで比較しているんだよね。 ではクイックソートの実装を関数型言語 VS C言語で
比較してみましょう。 代入の代わりに遅延評価が使えず、新しく生成するようなプログラムは遅くなるし、リソースを無駄に使う
だから純粋関数型言語ではなく、scalaを使って手続き型と関数型の良いどこどりしましょうね〜 速いのが良いならアセンブリとCだけ使っとけばいいよもう なかなかおもしろいことになりそうだw
http://elephnote.com/blog/archives/838
> Togetterにいろいろな主張のまとめがありました。曰く、
>
> 「In-placeソートでないからだめ」「というか遅い」「いやHaskellに効率を求めてはいけない」
> 「5行の例はPivotingをしていないのでだめ」「Pivotingはクイックソートの本質ではない」
> 「メモリを抽象化していて扱えていないのでとても遅い」
> 「Haskellでメモリの議論をするべきでないしIn-placeソートでなくてもよい」
> 「Haskellでクイックソートをしっかり書きたいなら手続き型風に書くのが良い」 そもそもなんで最近になって微妙に流行ってんの?
スクリプト言語が採用したから? >>36
jQueryが間接的な発端じゃないでしょうかね?
jQueyrは関数型に似ている
↓
関数型言語とはなんぞや?
↓
関数型言語とはうんぬん(略) ゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミwwwwwwwwwwwwwww >>40
ゴミで何が悪いんだ、夢の島にうめたろか? フィルターのメソッドにブール型を返す関数とかを入れるってのは凄くいいと思うよ ゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミゴミwwwwwwwwwwww >>36
流行ってるって2ちゃんの話だろ?
具体的なショーケースはなにもない
LispやD言語やVBのスレが勢いある2ちゃんの話だろ VBのライバルであるDelphiを忘れないで下さい。 デカイサービスやビジネスに採用された例ってあんの? >>35
わかりやすさでは、Haskellの圧勝。 このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所 >>1
一般論を言えばその通りだ
性能に関して言えば、関数型に適したアルゴリズムやデータ構造の
研究/開発と、その普及が重要になってくる
たとえばアルゴリズムであればメニーコア時代の並列処理や
モナドに代表される圏論を応用したソフトウェア部品化技術、
データ構造であれば「永続データ構造」や「メモ化」(Wikipedia等を参照)が
キーワードになるだろう
Rubyなら、こんなGemがあるね
・Ruby で並列実行処理を簡単に書く
http://subtech.g.hatena.ne.jp/secondlife/20110927/1317123109
・Rubyで関数型プログラミングをするための ImmutableList gem を公開
http://gam0022.net/blog/2013/10/22/immutable-list-gem/
あとOSX/iOS上の並列技術であるGCDは、MacRuby/RubyMotionから
お手軽に使えるから、Macユーザにはお薦めだね
・ASCII.jp:マルチコア時代の新機軸! Snow LeopardのGCD (1/4)
http://ascii.jp/elem/000/000/455/455786/ >>1
そんなわけない。
今後は、マシンパワーをフルで使う処理こそ関数型になってくだろ。
遅いのは処理系。 関数型でしか書けないってのは強い制約。
わざわざ不便にするのは、実行の流れを無くすためとか。
そうなれば、主導でマルチスレッドプログラムせずに、自動でマルチスレッド対応に出来る。 >>47
多い土方が使用してないんじゃ流行ってるとは言わないだろ まあ遅さが問題にならないとこで
物好きだけが使ってればいいんじゃないでしょうか 関数型は遅いダメだろ
時代はウインドウズでC♯とVBを極めるのが最強。関数型は絶対に使うな!
VBとC♯だけに集中して関数型は使わないようにするのが情強だぞ。絶対に使うな。関数型はクソだとみんなも言っているだろ。VBとC♯だけをやるのが正しい。絶対に関数型は使うな。関数型はクソだ。 代入が出来ないとか強いプログラム上の制限がある分、速く出来るのが普通だ。
翻訳、コンパイルするほうの性能が悪いだけ。 関数型を使ってみました。
目から鱗でした。
目には鱗が付いていることがわかりました。
これはすごいです。
ナチュラルかつ完璧な制約があります。
ごく自然な形で制約を受け入れたコードが書けるのです。
制約は私を縛るものではありませんでした。
構文上のみならずロジック上の誤りすら見つけ出してくれるのです。
コンパイルを通ればバグが無いことが保障されました。
そして、生成されたコードは速いです。
Cの二倍速いJSよりさらに早いです。
これはJSなんか使ってる場合ではないと思いました。 関数型で書けないコードってあるの?
ヒープソートとか辛そうだけど Javascriptは関数型ハイブリッド言語。
Javascriptのクイックソート。
QuickSort = function (X) {
if (X.length <= 1) return X;
var pivot = X[0];
return (new Array).concat(
QuickSort(X.filter( function(x){ return pivot>x;})),
X.filter( function(x){ return pivot==x;}),
QuickSort(X.filter( function(x){ return pivot<x;})));
}; Scalaのクイックソート
def sort(xs: Array[Int]): Array[Int] = {
if (xs.length <= 1) xs
else {
val pivot = xs(xs.length / 2)
Array.concat(
sort(xs filter (pivot >)),
xs filter (pivot ==),
sort(xs filter (pivot <)))
}
}
https://sites.google.com/site/scalajp/home/documentation/scala-by-example/chapter2 >>64
手続き型で書いた場合と比べると読みにくいし、理解するのが難しい
それでもって速度はJava以下
笑えるな >>66
このコードはクイックソートのロジックそのものだろ
脳みそ腐ってんじゃねえの マルチコア時代のプログラマは関数脳になろう
CPUのクロックアップに限界が訪れ、マルチコア化することで処理性能向上を目指す時代になりました。
これからのプログラマには、マルチコアで処理性能が向上するプログラム=マルチスレッドで並列処理が可能なプログラムを書く能力が必要になります。
今回は「関数型」でプログラムを書くことによって、いとも簡単に並列化ができることを実例を元に解説します。
http://tech-sketch.jp/2013/08/parallel-functional-programming-1.html
現場で活かす関数型プログラミング
クラウドやマルチコア、メニーコアを利用する大規模並列型のシステム開発を行なう上では、プログラミング言語の選択も重要になってきます。
そんな中でここ数年注目を浴びているのが、Haskell,OCaml,Scala,F#などといった関数型言語です。
ですが、関数型言語は、並列処理等の複雑なアルゴリズムを 記述するだけの言語ではありません。
http://www.mamezou.com/training/f_pro.html
プログラマが知るべき97のこと/関数型プログラミングを学ぶことの重要性 - Wikisource
最近プログラミングコミュニティでは、再び関数型プログラミングへの関心が高まっています。
その理由としては、業界全体でマルチコアヘの移行が進んでいる、ということもあるでしょう。
移行によって生じる新たな課題への対処に、関数型パラダイムの持つ特性がうまく合致することが明らかになってきたからです。
重要なのは、参照透過性(referential transparency)が向上するということです。
参照透過性が高い、というのは非常に素晴らしいことです。参照透過性が高いとは、関数がどこでいつ呼び出されようと、入力が同じであれば、
常に得られる結果が同じになる、ということを意味します。
つまり、関数の評価結果が状態変化の副作用に左右されることが少ない(あるいは、まったくない)ということです。
http://ja.wikisource.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%8C%E7%9F%A5%E3%82%8B%E3%81%
B9%E3%81%8D97%E3%81%AE%E3%81%93%E3%81%A8/%E9%96%A2%E6%95%B0%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A
9%E3%83%9F%E3%83%B3%E3%82%B0%E3%82%92%E5%AD%A6%E3%81%B6%E3%81%93%E3%81%A8%E3%81%AE%E9%87%8D%E8%A6%81%E6%80%A7 関数型で書いても並列処理の結果は結局共有部分で受けないといけないのではないんですか 処理を関数型のイディオムに落とし込むのがだるい
パフォーマンスをいちいち考えないといけないのがだるい
数学みたく、無限の計算リソースがあるならまだしも 適当に書いたC>>>>>>クソ遅いゴミ言語による並列処理 CPUのマルチコア化が関数型普及の引き金
現在,皆さんが使っているパソコンを見てください。ちょっと昔のを使っているんでしたらCore2 Duo,今どきの新しいものでしたら,Corei7とか5とか3とか。
CPUの中身の配線の問題でこれ以上の集積化は難しくなってきたので,CPUコア数を増やす方向で処理能力を上げることになりました。
それが,Core iシリーズです。Core i7は1つのCPUの中に4コア入っています。コア数が複数個あるので,マルチコアCPUと言われています。
さて,話を戻します。そうしたマルチコア・マルチスレッドCPUのパワーを引き出せるのが,関数型プログラミング言語だと言われています。
CPUのマルチコア・マルチスレッド化で今もっとも注目され,再評価が進んでいます。
実は関数型プログラミング言語とは,突然現れたものではありません。1970年代頃からあるもとしてLisp(リスプ)が有名です。
関数型の特徴として非常に抽象度が高いコードになるので,一見判読しにくいことがあります。
しかし,ほんの数行コードを書くことで,スゴイ処理を実行できるので,プログラマーや研究者達の知的好奇心が沸き立ちます。それが魅力なのです。
http://gihyo.jp/book/pickup/2013/0089?ard=1391594763
10月25日 マルレク2013「クラウドとクラウド・デバイスの新時代」第五回(東京都)
講演概要
「関数型言語と並列・分散処理」
マルチコアの下でのプログラミングについては、丸山は今年1月のクラウド研究会で、「関数型言語と並列・分散処理」という講演を行いました。
そこでは、ハードウェアのMany-Core化がやむことなく進み、ソフトウェアのParallel化の要求がますます高まる中で、
ソフトウェア側の対応が遅れているという認識から出発しました。
1月の講演は、Many-Coreのパワーを引き出す上で、Data Parallelの手法を効率的に表現出来る関数型言語の有効性に注目したものです。
http://kokucheese.com/event/index/119193/
「世界は並列的に進行していて、人々も並列で動いています。コンピュータも並列で動いているのなら、なぜ逐次型プログラミング言語に固執する必要があるのでしょう。」
NI LabVIEWソフトウェアの生みの親であるJeff Kodoskyは何年か前のNIWeekでこのような質問を投げかけました。
http://www.ni.com/newsletter/50473/ja/ 最適化技術が進歩すれば分からなくなるけどな
超でかい配列 -> 処理 -> 処理 -> 処理・・・
これを自動でテンポラリ使うか遅延評価使うかを判断して
メモリアクセスパターンも考慮して最適化してくれるなら
使ってやってもいい 関数型言語を使えばクイックソートが
並列で処理可能・・・ってことには
ならないんだよな。 >>75
ん? たとえばDVDを読み書きするとして、
並列で行うならば、レーザーが複数なければ
いけないはずだけど? >>76
100万の数値をソートするなら50万50万に分けた後で並列化できないの? >>78
いえ、だから関数言語を使うだけで簡単に並列可能に!には
ならなくて並列可能なアルゴリズムに作り変えなきゃならないでしょ?って話。 >>78
手続き型で並列化するには特別なコードが必要
関数型なら普通に書けば・・・ 特別と言ったって
たいして特別でもないよなぁ。
ローカル変数使っていればいいだけだし。 関数型に不可能なことはないのです。
なぜなら自分自身を書き換え進化していくことができるからです。 いや、普通のクイックソートを書けば自動で並列化してくれる
夢の言語に対して並列化のための特別な(余計な)コードが必要という意味で >>78が書いているように
> 100万の数値をソートするなら50万50万に分けた
という、分ける処理をしないといけないしね。
1. 分ける
2. 並列で処理する
3. 統合する
単なる1工程で良かった処理が
3工程に分かれてしまう。
もうこれアルゴリズムが変わってるから。 ScalaだとActorクラスをラッパーとして使えばいい感じにできそうだけどそれも無駄なコードだからなあ RPGの町にいる人みたいに各々がその他と
かかわらずに独立しているようなものなら
並列化しやすいんだけどね。
多くの問題は、一つのデータの塊を扱うことが多い。
その塊を処理するには、小さな塊に分割して
終わった後に合わせるという作業が必要になってしまう。
入力データが一つで、出力データも一つだから
並列化しにくいんだよ。 >>87
その人達を並列化しても当たり判定とかを世界全体で同期しないといけないから意味なくね >>88
同期する量が少なければいいんだよ。
ソートなんか典型的な全データを同期しなければ
いけない処理だからね。 やめろ!おまえら関数型を知るな!
C♯とVBの方がいいぞ!Javaがいいぞ主流だぞ!
関数型はクソだ!!!みんなもクソだと言っているから誰も使ってないだろ
みんなC♯とVBを使ってるだろ。みんなと同じ方が互換性があっっていいのです。関数型は忘れましょう。関数型はクソだぞ使ってると恥ずかしい笑われるぞ。 簡単な例は手続き型でも簡単にかけるしな
簡単じゃない例は関数型でも難しいしな
並列をウリにするのはおかしい そもそもshared mutable stateが問題になるほど複雑な並列処理を行うプログラムを作る人間がこのスレにいるのかどうか >>91
だな
関数型よりC♯とVBの方が優れてるよな。おれも同意するわ。
>>92
関数型教だよなwww
惑わされずにC♯とVB使うのが情強だ。
>>93
だな。
おれも同意する。C♯の方が良いとみんなも思ってるよ ドカタ用の汎用プログラミングを侵食するものではないから不安がることは無いよ ランダムアクセス(readもwriteも)がO(1)で
クローンがO(1)であるような、リストって作れる?
これが出来れば並列プログラミングがぐっと楽になるぞ? >>97
どうすんの?普通の俺んちのパソコンでだぞ? >>99
みつけた。VListか?
これなんでみんな使わないの? これ最強じゃね?普通な配列におとるかもしれないけど
参照でやれば効率いいけど誰かが書き換えないか心配
コピーしてしまえば楽だけど・・・っていうトレードオフをしなくて良い
さっそく、俺の愛用するC#で実装してみるかな >>73に一歩近づいたかっていうか
研究者は2002年の時点でこれやってるわけだから
まだ普及した実装がないだけで、今分かっている研究を全て
集結させたコンパイラ作ったらかなり最適化できるのかな データ集合体へのアクセスパターンを認識し、集合構造を最適化します。
これは知識と呼ばれるものと同じであり、近い将来において、人工知能に
進化する可能性が危惧されています。 関数型の利点は並列プログラムをしなくても、意識しなくても、コンパイラが対応すれば出来てしまうところ。
1コア、10コア、100万コアでも同一コードで動かせる。
純粋関数型で、対応コンパイラがあれば。 >>105
残念ながら、現在の並列関数型言語処理系の研究で成果を挙げているのは、
メモリを共有する密結合型並列方式のみ
そして今後半導体の集積技術がどこまで進化するのか予測は難しいが、
せいぜい数十から数百で限界がくるから、
結果的にHPCの世界で研究されている粗結合型超並列へと向かわざるをえない
それを、従来のアルゴリズムで書かれたプログラムを粗結合型並列へ自動変換できる
魔法のコンパイラがたやすく実現できるものだと想像してしまうのは、
素人の浅はかな考えと言わざるをえない >>77
並列に動く複数のレーザを備えたDVDドライブがあれば、
関数型言語でもI/Oを並列に処理できるよ。 >>64
なんかScalaって読みにくいな
何が読みにくいかって、
xs.length とメソッドっぽい書き方、Array.concat(...) とモジュールっぽい書き方、
と思えばsort(...) と普通の関数っぽい書き方、
さらには xs filter (...) と中置記法の演算子のような書き方、
さらに (pivot >) では中置記法の演算子を部分適用、
なんだかsyntaxが盛りだくさんで統一感がないように思えるんだが。 CだってCで書きやすいようにCPUが設計されてたりするんだし
関数型で書かれたコードを動かすことが前提のプロセッサがあってもいいんじゃないの?
そういうのは世に無いの 標準のコレクション(List)が連結リストな時点で、速いわけがない。 VListちょっと思ってたのと違うな
fully persistent arrayっていうのが俺の思ってたのに近い
これはclone, read, writeがlog(log(操作数)) Haskellは問題によってはアセンブラより速いらしいよ。 誰も釣られてくれないようだな。下手糞なアセンブラよりも早いってことかな。 たらいまわし関数をgccとsbclで試したら僅差でsbclの方が速かった 細かいところ並列化しても遅いまま。でかいところは、並列化する方法はすぐわかる。 細かいところの並列化って
パイプラインとかスーパースカラでやってるじゃん?
CPU処理の並列化
で、この機能の限界の原因は、なんでも並列化出来るわけじゃないんだよ。
前処理の計算結果に依存する処理があるから並列化出来ない。
これは関数型言語にしても当てはまる話で
できないものはできない。
で、>>116が言うように、でかいところは並列化する方法はすぐわかる。 関数型に魅入られた人は我々と違ってなんか宗教のように関数型を推すけど
あれはなんなんだろうか。なにか彼らの中で現行の言語で許せない何かがあって
よくわからない"それ"からの解放が宗教的恍惚をもたらすのだろうか?
たとえば俺はRPNの電卓を愛用していて日常的に2*3+4*5を
2ent3*4ent5*+と操作して計算しているわけだが
この方が計算機の構造に合ってるしエレガントで速いとは思うものの
「これからの数学では2*3+4*5は2ent3*4ent5*+と表記すべき!未来はそうなる!」
なんてあたまおかしなことはそれが引き起こす「副作用」を考えると
とても言えないわけで。
ちょうど俺が最近のC++やらなんやらのわけのわかんない型や書式、クラスの氾濫に嫌気が差して
あの「なんでもクラスだ」「クラス名は読んでわかる奴にしろ」「メソッドも見てわかるように作れ」で
長い名前だらけでキートップの磨耗をできるだけ防ぎたいプログラマーに絶不評のObjective-C最高じゃん?
ってなってんのと逆ベクトルで、関数型こそ至高!ってなる…なにがあるんだろう? >>118
近頃の関数型言語周辺の雰囲気は、C言語全盛時代のパソコン通信における
「オブジェクト指向」の雰囲気にそっくり。 時代は、マルチパラダイムに進んでるけどね。
大枠をオブジェクト指向で作って、細かい部分を関数型で埋める。 クラス=状態がある=テストが書きにくい=管理しにくい
関数=状態がない=テストが書きやすい=管理しやすい そんなに違いは無いと思うけどね。
テストは関数型が断然やりやすいけど。 自分で使ってF#で書いた方がバグの発生率やそれの修正コスト含めて圧倒的にC#より生産性高いので使えるならF#使うわ。
>>121
だいたいそんな感じやね。大枠にするようなものまで関数型にする必要ないしと言って細かいクラスを乱立させる意味は無い。 カリー化って何の役に立つの?
呼び出しコストが何倍にもなるだけだと思うのだけど 機械に対するヒントが手続型より少ないのだから、仕方がないだろう。
Fortranだって早くするには、ディレクティブをたくさん書かないといけない。 >>125
その場その場で適した関数化に役立つ。
むしろ事前適用するので後からの呼び出しコストが減る この関数は副作用ありませんよっていう
キーワードみたいなのが手続き型でも使えれば
デバッグ中にウォッチ式で関数呼び出せたりできて便利な気がする そもそも高級言語は「人間が処理を理解しやすいように」作られてんのに
なんで「こういうわかりにくい書き方をするとこんな利点が!」ってドヤるんだよ >>130
人間が理解しやすい ≠ お前が理解できる 俺にわかりにくいものは、他の誰にも絶対にわかりくい、ってドヤってるバカはおまえだw ×高級言語
○高水準言語
単純にハードに近いか遠いかだけなんだけどな。指摘するのが馬鹿らしくなる位に
高級言語としか書かないのしかいないけど。 High level languageという表現を見たことが無い奴を篩い分けるいい目安なので、
そういう正しい知識を広めるの、やめてくれないかなw >>134
高級言語ならhigh class languageになるな。 関数型言語がまったく普及しないのはコードが読みにくいのに
「これが読める俺tueee!」って厨二病しか支持してないせいだよね… ということにしたいのですね、としか言いようがない。 >>136
んーわかってる人の中では普通に使われてるからねぇ。 Javaで書かれたソフトウェアを使いたくないエンドユーザーが一般に存在することを
考えると、関数型で書かれたソフトウェアがユーザーに受け入れられがたいのは
容易に想像できます。
例えば、ホビーで良く使われるmebed NXP LPC1768はフラッシュ512KB、RAM32KBを
搭載、C++で開発するのが主流です。
RAMが32KBしかないのです。
この環境で関数型を使いたいでしょうか?
ユーザーはパソコン上であっても、関数型で書かれたソフトウェアを敬遠するでしょう。
アイデアは良かったと思います。
関数型は遠い未来には期待が持てると思います。
でも今は・・・ 訂正
RAMが32KBしかないのです。
関数を使いたくないのは、この環境ぐらいじゃないでしょうか? 関数型言語でどういうコードが「読みやすいか」ってのは、手続き型言語やオブジェクト指向言語に比べてまだ定石のないところだとは思う。
カウボーイコーディングで場当たり的に書いていくと、より手の付けられない状態になりやすいのは関数型言語の方、ってのは実感としてあるがどうか。 >>140
遠い過去の世界に生きてる人がなんか言ってる、という感じにしか聞こえない。 >>143
むしろオブジェクト指向より歴史あるんだが(´・_・`) 正直、C++とか筋の悪いオブジェクト指向言語で
ソースの可読性の問題でやたらバグが出て頓挫するようになったから
"ソースの可読性もクソもないコレで書けばバグが出ないよ!"って
滅んだ過去の亡霊が墓所から這い出て来たようにしか見えない。 Haskellはむしろ構文解析はめんどいぞ。
PEGの論文書いた人がサンプルに使ったのが、それが理由でJavaの構文を使ってるくらいだからw まぁ普通に書いたら何でもかんでもオブジェクトにしてスパゲティになるよりも値をトランスフォームしてく関数型の方がバグが少ないのは自明だわな(´・_・`) だがバグのあるプログラムを書く自由は神に与えられた権利
それを脅かす者どもとは戦わねばならない Haskellでもバグのあるプログラムは書けるよ。
単に型システムによって蹴落とされるようなバグだけが、コンパイル時に弾かれる、というだけで。 C++が勘違いして導入した(そしていまも勘違いしてる奴が多い)オブジェクト指向と違って
本来のオブジェクト指向はオブジェクトにコレをやれとメッセージ(メソッド)を送ると
能動的にオブジェクトが自分で対処するという「ロール」としての区切りだから
本来スパゲティもなんもない。 本来の、というより、Smalltalk流の、だな。
Simula流を「勘違い」と定義している奴はそんなにいないと思うぞ。
まぁ観測範囲を偏らせれば、それなりにいるのかもしれんが。 >>153
メッセージの実行方式とメッセージをどこに送るかは何も関係ないんだが…(´Д` ) >>145
歴史があるかどうかは関係ないんだが(´・_・`)
あらゆるソフトウェア、様々な規模のプロジェクトに適用されていて
経験とプラクティスがより蓄積されているのはどっちか言ってみ?(´・_・`) >>156
ドカタは知らんかもしらんが、OCamlもHaskellもLispもErlangも色んなものに使われてるんだが(´・_・`) いろんなものというのはな。
たとえば、・・・あとは>>157が答えてくれるはずw LispはAutocadのマクロに使われていたが、いつの間にかVBAが主流に変わっていた。
使いにくさはいい勝負なのでどっちでもいいけど。 関数型じゃないけど、Paintshop ProはPythonをマクロに導入して、そこから転落が始まり
ついに表舞台から消え去った。
今はひっそりと裏街道をとぼとぼしてる。 例えばお掃除ロボットのAIがlispで書かれてたりするみたい 特殊な用途ばかりだね。
お掃除ロボットって作ったことあるかい? そもそも関数型はアプリのマクロ程度にしか使いようがない。
ブラウザのスクリプトがJSではなくHaskellだったとしたら、現在のJSと同様に
広まったかもしれない。
そういう言語。 関数型は、マルチコアに良いから出てきた。
未来の言語。
まだ、マルチコアに十分に対応したのがない。 それは机上の空論の可能性が高いよ。
マルチコアに良いって言うのが副作用が無いことに依存している時点で、
既に使い道がかなり限定される。
ほとんどのユーザーは副作用のためにソフトウェアを利用するんだから。 オール純粋関数型でなくてもいい。
マルチコアに対応したいところだけでいい。
CPU、GPUをフル活用しても時間食う処理の部分だけ純粋関数型で書く。 副作用はあるけど無い部分とうまく分けられる部分が評価されてるんじゃないの OSがタスク振り分けるからプログラムは自分で各コア勝手に弄るな!ってなりそうだよね >>166
Haskellだって副作用のあるコードかけんだよ。馬鹿じゃねーの >>167 Fortran95以降のpure/elemental functionがそれに該当するかもね。
引数わ書き換えたり(Fortranは基本、アドレス渡し)、ファイルI/Oの処理
が内部で禁止される。
スカラーからスカラーへの関数が、ベクトルからベクトルへの関数に自動的に
拡張されて、自動並列化をONにすれば要素毎の演算がコアに割り振られる。 こんな問題、インライン化できないスクリプト言語だけ ↑
とまあこのように、関数型をマンセーしているのは関数型を使いこなせないでいる人たちってことですわ。
使いこなせる人は悟りを開いて使わない選択をする。
そんな時代ですわ。 まぁ今の時代にmutableデフォで作ることがあり得ないけどな 関数型言語を使いこなすコストパフォーマンスはオブジェクト指向とはさほど変わらないだろうけど、コストとパフォーマンスの総和はオブジェクト指向よりもかなり大きいって感じるなあ。 >>177
C#とF#で作ったもの、概ね速度同等で動くんだが。 なぜそこでオブジェクト指向がでてくるのか理解できない。 >>178
実行速度じゃなくてプログラマの労力の話ね。 >>181
何がコストで何がパフォーマンスなんだよ(´・_・`)
つかそもそもコストとパフォーマンスって足せるのか。 お前のモジュールって必要以上にファンクショナルだよな haskellでforMとかmutable arrayとかRWSTモナドとか使ってると、これもう手続き型言語じゃんって気分になる
でもオブジェクト指向にはなれないんだよな
やっぱ両方使える方がいい x64って何か変なスタックフレームの書き方するよな
再帰呼び出しが遅くなってスタック領域も多量消費すると思うんだけど 製品版はどうせマイクロソフトなんだよ(´・_・`) JAVAで世界が変わる!
JAVAでOSが消える!
全てのソフトウェアはJAVAになる!
JAVA用のプロセッサが開発される!
OOP以外の言語は消える!
と言われていた時代を思い出した。 証拠(笑
そう言うアホみたいな記事で埋め尽くされてた時代を知らない世代の方が多いのかもね、20年近く前の話だものなぁ。
当時の記事は古すぎてほとんど見つからないけど、少しは自分でググれよ。Amazonとかでそう言う本見つかるぜ。 ほとんど見つからないのは、実際の所、ごく一部のバカが「銀の弾丸だ」と騒いだ、
といういつものパターンだからだよw
バズワード化すると、技術の本質ではなくバズワード的な部分しか見ないおまえのような
バカが沸くのも何十年経っても変わらないねぇw 誰に文句言ってるんだろう?
一人で空回りしてるね >>195のこと >>195
何十年も何も人間の本質なんてここ2〜3千年位変わってないだろ。
記録に残ってないだけでもっと昔からかも知れないけどね。 数年前の「安価なAndroidがiPhoneを駆逐するね!」論ぐらいの頻度で
Java無敵論はネットで毎日のように見かけたからなぁ
「おれはバズワードだってわかるもんねうひひ」とか(笑 逆に携帯のOSをオープンソースでなんてあり得ないとか言われてたよね。 今でも、ソースコードらしきものはあっても本当にそれからビルドされてるのか怪しいもんだしな 海上自衛隊のドラム演奏が凄い!東京音楽隊
Haskell's Rascals Paul V. Yoder JapanNavy band
「ハスケルのあばれ小僧」ポール・ヨーダー スネアドラムロール - YouTube
https://www.youtube.com/watch?v=7Stt2bkLSCs >>63
今はこうだな。
var quickSort = (ary, pvt = ary[Math.trunc(ary.length/2)]) =>
ary.length <= 1
? ary
: [
...quickSort(ary.filter(n => pvt > n)),
...ary.filter(n => pvt == n),
...quickSort(ary.filter(n => pvt < n)),
]
quickSort([32,673,256,78,765,43,28,0,6])
//=> [0, 6, 28, 32, 43, 78, 256, 673, 765] 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
JT78J ■ このスレッドは過去ログ倉庫に格納されています