おはピヨ♪マルチパラダイムなインドリです！
今日も朝起きてから、ぼーと並列処理について思いを巡らせていました。
そこで考えたのが、並列処理は今までの常識を変えるという事です。
例えば、メソッドの引数を多くするよりも、プロパティ等を使用して引数を少なくし、メソッド呼び出しのパフォーマンスを向上させる事が提唱されていました。
※スタックされるデータ量が減るからパフォーマンスが向上するという事。
でもそれは逐次処理だから通用する事です。
並列処理になると、そんな事をしたら同期処理が増えますし、並列度が低下しますので、パフォーマンスが逆に低下します。
そういった事が多々あります。それを難しいと感じる人も多いでしょう。
しかしながら、グローバル変数を極力使用しないとか、従来からも言われている共通点もあります。
だから、あんまり気にしなくても思います。
OSやデータベースについて考えていると、それらの事はおのずと分かる事ですし、我々の政界は並列的なので、実のところその方が自然な考え方です。
リラックスしたら自然と分かります。
素直になればいいのです。情報処理技術は変化が早いので、素直さが一番大事なのかもしれません。
とにかく、ラブ＆パッションです！
呼吸をするように自然と情報処理技術について考えていれば、自然とレベルアップします。
例えば、歩道でセマフォについて思いをはせましょう。職場でのトラブルからデッドロックを感じましょう。
そうした姿勢が苦痛なく技術力をアップさせます。
常に情報処理技術について考えていれば、素質なんて関係ありません。
情報処理技術は特別な才能を必要としません。
気楽に情報処理技術を楽しもう♪
スポンサーサイト
テーマ : 裏事情
ジャンル : 謎
一連の記事をみていくと、インドリ先生の御主張は次ぎのように理解しました。
・副作用がある言語は、逐次処理では良いが並列処理では適していない
・これからは、並列処理の時代だから、従来の逐次処理(言語)は衰退していく。
誤読していたら、指摘を下さい。
副作用のない薬は、薬効がありません。
代表的な副作用は、C言語のマクロですよね。プリプロセッサが字面の置換を行うため、初心者は副作用に悩むことになります。
でも、マクロは廃止されるどころか、有効に使い続けられています。
副作用を遙かに超えるメリットがあれば、副作用の存在は、微々たる物だと思いませんか?
業務アプリが、関数型言語に置換される姿を、どうしても想像できないのですか、如何ですか?
先生は止めてください。
> 一連の記事をみていくと、インドリ先生の御主張は次ぎのように理解しました。
> ・副作用がある言語は、逐次処理では良いが並列処理では適していない
> ・これからは、並列処理の時代だから、従来の逐次処理(言語)は衰退していく。
> 誤読していたら、指摘を下さい。
衰退というよりも、関数型言語の要素を取り入れ、マルチパラダイム化が加速していくと思います。
これは誤読というほどでもありません。
> 副作用のない薬は、薬効がありません。
> 代表的な副作用は、C言語のマクロですよね。プリプロセッサが字面の置換を行うため、初心者は副作用に悩むことになります。
> でも、マクロは廃止されるどころか、有効に使い続けられています。
> 副作用を遙かに超えるメリットがあれば、副作用の存在は、微々たる物だと思いませんか?
>
副作用がどうしても生じる場所はあると思います。
例えば、I/O処理も絶対に必要です。
ただ、モナドやトランザクショナルメモリなどといったもので何とか出来ることでもあります。
今この辺を詳しく調べているところです。
> 業務アプリが、関数型言語に置換される姿を、どうしても想像できないのですか、如何ですか?
それは大丈夫です。
関数型言語で作られたシステムがあると聞いております。
Lispハッカーで名高いポール・グレアム氏は、それで商売すらしております。
さらにえば、論理型言語であるErlangも有効に使われています。
今まで関数型言語になじみがないだけであって、業務システムに使えると私は思います。
F#も関数型言語ですが、普通に業務システムで使えそうですよね。
話しが記事の内容とはずれますが、私はメタプログラミングが大好きです。
※マクロは副作用というよりも、メタプログラミングの領域だと思います。
でもマクロは、テキスト処理だから、ビャーネ氏と同じく、コンパイラから極力排除するべきものだと思います。
マクロをそのまま残すよりも、独立したコンパイル段階を設けて、専門的に行うべきです。
メタプログラミングはもっと積極的に行われるべきだと思いますが、それと副作用の話しは別物だと思います。
ちなみに、私は副作用が生じる事にも利点があるとは思っています。
例えば、言語設計的にいえば、オブジェクト指向プログラミングは、変更可能にする事により実現できるプログラミング技法です。
全ての要素が変更不可にできれば話しは早いのだけど、そうは問屋が卸さないよね。
ただ、副作用は並列処理の敵ですので、意識して排除するべきものです。
副作用を避けると、テストもやりやすくなるからいいよ。
大変面白く拝見させていただきました。
副作用について…ですが、
並列処理において、参照透過性を如何に守るか？
と言うお話かな？と思って読んでおりました。
私自身知識の浅い部分のお話なので、理解が足りない発言があるかもしれませんが、
関数型言語を利用しても、
結局のところトランザクション管理がとても大変そうだな…
と感じてしまうのですが、どうなのでしょう。
マルチプロセッサ下では処理速度等の面で良い(らしい)ですが、
今までの同期処理の方が、
感覚的に安全な気がしてしまいます。
> 大変面白く拝見させていただきました。
>
ありがとう。
> 副作用について…ですが、
> 並列処理において、参照透過性を如何に守るか？
> と言うお話かな？と思って読んでおりました。
>
> 私自身知識の浅い部分のお話なので、理解が足りない発言があるかもしれませんが、
> 関数型言語を利用しても、
> 結局のところトランザクション管理がとても大変そうだな…
> と感じてしまうのですが、どうなのでしょう。
>
副作用があるともっと難しくなりますよ。
> マルチプロセッサ下では処理速度等の面で良い(らしい)ですが、
> 今までの同期処理の方が、
> 感覚的に安全な気がしてしまいます。
今までの同期処理って、モニタとかセマフォとかの事かな？
それは、言語とは独立した概念です。
ただ、関数型言語には工夫が見られるだけであって、これからはより抽象化された同機モデルが提供されると思います。
関数型言語であっても命令型言語であっても、抽象化されていく傾向にあるから、どちらにせよ、従来の同期処理は内部で使われる事になっていきそうです。
副作用を避けている…と言われていますが、
実際は状態というものを排除することで避けているように見えるだけという理解でおります。
同期処理、と申しておりますのは、
排他制御の事です。
高い並列度と、参照透過性の維持は、
やはりどこかで相反するものだと思います。
また、「副作用は避けるべき」とのお考えには同意しますが、
副作用はあって然るべきだと思います。
そして、「副作用」と名前はあまりよくないですが、
悪いもの、ではないですね。避けるべき場合と、そうでない場合があると思います。
#勿論、そんな事はご理解なさっていると思いますが…
現社会を見ても、常に全てが並列で処理されているわけではないですよね。
待ち行列のように。
何にせよ、仕事ではJavaにしかありつけない私には、
あまり想像ができない部分なのかもしれませんが…
> 現社会を見ても、常に全てが並列で処理されているわけではないですよね。
> 待ち行列のように。
>
> 何にせよ、仕事ではJavaにしかありつけない私には、
> あまり想像ができない部分なのかもしれませんが…
マルチコア時代だから、並行処理／並列処理は当たり前になります。
今のうちに学習しておく事をお勧めします。
そうですね。
読んでおくべきは
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060915/248215/
この辺り、と言ったところでしょうか？
#古い記事ですが良かった記憶が…嘘かもしれません＾＾；
ご心配頂いて有難うございます。
この件については、多分お勉強は必要ないかな、と思っております＾＾
又お邪魔しますね。
