タグ付けされた質問 「functional-programming」

グリッド内のアリの活動をシミュレートするプログラムを作成しています（PDF）。アリは動き回り、物を拾い、物を落とします。 問題は、アリのアクションと各アリの位置をクラス属性で簡単に追跡できる（そして、そのようなアリの多くのインスタンスを簡単に作成できる）一方で、クライアントは関数型プログラミングのバックグラウンドがあるため、関数型プログラミングを使用して行われるシミュレーション。 明確にするために、クライアントからの元の単語は「クラスなし」のみであり、「関数型プログラミング」ではありません。だから私は彼が関数型プログラミングを意味するのではなく、私が命令的にそれを行うことができると思います。さらに、関数型プログラミングの経験はありません。 ただし、単に「命令的に実行する」よりも、特に関数型プログラミングの要件に関するこの質問に焦点を当てることが有益だと思います。 この状況にどのように対処しますか？クライアントに、オブジェクト指向プログラミングを使用する方がはるかにクリーンであると説得して、彼が要求したものに従い、質の悪いコードを与えようとしますか、それとも何か他のことをしますか？

31 object-oriented  functional-programming  client-relations 

私はほとんどC / C ++プログラマーです。つまり、私の経験の大部分は手続き型およびオブジェクト指向のパラダイムに関するものです。ただし、多くのC ++プログラマーが認識しているように、C ++は長年にわたって機能的なスタイルに重点を移しており、最終的にC ++ 0xにラムダとクロージャーが追加されました。 とにかく、C ++を使用した関数型スタイルでのコーディングの経験はかなりありますが、LispやHaskellなどの実際の関数型言語の経験はほとんどありません。 私は最近、これらの言語の研究を始めました。なぜなら、特に並行性と分散コンピューティングへの応用に関して、純粋に機能的な言語の「副作用なし」という考えが常に興味をそそっていました。 ただし、C ++のバックグラウンドから来ると、この「副作用なし」の哲学が非同期プログラミングでどのように機能するかについて混乱しています。非同期プログラミングとは、ユーザーが提供するイベントハンドラーをディスパッチして、非同期に発生するイベントを処理するフレームワーク/ API /コーディングスタイルを意味します（プログラムのフロー外）。これには、Boost.ASIOなどの非同期ライブラリ、または単なる古いCさえ含まれます。シグナルハンドラまたはJava GUIイベントハンドラ。 これらすべてに共通することの1つは、非同期イベントハンドラーが呼び出されたことをプログラムのメインフローが認識するために、非同期プログラミングの性質が副作用（状態）の作成を必要とするように見えることです。通常、Boost.ASIOのようなフレームワークでは、イベントハンドラーはオブジェクトの状態を変更するため、イベントの効果はイベントハンドラー関数の有効期間を超えて伝播されます。本当に、イベントハンドラは他に何ができますか？コールポイントがないため、コールポイントに値を「返す」ことはできません。イベントハンドラはプログラムのメインフローの一部ではないため、実際のプログラムに影響を与える唯一の方法は、状態を変更することです（またはlongjmp、別の実行ポイントに変更することです）。 そのため、非同期プログラミングは、副作用を非同期的に生成することがすべてのようです。これは、関数型プログラミングの目標と完全に矛盾しているようです。これら2つのパラダイムは、関数型言語でどのように（実際に）調整されますか？

31 async  functional-programming  side-effect 

OOプログラミングの長年にわたって、差別化されたユニオンとは何かを理解していましたが、実際に見逃したことはありませんでした。私は最近、C＃で関数型プログラミングをいくつか行ってきましたが、今はそれがあればいいのにと思っています。これは私を困惑させます。なぜなら、一見すると、差別化された結合の概念は、機能的/オブジェクト指向の二分法とはまったく独立しているように見えるからです。 差別化された共用体をオブジェクト指向よりも便利にする関数型プログラミングに固有の何かがありますか、それとも「より良い」方法で問題を分析することを強制することで、単に標準を引き上げて、より良いものを要求していますか？モデル？

30 functional-programming 

Spring + HibernateプロジェクトでJavaからScalaに切り替えて、パターンマッチング、OptionなどのScalaの機能を活用し、一般的にはより簡潔な構文に見えるかどうか疑問に思っています。私はScalaエコシステムでデフォルトでORMを探していましたが、Activateのような考え方を見つけました（しかし、ほとんどはHibernateをScalaで使用できるかどうかを見つけようとしています）。これを検索して、JPA + Scalaに関するPlayのドキュメントでこれを読みました。 しかし、最も重要なポイントは、関数型言語の力を持っているときに、オブジェクトとリレーショナルのマッパーが本当に必要なのかということです。 おそらくない。JPAは、データ変換におけるJavaのパワー不足を抽象化する便利な方法ですが、ScalaからJavaを使用し始めると、本当に間違っていると感じます。 私は関数型プログラミングを使用して完全なアプリケーションを作成する方法を深く理解していません（だからこそ、オブジェクト指向と関数型を組み合わせているため、これを段階的に理解できるようにScalaを使用するつもりです）。関数型言語のORMが必要ない理由と、ドメインモデルの永続性に取り組むための関数型アプローチはどうなるのか。 Scalaでは、ビジネスロジックに対するDDDアプローチが依然として理にかなっていますよね？

