- 1 名前：デフォルトの名無しさん mailto:sage [2012/08/16(木) 22:17:50.32 ]
- 339 返信：153[sage] 投稿日：2012/08/16(木) 22:16:29.83
>>314
>関数型言語でなければならないという観点は間違ってる気がする
ああ、これについては同感だね
現状のどの関数型言語も文字列、パターン、ハッシュの操作に難があるから、
現行LLであるPerl/Python/Rubyを置き換えるには無理があると思う
ただし、関数型言語にも良い特性がある訳で、実際に(LLを含む)多くの言語に影響を与えている
だから自分は「LLにおける関数型プログラミング」に注目している
- 59 名前：28 mailto:sage [2012/08/18(土) 17:43:35.94 ]
- >>57
>破壊的な操作を内部に一カ所でも含む関数は破壊的になる
これは事実であり、特に純粋関数型言語であるHaskellプログラミングでは絶対的な真理でしょう
ただし、別の切り口による２つの考え方もありえると思います
最初の切り口は「純粋関数型 vs. 不純関数型」です
たとえば関数型言語のML族(F#/OCaml/SML)では、不変(immutable)データを操作する
透過的なプログラミングが基本の作法ですが、「例外」として明示的な参照型宣言や
逐次演算子(SMLの場合は ;(セミコロン))を用いた手続き型プログラミングも可能です
言い換えると、純粋関数型言語パラダイムではあらゆる破壊的操作を拒絶するのに対し、
不純関数型言語パラダイムでは例外を受け入れる寛容な思想です
そして、たとえ不純関数型言語パラダイムであっても、(手続き型言語パラダイムと比較すれば)
コード品質に関する明らかな恩恵を享受できることも事実です
Rubyによる関数型プログラミングもまた「不純関数型パラダイム」になります
もう一つの切り口は「ソフトウェアアーキテクチャレベルでの分離」です
たとえばRailsフレームワークは「MVCアーキテクチャ」をもとに設計されていますが、
ModelはRDB操作が、Controlerはセッション管理があるので破壊的操作は避けられないでしょう
でもViewに関してはRDBから取り出した値からHTMLオブジェクトへの「写像」という
純粋な関数として定義できると確信しています
つまり、(クラス/モジュールよりも粒度の高い)コンポーネント/サブシステムという単位で
破壊的操作コードと非破壊コードを分離することが、現場の開発では可能であると考えています
またMVCアーキテクチャはシステムを水平方向に分割しますが、
垂直方向にシステムを分割する「階層化アーキテクチャ」という発想もあります
つまり、I/O処理を含む下位層のコンポーネントは破壊的操作で設計し、
上位層を非破壊操作で設計することになります
もちろん水平分割と垂直分割を組み合わせることも可能でしょう
こういった(コード設計よりも上流の)アーキテクチャ設計も高品質ソフトウェア開発では重要です
- 60 名前：デフォルトの名無しさん mailto:sage [2012/08/18(土) 18:55:25.75 ]
- >>59
例えば Ruby なら、破壊的操作には関数名に ! をつけましょうという、
ハンガリアンと同レベルの命名規則が提案されもしたが、
しっかりと守る人は少なかった。
一方 OCaml などにおいては、参照透過性を保つことを基本としながら、
その中に（明確にマークすることにより）破壊的操作を混ぜることに成功している。
こちらも、破壊的操作はできるが、できるだけ参照透過性を守ろうというのは、
いわば約束であって、そうしなければコンパイルが通らないという話ではないから、
そういう意味では Ruby の命名規則による約束と強制力という点で何ら変わらない。
どちらも約束であるのに、一方で失敗し、もう一方で成功しているのは、
あくまで参照透過性が基本という、関数型言語が培ってきた文化の力が大きいと思う。
LL というカテゴリ名が示すように簡単に軽く書けることを信条としてきた言語では、
約束程度の縛りでは「可変(mutable)な操作と不変(immutable)な操作の明確化」
にはなかなか至れないと思う。
自分はそのつもりで守っても、使ってるライブラリでそれを壊してたら、
逆にデバッグ時にある意味不要な柔軟な思考が要求され、ハマる可能性もある。
せめて、内部で一カ所でも破壊的操作が行われていたら、
関数名の末尾に ! を付ける事を構文化して、ルールを守らなければ
インタプリタやコンパイラから警告ではなくエラーを出すようにしないと
明確化には遠いと思う。
- 61 名前：uy [2012/08/18(土) 19:53:44.14 ]
- 元々標準で
deleteとか
delete_if に!ついてねーもの
- 62 名前：28 mailto:sage [2012/08/19(日) 00:07:56.60 ]
- >>60
同感ですね、特に次の一文が....
>どちらも約束であるのに、一方で失敗し、もう一方で成功しているのは、
>あくまで参照透過性が基本という、関数型言語が培ってきた文化の力が大きいと思う。
新しいパラダイムの普及や文化の移行には、長い時間が必要です
オブジェクト指向にしても、Smalltalk-80の日本上陸から現在の繁栄の時代まで20数年を要しました
関数型言語からLLの戦場に対応すべく異常進化した新種が誕生するのか(>>28)、
あるいはLL文化が関数型パラダイムへと移行するのか(>>49,54)、未来は予測できませんが
長い目で見守りつつ自身の技(わざ)を磨いていかなければならないと思います
Rubyに関しては、「簡単に軽く書ける」どころか「楽しいプログラミング」を信条としている訳で、
そのRuby固有のユニークな文化は今後も生き続けるでしょうし、自身もそれを望んでいます
Rubyで高品質設計が求められつつあるといっても、その主戦場の重要性に変わりはないのですから....
(>>49,54で言ってる事と矛盾しているような気がしないでもないけど、たぶん気のせいでしょうw)
だから関数型パラダイムへの移行期間では、
・関数型プログラミング技法を用いてRubyで「楽しく」プロトタイプを開発し、それをML族へ移植
・高品質な部品(コンポーネント)をML族で開発し、それらをRubyで糊付
といったアプローチもありかもしれません
また、現実のRubyプロジェクトでは、以下の施策を適用しています
・[>>49] すべてのメソッド定義の出入り口に専用の動的型検査メソッド呼び出しを入れる
・[>>54] 生の組み込みクラスを包む破壊/非破壊操作を分離した独自クラス
- 63 名前：デフォルトの名無しさん mailto:sage [2012/08/19(日) 00:58:41.44 ]
- Pythonの命名規則の定着具合はRubyやPerlみたいなウンコ言語より遥かにマシだからLLと言って一緒くたにすんなよ
- 64 名前：デフォルトの名無しさん mailto:sage [2012/08/19(日) 01:03:40.72 ]
- >>63
例えばどのような命名規則でしょうか。
このスレはあくまでLLにおける関数型プログラミングの話なので、
関数型プログラミングに関わりそうな部分だけで結構ですので、
いくつか例を挙げていただけないでしょうか。
- 65 名前：デフォルトの名無しさん mailto:sage [2012/08/19(日) 01:07:43.30 ]
- LLにおける関数型プログラミングの話という認識が間違ってる
Rubyしか知らないのに他のLLを巻き込むなよ
|
 |
