【関数】Erlang【エリ ..
552:デフォルトの名無しさん
08/10/25 10:52:45
>>551
絶対に違うと思う
553:EW
08/10/25 12:18:02
>>550
だから、それっぽくということですwww
プログラミングをしている感覚としては、やっぱりオブジェクト指向よりも
手続き型に似ているような気がしてなりません。
そうですね。基本はreceiveをぐるぐる回す構造です。
メッセージによるイベントドリブン形式とでも言えるかと思います。
ErlangのAPIがCの構造体を利用したものに似ているんですが、
Pidをインスタンスに、メッセージをメソッドに、みたてて似たようなことをやるほうが、
並列処理では使い易いような印象がありますね。
まぁ、弊害として
・資源開放としてのプロセスの終了が必要になる
・死んでいるプロセスに送信したら無視される
というものもあるんですけど。
554:デフォルトの名無しさん
08/10/25 16:41:13
>>552
「絶対に」という根拠は気になるな
555:デフォルトの名無しさん
08/10/26 14:52:39
表紙のconcurrentに惹かれて「プログラミング Erlang」を読み進めているのだが、
今ひとつ並列性への本質的な強みが感じられなくて、期待はずれ感。
20章の初めには「たくさんのプロセスを使う」とか書いてあるし・・・
どうしたら満たされる、並列への期待
556:デフォルトの名無しさん
08/10/26 17:18:49
>>555
第五世代コンピュータ
557:デフォルトの名無しさん
08/10/26 17:23:53
織田信長?
558:デフォルトの名無しさん
08/10/26 18:01:36
> 20章の初めには「たくさんのプロセスを使う」とか書いてあるし・・・
プロセスを誤解してないか?
559:デフォルトの名無しさん
08/10/26 20:21:12
誤解とは?OSレベルのプロセスじゃないよってことかい?
560:デフォルトの名無しさん
08/10/26 21:02:42
>>559
うん。
それわかってて期待はずれならプロセス計算(代数)にも期待はずれなのかと。
561:デフォルトの名無しさん
08/10/27 04:38:07
>>560
ErlangでGHC(KL1)の処理系を書けばいいんじゃないの。
562:デフォルトの名無しさん
08/10/27 05:46:13
>>561
GHC(KL1)は各ゴールがプロセスでErlangよりたくさんプロセスを使うから
>555にはやっぱり期待はずれだろうね
563:デフォルトの名無しさん
08/10/27 06:14:43
>>562
GHCが問題なのではなくて、Erlangのプロセス管理を
生かす事例という意味だが。
564:デフォルトの名無しさん
08/10/27 08:16:18
programming erlangは並列経産の本じゃなくてerlangのチュートリアルだから
仕方ない。erlangを使って、openmpとかMPIとかMapReduceとかやればいいじゃない
565:デフォルトの名無しさん
08/10/27 16:13:54
>555は並列に何を期待しているのか?
566:デフォルトの名無しさん
08/10/27 16:52:15
>>565
次元の壁を越えた美少女達とのお付き合い
567:デフォルトの名無しさん
08/11/05 02:45:28
これの実用的なライブラリってある?rubyでいうrailsくらいの
568:デフォルトの名無しさん
08/11/05 21:31:34
誰か!誰かエスパー呼んできて!
569:デフォルトの名無しさん
08/11/06 20:05:56
ないだろ。別にエスパーよばんでも
570:デフォルトの名無しさん
08/11/07 08:17:56
あればもっと流行ると思うんだけどね
てか言語の流行る流行らないは実用的ライブラリが揃ってるかどうかが大きい
571:デフォルトの名無しさん
08/11/07 20:46:24
関数型で流行ってるのなんてないだろう。
572:デフォルトの名無しさん
08/11/08 00:05:48
こういう時やたらHaskellを推してくる人がいるけど、そいつが実際どれだけHaskellでコード書いてるのか知りたい。
573:デフォルトの名無しさん
08/11/08 00:15:30
>>572
>こういう時やたらHaskellを推してくる人がいる
どの人の事?
574:デフォルトの名無しさん
08/11/08 00:18:25
ただの妄想だろう
575:デフォルトの名無しさん
08/11/08 01:02:36
「やたら〜する人がいる」 「みんな言ってる」 は大抵1人とか二人とかだよな
576:デフォルトの名無しさん
08/11/08 01:19:55
だから数字にすることに意味があるんだね。
577:デフォルトの名無しさん
08/11/08 01:21:21
以前初心者オススメスレにHaskellを推しまくってるヤツがいたよなwww
あまりに変だったからさらに不自然なHaskell狂信者風なのが出てきてネタにしてたwww
578:a36 ◆K0BqlCB3.k
08/11/08 01:29:47
>>572
まぁ、人にはいえないあんなことやこんなことに使ってます。
Haskellでスタンドアロンアプリを書くことは滅多にないのですが、
とあるHaskell用のライブラリを作って公開しています。(本家にリンクがある)
論文を書くときにHaskellを題材に使ったりすることもあります。
579:デフォルトの名無しさん
08/11/08 08:28:49
企業でHaskell,Erlang,Lisp,Prologなどを使う場合は
使ってることも何に使っているかも秘密にしておくよ。
580:デフォルトの名無しさん
08/11/08 08:40:59
>>575
どういう風に統計とったの? 妄想?
581:デフォルトの名無しさん
08/11/08 09:03:24
>>572
>こういう時
どういう時?
582:デフォルトの名無しさん
08/11/08 22:02:30
>>580
そうみんな言ってた
583:デフォルトの名無しさん
08/11/08 22:10:23
ワロタww
584:デフォルトの名無しさん
08/11/09 04:28:11
この言語はよっぽどネタがないんだな
ということが分かるやり取り
585:デフォルトの名無しさん
08/11/09 05:38:37
>>559
どういうこと
586:デフォルトの名無しさん
08/11/09 14:23:44
仕様が成熟している、利用者がいない、のどちらかまたは両方
587:デフォルトの名無しさん
08/11/09 14:29:34
>>586
erlangが普及しない理由
1. 遅い
2. 関数型言語
3. ネイティブが吐けない
4. 実行方法が異質
5. (ほぼ)サーバー特化
588:デフォルトの名無しさん
08/11/09 17:43:37
遅い、ネイティブが吐けないとかはpythonとかでも同じじゃんか
なのにpythonは普及している。
関数型言語ってのが普及しない一番の理由じゃないかな、実用的に見て
589:デフォルトの名無しさん
08/11/09 18:50:38
>>588
pythonはライトウェイト言語であって、erlangとは領域がまったく違う。
プロセスは軽いが処理自体は低速。
サーバを停止しなくても修正ができるというのはメリットだが、
そういう機能が必要なければバイナリが吐けたほうが都合が良い。
それにC++でも軽いソフトウェアスレッドのライブラリは存在するから
もはやプロセスが軽いというのはさほどメリットでもない。
関数型言語としてはHaskellやOCamlのほうがすぐれている。
590:デフォルトの名無しさん
08/11/09 18:52:44
あくまでこれは俺がこの言語を選択しない理由として挙げているだけ。
erlangはどんな言語か知っているけど、あえてこの言語を選ぼうとは思わないんだよ。
サーバーを書くときは簡潔に書けるから便利ではあるけど。
591:デフォルトの名無しさん
08/11/09 18:55:00
スタンドアロンなツール類を書くならやっぱりC++だろうな。
WEBアプリを書くならRubyかPHPかPerlだし、俺自身はPythonという選択肢はない。
サーバーならerlangかhaskellが書きやすい。
それぞれ使いわけでいいじゃん。
サーバー書く人が少ないっていうのが一番大きい理由じゃないの?
592:デフォルトの名無しさん
08/11/10 20:30:25
すごいな。ErlangもC++と対等に語られるようになったか。
593:デフォルトの名無しさん
08/11/10 21:13:43
オブジェクティックでフォンクティックな言語があればいいのに
594:デフォルトの名無しさん
08/11/10 21:53:38
>>593
"object oriented" functional language でぐぐったら、なんかいっぱい出てくるぞ。
でも実用にできるのはOCaml, Scalaくらい?
595:デフォルトの名無しさん
08/11/10 22:18:51
CLOS(Lisp)、あとOzとか
オブジェクト指向ベースに関数型の機能を取り込むアプローチだと、
まあ高階関数ぐらいなら比較的新しい言語はどれも持ってる
596:デフォルトの名無しさん
08/11/10 23:16:53
高階関数それ自体がマルチコアを生かすようなバイナリに繋がると良いが、原理的にそんなことないわな。
しかし今だ考え方はプロセス・スレッド止まりだし。
もっとまったく新しい考え方って何かないのかね
597:デフォルトの名無しさん
08/11/11 00:48:27
Objective Erlang的なの作ればいいんでね?
598:デフォルトの名無しさん
08/11/11 00:54:49
Erlang使ってない俺が言うのも何だが、流れはEW氏に来たということか。
599:デフォルトの名無しさん
08/11/14 02:39:00
開発を手続き型言語以外でやってる会社とかないよな
関数型はオナニー
600:デフォルトの名無しさん
08/11/14 03:21:58
Diceあたりで検索かければ出てくるよ。少ないけど。
601:デフォルトの名無しさん
08/11/14 13:59:37
>>599
Schemeで書かれたピンボールとか出てこようかという
ご時世に、ずいぶん乗り遅れてますねあなた
602:デフォルトの名無しさん
08/11/14 23:24:30
>>599
今の教育課程でパンピーの知能じゃ無理でしょ。まだだいぶ先の話じゃないか、
関数型つか並列資源を存分に使いこなすプログラミングなんて。
603:デフォルトの名無しさん
08/11/15 08:46:24
>>601
やっとピンボールですか。
手続き型なら30年前にできてたので、ずいぶん乗り遅れてますね。
604:EW
08/11/15 10:41:08
>>597
Erlangが目指すところはオブジェクト指向と相反するような気がしますね。
カプセル化などは便利だと思いますが、インスタンスを使いまわすというのは
かなりイケてないことだと思います。
それがおkなら、変数への再代入なども許可しているでしょうし。
おそらく、可能な限り「状態依存を無くす」というのが、
Erlangの基本コンセプトなのではないかと思います。
>>598
僕が使っているのはあんまり上等な代物じゃないですよ。
個人レベルで手抜きをしているだけであって、本来なら綿密なデバッグが必要となる
危険なプログラムだと思います。
余談ですが、来年から planet lab のメンバーに加わることになりました。
605:デフォルトの名無しさん
08/11/15 11:29:08
>>603
その理屈では機械語以外は全て遅れている言語ですよ。
脳味噌大丈夫ですか?
606:a36 ◆K0BqlCB3.k
08/11/15 11:44:09
>>602
今の大学生は提出課題ですら他人のコピーだから、
FizzBuzz問題すら解けない子が多いよ。
607:デフォルトの名無しさん
08/11/15 12:36:47
>>605
きみこそ脳みそ大丈夫?
高級言語が機械語より遅れてるの当たり前じゃないか。
608:デフォルトの名無しさん
08/11/15 12:43:43
>>606
昔の大学生も、FizzBuzz問題すら解けない子おおかったと思うが。
609:デフォルトの名無しさん
08/11/15 14:32:15
>>607
しょうがないよ、君の理屈だとそうなるんだから(605の理屈ではない)。
610:EW
08/11/16 23:20:23
2つ以上のイベントドリブン形式のプロセスが相互に通信しあうというモデルでは
複雑なトランザクションを記述するよりも、
プロセスがメッセージを受け取ったら、
「新しいプロセスを作り処理させて、その結果を返す」
という手法のほうがプログラムを組みやすいみたいですね。
AがBに処理を依頼
BがAに対してある処理をさせる。
Bはその結果を受け取る。
そして処理を続行し、完了するとAに値を返す
という処理を書いたのですが、逐次プロセスのみだと処理が複雑になって
アウトでした。自分の意図しないところでデッドロックやバグがおきまくりました。
AとBの処理を新しいプロセスを立ててやらせると、かなり簡単に動きました。
なかなか便利な手法です。
611:デフォルトの名無しさん
08/11/17 01:00:47
AがBに依頼した処理をBがAに処理をさせる?
612:デフォルトの名無しさん
08/11/17 01:12:02
AとBでコルーチン的に処理をさせたいってことじゃね?
613:デフォルトの名無しさん
08/11/17 03:04:20
名古屋コーチンがどうしたって?
614:デフォルトの名無しさん
08/11/17 20:29:56
名古屋撃ちなら知ってる
615:EW
08/11/17 21:54:07
612の方が指摘している通り、コルーチン的に処理するってことです。
純粋な逐次プロセスでコルーチンを実装すると、その処理をやっている間は
第三者からのアクセスに反応できないため問題がありました。
並列で新しいプロセスを作ると、コルーチンを分解できるんで
シンプルになりましたということです。
616:デフォルトの名無しさん
08/11/19 22:28:39
>>615
権利義務の関係で処理すればいいんですね。
それぞれのプロセスはメッセージを受け取り自分を使わせる代わりに、
質問者を制御するメッセージを応答に付加できる。
そして、質問者はこのメッセージをevalことを義務付けられている。
これだけで>>610は実現できます。
617:616
08/11/20 06:48:07
これではダメでしたね。
質問者は最初の質問に対してサーバから一度応答を
受けてそこで完了してしまいます。実際にはさらに続いていて、
質問者側の情報をサーバが得て本回答を送ってくるのですが、
それを受け取るのは、最初の質問者が設定した質問ではないですね。
サーバ側によって仕組まれた、バックグラウンドでの質問です。
これを質問者が最初の質問の回答と見なすのは困難ですか・・・。
618:616
08/11/20 07:26:58
できるだけプロトコル化しないのがスマートと思ったのですが、
破綻しました。keep-alive状態を保って再質問するのが質問者
となるように仕組むことはできますが、
再質問は(最初の質問+質問者側でエバッた値)を引数に与えなくてはならず
複雑ですね。
619:616
08/11/20 07:55:21
それにBは最初のAの質問に回答しないで、Aから情報収集してから
回答を用意するのが>>610の仕様ですね。全然ダメですね。
お騒がせしました。>>616->>619までは無視してください。
620:デフォルトの名無しさん
08/11/20 23:41:22
>>616-619
621:EW
08/11/21 10:13:54
やっていることとしては
loop(State) ->
receive
1 -> spawnA, NewStete = State
2 -> spawnB, NewState = State
2' -> setState, NewState = 更新
end
loop(NewState).
みたいなのをイメージして頂ければいいと思います。
somefunc() ->
sendA
receive
sendB
receive
return Value
とやると、その間は処理がストップする(loopがreceiveできない)
ので、新しいプロセスを独立させてそこでコルーチンlikeな処理をして
その結果をloopに対してメッセージとして送っています。
上記の方法は柔軟性が増しますが、代わりに厳密性を失っています。
そのコルーチン処理がプロセスの状態に関るものであるならば危険なプログラムなので
使用しないほうがいいと思います。
622:デフォルトの名無しさん
08/11/24 14:42:15
vistaで erl -name hoge とするとAPPCRASH(StackHash_e52f)で起動できないのですが、
何が悪いのでしょう?
R12B-5(Erlang (BEAM) emulator version 5.6.5)です。
Microsoft Office IME 2007だとStackHash_e52fが起きるらしいのでMicrosoft IMEに
してみましたが、効果無しでした。
623:EW
08/12/10 11:56:36
>>622
ごめんなさい。分からないです。
624:デフォルトの名無しさん
08/12/12 00:20:13
おれはXPで動けばいいと思ってる
625:デフォルトの名無しさん
08/12/12 23:28:46
》624
なんで?
626:デフォルトの名無しさん
08/12/13 16:34:11
vistaはmeと同じ運命だからじゃないかい?
627:デフォルトの名無しさん
08/12/13 19:08:43
そのmeを3年使った俺への当てつけか?
それにどうせ7はvistaの発展なんだから、vistaがmeと同じ立場というわけにはならないよ。
628:デフォルトの名無しさん
08/12/13 19:14:02
そうだよな。7のカーネルはVistaと同じ、バージョン6.xなんだよな。
どの辺りが7なのか未だにわからない。
629:デフォルトの名無しさん
08/12/14 05:56:13
MSも必死だからな
630:デフォルトの名無しさん
08/12/14 12:19:25
名前なんて飾りです
631:622
08/12/14 22:53:41
>>623
どうもありがとうございます。
-snameは動くので、ローカルなネットワーク限定で遊ぶことにします。
vistaで使っている人はいないのか…
632:デフォルトの名無しさん
08/12/15 20:05:56
で、そろそろアーランを使用した基幹システム開発導入事例とか
出てきてもいいと思うんだ
通信以外の用途で
633:デフォルトの名無しさん
08/12/22 13:20:47
io:fwriteでファイルに書き出すときは文字列のエスケープをしないのに
コンソールに出力するとUTF8の多バイト文字が皆エスケープされてしまうのだけど
これを抑止することできますか?
ファイルからテキスト処理してコンソール上で確認してるとことごとく\227,\130,\143…みたいになっちゃって
涙が
634:EW
08/12/22 21:59:14
>>663
Erlang本には多バイト文字の扱い方が書いていないことは確かです。
正直、ファイル処理ですら相当危ういと思います。
ファイルにそのまま出力できたのは、UTF8の文字を認識しているのではなく
「バイト列をそのまま書き込んだから同じになったに過ぎない」という程度だと思います。
おそらく、ちょっと手を加えるだけで、ファイル出力も一瞬で文字化けするような気がします。
とりあえず、コンソール(コマンドプロンプト)が、EUCやShift-Jisになっていないかを
確認して、それでも駄目ならかなり厳しいんじゃないかと思います。
(だって、開発国の言語であるスェーデン語ですら文字化けするぐらいですし・・・・)
635:デフォルトの名無しさん
08/12/23 21:03:44
>>634
不当なシーケンス食わせてもそのまま保持してくれるので(pread)コンソールでの
エスケープだけやめてくれれば十分な場合がほとんどだと想うのですが
パッチ自分で入れないとなんないとすると面倒だなぁ(ファイルにログ吐くとUTF8通るのに、コンソールだとアレみたいな)
636:デフォルトの名無しさん
08/12/26 17:37:08
ErlangのWindowsバイナリーってWin95、Win98にインストール可能?
637:デフォルトの名無しさん
08/12/27 03:34:03
>>636
FAQにはサポートされていると書いてあるけど
執筆日時が記述されていないから
自分で試すしかないと思うよ。
8.4 What operating systems does Erlang run on?
URLリンク(www.erlang.org)
638:デフォルトの名無しさん
08/12/27 09:21:35
>>637
何とか古いPC引っ張り出してやってみたけど
ダメだった。VCのランタイムとかいろいろ
いるみたい。
639:デフォルトの名無しさん
09/01/13 18:06:16
↑↑馬鹿だろ
640:デフォルトの名無しさん
09/01/25 09:12:34
最近、Erlangに興味を持ってネット上の入門レベルサンプルを動かしているんですが、
エミュレータ(erlコマンド)を使っている時に、BIFのパラメータ説明を調べる手間を
少なくする方法を模索中です。
現在使っている方法は、
・Googleで検索(Erlang keysearch など)して、使用例を見つけたら文法を推定する。
・Concurrent Programming in ERLANG のPDFファイル内で検索
ですが、皆さんはどうやって調べてるんでしょうか?
宜しければ、御教示願えると助かります。
641:デフォルトの名無しさん
09/01/25 21:41:46
>>640
Linuxでやっているので,man pagesをインストールしておいて,
たとえば ets:new とかなら,man ets してから less上で
new を検索してる
man pages はDownloadページにリンクがあるけど,
普通の本体とは別なので,別途DLしてインストールが必要.
最新だとこれ>URLリンク(www.erlang.org)
642:デフォルトの名無しさん
09/01/25 23:09:49
emacsのerlang-modeマジオススメ。
"M-x erlang-man-module"→"module:function"で直接manを検索できる。
643:デフォルトの名無しさん
09/01/27 20:50:35
>>641,642
レスが遅くなりましたが、有り難うございます。
という訳でLinuxをインストール後さっそく導入してみました。
man pages、Emacsのerlnag-modeの他に、Distel ↓というのを見つけたので
少し使いこんでみたいと思います。
URLリンク(code.google.com)
最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4777日前に更新/151 KB
担当:undef