30 scala  functional-programming 

上記の質問は、レガシーコードで発生する一般的な問題、またはより正確には、この問題を解決するための以前の試みに起因する問題の抽象的な例です。 Enumerable.OfType<T>メソッドのように、この問題に対処することを目的とした少なくとも1つの.NETフレームワークメソッドを考えることができます。しかし、最終的に実行時にオブジェクトの型を調べることになってしまうという事実は、私には正しくありません。 それぞれの馬に「ユニコーンですか？」次のアプローチも思い浮かびます。 ユニコーン以外の角の長さを取得しようとすると例外がスローされます（各馬に適切でない機能が公開されます） 非ユニコーンの角の長さのデフォルト値または魔法の値を返します（すべてユニコーンではない可能性のある馬のグループでホーンの統計情報をクランチするコード全体にデフォルトチェックが必要です） 継承を廃止して、馬がユニコーンであるかどうかを示す別のオブジェクトを馬に作成します（潜在的に同じ問題をレイヤーに押し込んでいます）。 これは「無回答」で最もよく答えられると感じています。しかし、この問題にどのようにアプローチし、それが依存する場合、あなたの決定の背景は何ですか？ また、この問題が関数型コードにまだ存在するかどうか（または、可変性をサポートする関数型言語にのみ存在するかどうかに関する洞察にも興味がありますか？） これは、次の質問の重複の可能性としてフラグが立てられました： ダウンキャストを回避する方法 その質問への答えは、HornMeasurerすべてのホーン測定を行わなければならないaを所有していることを前提としています。しかし、それは、誰もが馬の角を自由に測定できるという平等主義の原則の下で形成されたコードベースに対する非常に強い課しです。 aがないHornMeasurer場合、受け入れられる回答のアプローチは、上記の例外ベースのアプローチを反映しています。 また、馬とユニコーンが両方とも馬であるかどうか、またはユニコーンが馬の魔法の亜種であるかどうかについてのコメントにもいくらか混乱がありました。両方の可能性を考慮する必要があります-おそらく一方が他方よりも望ましいですか？

30 design  object-oriented  functional-programming 

思わ遅延評価式のが彼らのコードが実行される順序を失うコントロールにプログラマを引き起こす可能性があります。これがプログラマーに受け入れられる、または望まれる理由を理解するのに苦労しています。 式がいつどこで評価されるかが保証されていない場合、このパラダイムを使用して、意図したとおりに動作する予測可能なソフトウェアを構築するにはどうすればよいですか？

30 functional-programming  haskell 

Steve McConnellは、第2版の839ページで、プログラマーが大きなプログラムで「複雑さを克服する」ためのすべての方法について議論しています。彼のヒントは次のステートメントで終わります。 「オブジェクト指向プログラミングは、アルゴリズムとデータに同時に適用される抽象化のレベルを提供します。これは、機能分解だけでは提供されない一種の抽象化です。」 「複雑さを軽減することは、間違いなく効果的なプログラマーになるための最も重要な鍵」（同じページ）という彼の結論と相まって、これは関数型プログラミングへのほとんどの挑戦のようです。 FPとOOの間の議論は、並行性または並列化の課題に特に由来する複雑性の問題に関するFPの支持者によってしばしばフレーム化されます。ただし、ソフトウェアプログラマが克服する必要があるのは、同時性だけではありません。おそらく、ある種の複雑さを減らすことに焦点を合わせると、他の次元では大幅に増加するため、多くの場合、ゲインはコストに見合うものではありません。 FPとOOの比較の条件を、並行性や再利用性などの特定の問題からグローバルな複雑さの管理にシフトした場合、その議論はどのように見えるでしょうか？ 編集 私が強調したかったのは、オブジェクト指向はデータとアルゴリズムの両方の複雑さをカプセル化して抽象化しているように見えますが、関数型プログラミングはデータ構造の実装の詳細をプログラム全体に「公開」することを奨励しているようです。 たとえば、ここで「データ型の過剰な指定」は「慣用的なOOスタイルの否定的な結果」であり、AddressBookをより豊富なOOオブジェクトではなく単純なベクトルまたはマップとして概念化することを推奨するStuart Halloway（Clojure FP支持者）を参照してください追加の（非ベクター的かつ非マップ的）プロパティとメソッドがあります。（また、オブジェクト指向およびドメイン駆動設計の支持者は、AddressBookをベクトルまたはマップとして公開すると、カプセル化されたデータがドメインの観点からは無関係または危険なメソッドに過度に露出されると言うかもしれません）。

