すべてのRubyをHaskellであるかのように書いても大丈夫でしょうか？

Rubyには、リスト作成、マップ、選択、収集などの優れたリスト操作機能が組み込まれています。Procs、Blocks、Lambdasがあり、優れた反復サポート（eachファミリ）があるので、もしもRubyのものをすべて最も純粋に機能的な方法で記述しますか？I / Oがほとんどまたはまったくない（したがって、明らかな副作用が少ない）コードに特に適していますか？

私はHaskell（「本当の」ハッカーの言語と呼ばれます）を学んでいて、それを行う方法に夢中になっています。 Rubyはそもそも借りたり、そこから多くを学んだりしませんか？）

建設的なガイダンスは大歓迎です...

私はこれをpythonで行っています。そのために設計されていない言語で、伝統的に純粋な関数型のスタイルで書くのは面倒です。たとえば、in_orderの2つの定義を対比します。

def in_order(xs):
    for i in range(1,len(xs)):
        if xs[i] > xs[i+1]:
            return False
    return True

inOrder :: (Ord a) => [a] -> Bool
inOrder xs = and $ zipWith (<=) xs (tail xs)

書き込みin_orderpythonでHaskellの方法は、（のpythonは非常によく、必要なイディオムをサポートしていないので）両方の冗長可能と低速（線形空間の代わりに、怠惰のためにHaskellの一定の空間）になるだろう。

しかし、私は機能的な編成と各関数の慣用的な実装を備えたpythonプログラムの作成に成功しました。これがプログラミングの良い方法であるという考えは、実際には私のcodecatalogプロジェクトの背後にある論文です。したがって、私のコンポーネントは、状態を持つクラスではなく、抽象化とそれらに作用する（純粋なインターフェースを持つ）関数を中心にしており、うまく統合されています。実際、この方法で編成されたコードは、クラスで編成されたコードよりも柔軟に再利用できます。しかし、私はまだハスケルの信者なので、それは個人的な偏見かもしれません。

だから私はあなたの質問への答えはちょっとだと思います。機能的なルーツを使用して考えやすくしますが、無理しないでください。例えば。イディオムのためだけにRubyで遅延リストをシミュレートすることは、おそらくそれよりも厄介なことになるでしょう。

Rubyコードは、HaskellではなくSchemeのように機能的なスタイルで記述できます。それをHaskellであるかのように書くには、Haskellに似た型システムと、広範にわたる遅延評価が必要になります。

Rubyで遭遇した特定の状況で、関数型プログラミング、特にHaskellを理解することが役立つことがわかりました。しかし、Haskellを学べば学ぶほど、RubyがHaskellのようになることができることから、どれほど遠くにあるかがわかります。

モジュール/コードの読み込み状況はひどいです。現在のインタープリターでは末尾呼び出しの最適化がオンになっていないため、Haskellで行うように再帰を使用することはできません。そして、Monadsに入ると、HaskellとRubyで実現できる抽象化のレベルを比較することはできません。

興味があれば、Ruby / Haskellの比較コードをgist.github.comに投稿してきました。

私がRubyにもたらした手法の中で最も優れたものは、できる限り純粋な関数を見つけることでした。つまり、あなたがしようとしているように思えます。

「はい」と言います。あなたが話している（私が思う）のは、ルビ言語における関数型プログラミングの影響です。機能的パラダイムには、オブジェクト指向を補完または重複する（特に副作用がない）いくつかの非常に優れた概念があります。

Rubyの優れた点は、線形、オブジェクト指向、または機能的なスタイル、またはこれらのブレンドでコーディングできることです。そして、複雑さが増すと、シンプルな線形スクリプトがOO / Functionalスタイルに変形する可能性があります。

他の人とコラボレーションするかどうかによります。自分でコードに取り組んでいる場合は、最も使いやすいスタイルを使用してください。ただし、他のRubyプログラマーと作業している場合、それらは純粋に関数型のプログラミングに慣れていない可能性があり、そのため、コードによって混乱する可能性があります。また、共同作業者がRubyに移行したHaskellプログラマでもある場合は、この問題は発生しない可能性があります。