30 object-oriented  functional-programming  object-oriented-design 

関数型言語を使用して実験プロジェクトを開始することを検討しており、ErlangとHaskellの間で決定しようとしています。 Haskellの強力な型システムと純度が好きです。本当に信頼できるコードを簡単に書くことができると感じています。そして、Haskellの力は、私がやりたいことのいくつかをはるかに簡単にするだろうと思います。 マイナス面では、YesodのようなHaskellでWebを処理するためのフレームワークのいくつかは、Erlangのカウンターパートほど高度ではないと感じています。 スレッドとフォールトトレランスに対するErlangのアプローチが好きです。Erlangのスケーラビリティは大きなプラスになり得ると感じています。 それが私の質問につながります。HaskellとErlangの両方でWebアプリケーションのバックエンドを実装する際に人々が経験したことは何ですか。HaskellがErlangにある軽量スレッドとアクターのいくつかを提供するパッケージはありますか？

30 functional-programming  haskell  erlang 

UNIXプログラミング環境（古典的なテキスト）は、プログラミングに対するUNIXのアプローチは、より複雑な問題を解決するために組み合わせることができる、小さく明確に定義されたツールを構築することであると述べています。CとBashシェルを学習する中で、これは広範なプログラミングの問題に対処するために使用できる強力な概念であることがわかりました。 Linuxプラットフォームを使用するだけで、コンセプトは非常に明確であり、常に使用されています。I / Oをリダイレクトし、ls、grepなどのシステムツールをリンクするコマンドラインで形成される式は、この概念がいかに強力かを示しています。 私を混乱させているのは、これらのプログラムの多くが命令型/手続き型プログラミングスタイルを使用してCで書かれていることですが、コマンドラインでの使用方法と結合方法は、各プログラムが機能的なプログラミングに似ているようです結合される可能性のある他のプログラムの状態に依存しない孤立した関数。 これは正確であり、UNIXプログラミングの哲学を理解することは、基本的に命令型プログラミングスタイルを使用して構築されたツールを使用した機能プログラミングです。

30 unix  functional-programming  paradigms  philosophy 

Haskellの学習中に、モナドとは何か、Haskellでモナドが重要である理由を説明しようとする多くのチュートリアルに直面しました。それぞれが類推を使用していたので、意味をつかみやすくなります。結局のところ、私はモナドが何であるかの3つの異なるビューになりました： 表示1：ラベルとしてのMonad 時々、モナドは特定のタイプのラベルとして考えます。たとえば、次のタイプの関数： myfunction :: IO Int myfunctionは、実行されるたびにInt値を生成する関数です。結果の型はIntではなくIO Intです。そのため、IOは、Int値がIOアクションが行われたプロセスの結果であることをユーザーに警告するInt値のラベルです。 その結果、このInt値はIOを持つプロセスからの値としてマークされているため、この値は「ダーティ」です。あなたのプロセスはもはや純粋ではありません。 見解2：モナドは、厄介なことが起こりうるプライベートな空間として。 すべてのプロセスが純粋で厳格なシステムでは、副作用が必要になる場合があります。そのため、モナドは、厄介な副作用を実行するための小さなスペースです。この空間では、あなたは純粋な世界から脱出し、不純なものに行き、あなたのプロセスを作り、価値を持って戻ってくることができます。 表示3：カテゴリー理論のようなモナド これは私が完全に理解していない見解です。モナドは、同じカテゴリーまたはサブカテゴリーの単なるファンクターです。たとえば、Int値があり、サブカテゴリとしてIO Intがあります。これは、IOプロセスの後に生成されるInt値です。 これらのビューは正しいですか？どちらがより正確ですか？

29 functional-programming  haskell  monad  side-effect 

F＃では、recキーワードを使用する必要があります。Haskellでは、特定の関数が再帰的であるかどうかを明示的に伝える必要はありません。 関数型プログラミングにおける再帰の役割を考えると、F＃の設計はかなり奇妙に思えます。それは良い言語設計の決定ですか、それとも歴史的な理由または実装の制約のためにのみ存在しますか？

28 functional-programming  language-design  f# 

Haskellで私がまったく思いつかなかったことの1つは、次のように、入力型では戻り型を決定できない多相定数と関数をどのように持つことができるかということです。 class Foo a where foo::Int -> a 私はこれが好きではない理由のいくつか： 参照の透明性： 「同じ入力が与えられたHaskellでは、関数は常に同じ出力を返します」が、それは本当ですか？コンテキストでread "3"使用すると3を返しIntますが、たとえば(Int,Int)コンテキストで使用するとエラーをスローします。はい、あなたはそれreadも型パラメータを取っていると主張することができますが、型パラメータの暗黙性は、私の意見ではその美しさの一部を失うことになります。 単相性の制限： Haskellで最も厄介なことの1つ。私が間違っている場合は修正してください。しかし、MRの全体的な理由は、共有されているように見える計算は、型パラメーターが暗黙的であるためではない可能性があることです。 デフォルトのタイプ： 繰り返しになりますが、Haskellで最も厄介なことの1つです。たとえば、出力で多相関数の結果を入力で多相関数に渡す場合に起こります。繰り返しますが、間違っている場合は修正してください。ただし、入力タイプ（および多態定数）で戻り値のタイプを判別できない関数がなければ、これは必要ありません。 だから私の質問は（「議論の質問」としてスタンプされるリスクを実行している）：型チェッカーがこれらの種類の定義を許可しないHaskellのような言語を作成することは可能でしょうか？もしそうなら、その制限の利点/欠点は何でしょうか？ 私はいくつかの差し迫った問題を見ることができます： 、たとえば、場合2のみのタイプを持っていたInteger、2/3現在の定義ではもうチェックを入力しないでしょう/。しかし、この場合、機能的な依存関係を持つ型クラスが助けになると思います（はい、これは拡張機能であることがわかります）。さらに、入力タイプが制限されている関数を使用するよりも、異なる入力タイプを使用できる関数を使用する方がはるかに直感的であると思いますが、ポリモーフィック値をそれらに渡すだけです。 []およびのNothingような値の入力は、クラックするのが難しいナットのように思えます。私はそれらを処理する良い方法を考えていません。

28 haskell  functional-programming 

Java / C＃/ C ++プログラマーとして、関数型言語について多くの話を聞いていますが、関数型言語を学ぶ必要はありません。関数型言語で導入されたより高いレベルの思考が、より優れたOOP /手続き型言語のプログラマーになると聞いたことがあります。 誰でもこれを確認できますか？どのような点でプログラミングスキルが向上しますか？ それほど洗練されていない言語でスキルを向上させることを目標に学習する言語の適切な選択は何ですか？

28 object-oriented  functional-programming 

次のコード例は、私の質問の背景を示しています。 Roomクラスはデリゲートで初期化されます。Roomクラスの最初の実装では、例外をスローするデリゲートに対するガードはありません。このような例外は、デリゲートが評価されるNorthプロパティにバブルアップします（注：Main（）メソッドは、クライアントコードでRoomインスタンスがどのように使用されるかを示します）。 public sealed class Room { private readonly Func<Room> north; public Room(Func<Room> north) { this.north = north; } public Room North { get { return this.north(); } } public static void Main(string[] args) { Func<Room> evilDelegate = () => { throw new Exception(); }; var kitchen = new Room(north: …

27 c#  functional-programming  pure-function 

「システムをモジュールに分解する際に使用する基準について」という古典的な記事がありますが、これは初めて読んだばかりです。それは私にとって完全に理にかなっており、おそらくOOPのベースとなった記事の1つです。その結論： これらの例により、フローチャートに基づいてシステムのモジュールへの分解を開始することはほとんど常に間違っていることを実証しようとしました。...各モジュールは、そのような決定を他のモジュールから隠すように設計されています 私の無学で経験の浅い意見では、関数型プログラミングはこの記事の正反対のアドバイスを取ります。私の理解では、関数型プログラミングはデータフローを慣用的にします。データは関数から関数に渡され、各関数はデータを密接に認識し、途中で「変更」します。そして、データの隠蔽が過大評価されているか、不必要であるか、または何かについて話しているリッチヒッキーのトークを見たことがあると思いますが、確かに思い出せません。 まず、私の評価が正しいかどうか知りたいです。FPパラダイムとこの記事は哲学的に同意しませんか？ 彼らが同意しないと仮定すると、FPはデータ隠蔽の欠如をどのように「補償」しますか？おそらく、データ隠蔽を犠牲にしてX、Y、およびZを獲得する可能性があります。X、Y、およびZがデータ隠蔽よりも有益である理由を知りたいのです。 または、両者が同意しないと仮定すると、FPはデータの非表示が悪いと感じるかもしれません。もしそうなら、なぜデータ隠蔽が悪いと思うのですか？ 彼らが同意すると仮定して、FPがデータ隠蔽の実装とは何かを知りたいです。OOPでこれを見るのは明らかです。privateクラス外の誰もアクセスできないフィールドを持つことができます。FPの場合、これについての明らかな類推はありません。 質問すべき他の質問もあると思いますが、質問すべきかはわかりません。それらにも自由に答えてください。 更新 このNeal Fordの講演には、非常に関連性の高いスライドが含まれています。ここにスクリーンショットを埋め込みます。

27 design  object-oriented  functional-programming  object-oriented-design