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

これは理論的な質問ですが、私が現在理解しているプログラミングの長年の後に、主にC ++を使用する「通常の」命令型テクニックです。 これにより、完全に状態指向のプログラムを、純粋に機能的で状態のない別の実装に技術的に置き換えることができるのではないかと思いました。 それは興味をそそるアイデアであり、関数型プログラミングには明確で優雅なものがあることを認めなければなりません。

13 javascript  functional-programming  haskell  state  turing-completeness 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 背景：私は、一般的なメンタルモデルが不可欠なプログラミングであるVB.NETショップで働く関数型プログラミングを提唱しています。システムの基盤はWinFormsであるため、命令型プログラミングから完全に逃れることはできないと理解できますが、そのメリットを信じているため、可能な限りFP（主にLinq経由）を使用しようとしています。 FPに対する議論と反論 流fluentなLinqは、このスタイルがシーケンスを別のシーケンスまで処理し、それを繰り返すという点で、命令型の対応するものよりも効率が低いことに気付くかもしれません。一般に、シーケンス上の繰り返しパスを避けるために最適化できる命令型アプローチよりも数パス多くかかります。このため、リードは、明らかに「効率が悪い」機能的アプローチを選択する理由を理解できませんでした。 反論：CPUサイクルの観点からは効率が悪い場合がありますが、各行はシーケンスを通過するときに1つのことだけを行うため、人間が理解しやすく、追跡しやすいと感じました。私にとって、これは、自分のステーションの各人がやるべき仕事が1つしかない組立ラインがあるような気がします。効率の無視できるトレードオフは、懸念がきちんと分離されたコードによって補償されると感じています。 私の店で聞くFPに対する次の議論は、デバッグするのが難しいということです-それは本当です。Linqコードをステップオーバーするのは簡単ではありません。そして、すぐに見つけられない問題をよりよく追跡して分析するために、メソッドチェーンを解く必要がある場合があります。 _Counter-argument：ほとんどの場合、機能スタイルは読み方がより宣言的であり、エラーが機能チェーン内でスローされると、私は通常、問題をすぐに見つけることができるため、これには問題はありません。 私の質問 私は店で機能的なスタイルを宣伝しようとしてきましたが、私は前進しているとは感じません。私は両方のスタイルのプログラミングを行ってきましたが、最近Haskellに手を出したばかりです。長年の命令的な経験にもかかわらず、私はJavaScriptでFPを日常的に使用しているので、それは私に成長しました。命令型のスタイルにこだわった場合に行ったことと比較すると、コアの正当性のメモが鳴ります。私は脳を機能的思考、機能的構成に向けて再訓練しました。 私が理解できないのは、FPのメリットを他の人に納得させるのがどれほど難しいかです。 たとえば、私のショップの開発者はLinqを使用していますが、通常はドメインデータを処理するコンテキストで使用しています。私はより一般的な意味でそれを使用し、シーケンス/リストまたは永続的なデータ構造を扱うときはいつでもそれを好みます。チームメイトにLinqの使用を拡大するよう説得することができませんでした。 私が理解しようとしているのは、開発者がFPを好まない原因です。 FPの経験が豊富であるが、命令型を支持することに決めた人からの回答を期待したい。機能を使用するのではなく、命令にとどまるという決定を下した理由は何ですか？ 命令型プログラミングと関数型プログラミングの違いを強調する追加の例を次に示します。 SelectedRowsLinqでグリッドのメソッドを次のように書きました。 Public Property SelectedRows() As DataRow() Implements IDataSourceControl.SelectedRows Get Return Me.ugrBase.Selected.Rows. OfType(Of Infragistics.Win.UltraWinGrid.UltraGridRow)(). Select(Function(ugr) ugr.ListObject). OfType(Of DataRowView)(). Select(Function(drv) drv.Row). ToArray End Get ただし、このスタイルのコードは一部の開発者を不快にさせるため、当社のリードはそれをより馴染みのあるものに書き換えました。 Public Property SelectedRows() As DataRow() Implements IDataSourceControl.SelectedRows Get Dim plstRows As …

13 object-oriented  functional-programming  linq  imperative-programming 

などなど、ほとんどの関数型プログラミング言語（例えばCommon Lispの、スキーム/ラケット、Clojureの、ハスケル、スカラ座、OCamlで、SML）リスト上のいくつかの一般的な高階関数をサポートするには、map、filter、takeWhile、dropWhile、foldl、foldr（例えば参照、Common Lispの、スキーム/ラケットをClojureの並列リファレンスシート、Haskell、Scala、OCaml、およびSMLドキュメント。 C ++ 11には、リストに同等の標準メソッドまたは関数がありますか？たとえば、次のHaskellスニペットを考えます。 let xs = [1, 2, 3, 4, 5] let ys = map (\x -> x * x) xs 最新の標準C ++で2番目の式をどのように表現できますか？ std::list<int> xs = ... // Initialize the list in some way. std::list<int> ys = ??? // How to translate the Haskell expression? 上記の他の高階関数はどうですか？ C …

13 c++  functional-programming  c++11  lambda  list 

編集：私は質問を少し言い換えています。デストラクタという用語がOOPでまったく異なる何かに使用されていることに気づかなかったため、どうやら混乱が生じたようです。これは、オブジェクトが破棄されるときに呼び出される関数です。関数型プログラミングでは、可変状態を回避しようとするため、それに相当するものはありません。（質問に適切なタグを追加しました。） 代わりに、値をアンラップするためのレコードフィールド（特にnewtypes などの単一値のデータ型の場合）がdestructorまたはdeconstructorと呼ばれることもあります。たとえば、（Haskellで）次のようにします： newtype Wrap = Wrap { unwrap :: Int } ここWrapにコンストラクタがあり、それunwrapは何ですか？ 質問は次のとおりです。 unwrap関数型プログラミングをどのように呼び出すのですか？解体者？デストラクタ？それとも他の言葉で？ そして、明確にするために、この/他の用語は他の関数型言語に適用できますか、それともHaskellだけで使用されますか？ おそらく、これには一般的に、非機能的な言語での用語はありますか？ 私は両方の用語を見ました、例えば： ...ほとんどの場合、スマートコンストラクターとデストラクタを提供して、これらを簡単に操作できるようにします。... で、Haskellのウィキ、または ...ここでの一般的なテーマは、コンストラクターとデコンストラクターのペアを融合することです... で、Haskellのwikibook（ここではそれはおそらく、もう少し一般的な意味でのものです）、または newtype DList a = DL { unDL :: [a] -> [a] } unDL関数はdeconstructorで、DLコンストラクターを削除します。... 中実世界ハスケル。

13 terminology  functional-programming  haskell  data 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 Clojureをしばらく使ってきましたが、重要なプロジェクトでは使用していません。基本的に、構文といくつかのイディオムに慣れてきました。OOPのバックグラウンドから来て、Clojureが私が非常によく見た最初の関数型言語であるため、私は当然、物事の関数型の方法にそれほど満足していません。 とはいえ、大規模な機能アプリケーションの作成に共通する特定のワークフローやデザインパターンはありますか 「実際に」関数型プログラミングの使用を開始したいのですが、現在の専門知識の不足により、大失敗に終わるのではないかと心配しています。 「4つのギャング」はOOプログラマーにとって非常に標準ですが、機能的なパラダイムにより向けられた類似のものはありますか？私が見つけたほとんどのリソースには、優れたプログラミングナゲットがありますが、一歩踏み込んで、より広範な、よりアーキテクチャ的な外観を与えることはできません。

13 design-patterns  functional-programming  application-design 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 私はこれに興味があります。関数型言語を学ぶ前に思い出したので、それらはすべて恐ろしく、ひどく、ひどく読めないと思っていました。Haskellとf＃を知ったので、少ないコードを読むのに少し時間がかかりますが、その小さなコードは命令型言語での同等の量よりもはるかに多いので、純益のように感じ、私は極端ではありません機能的に実践。 ここに私の質問があります。私は、OOPの人々から、機能的なスタイルはひどく読めないと常に聞いています。これが事実であり、自分を欺いているのか、または関数型言語を習得するのに時間がかかったのであれば、スタイル全体がOOPよりも読みにくくなるのではないかと思います。 誰かが証拠を見たり、逸話を手に入れたりして、おそらくこれを言うのに十分な頻度で行っていますか？機能的に実際に書くのが読みにくい場合は、使い続けたくありませんが、そうなのかどうかはわかりません。

13 object-oriented  functional-programming  readability 

私は関数型および論理型プログラミングに強い関心があり、Mercuryはこの2つをうまく融合させているようです。業界で使用されていますか？私はその楽しみのためだけに言語を学びたいと思っていますが、実用的で雇用可能な手段があればいいと思います。言語のウェブサイトでの産業での使用例についてはあまり見つけることができませんでした。

13 programming-languages  functional-programming  industry  logic-programming 

他のパラダイムの前に関数型プログラミングを学ぶことの長所と短所は何ですか？

13 programming-languages  functional-programming  paradigms 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 私は再帰とは何かを知っています（通常、パテンが自身内で発生するとき、通常はブレークアウト条件付き...の後にその行の1つでそれ自体を呼び出す関数ですか？）、それらを詳しく調べれば再帰関数を理解できます。私の問題は、新しい例を見ると、最初はいつも混乱していることです。ループ、またはマッピング、ジッピング、ネスト、ポリモーフィックコールなどが表示される場合、それを見るだけで何が起こっているかがわかります。再帰的なコードを見ると、私の思考プロセスは通常「wtf is this？」です。続けて「ああ、再帰的」、続いて「もし彼らが言うなら、うまくいくに違いない」と続きます。 この分野でスキルを構築するためのヒント/計画/リソースはありますか？再帰は奇妙な概念の一種なので、それに取り組む方法も同様に奇妙で明白ではないかと考えています。

13 learning  functional-programming  lisp  haskell  recursion 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 私が現在使用している主な言語はC＃であり、私はこれに最も慣れています。しかし、私はF＃とHaskellに手を出し始め、それらの言語を本当に楽しんでいます。私はそれらを使用するのが本当に楽しいので、時間の経過とともにこれらの言語のいずれかでスキルを向上させたいと思います（「楽しい」と宣伝されるRubyとは対照的に、私はただ楽しみがどこにあるかわかりませんが、脱線します...）。私の質問は、プログラミングポジション（ジュニア/ミッドレベル）を採用/面接した人に向けられています。履歴書に関数型プログラミング言語が表示された場合、その候補者の意見（肯定的または否定的）に影響しますか？ 候補者の見解に影響を与える関数型プログラミングの知識に対する私の理論的根拠は、候補者が異なる方法論に適応でき、「同じ古いオブジェクト指向アプローチ」ではなく、問題に対して多次元アプローチをとることができるからです。（これはオフベースかもしれませんが、この仮定が同様であるかどうか私に知らせてください！）

13 functional-programming 

私は何度も何度も耳にしましたが、FPとOOは直交しているという考えを理解し、検証しようとしています。 まず、2つの概念が直交しているとはどういう意味ですか？ FPは、可能な限り不変性と純度を推奨します。そしてオブジェクト指向は、状態と突然変異（命令型プログラミングのわずかに組織化されたバージョン？）のために構築されたもののようです。そして、私はオブジェクトが不変であることを理解しています。しかし、オブジェクト指向は私に状態/変化を暗示しているようです。 彼らは反対のように見えます。それは、それらが直交しているということですか？ Scalaのような言語を使用すると、OOとFPの両方を簡単に実行できますが、これは2つのメソッドの直交性に影響しますか？

13 programming-languages  functional-programming  object-oriented  paradigms 

純粋な関数は、並列化を容易にすることが知られています。 本質的に並列実行に適応させる関数型プログラミングについてはどうですか？ Javacなどのコンパイラは、メソッドが純粋な関数であるかどうかを検出するのに十分スマートですか？Functionなどの機能インターフェイスを実装するクラスを常に実装できますが、副作用があります。

12 functional-programming 

どのように私は、次のすべてを持っているシステムを構築します。 不変オブジェクトで純粋な関数を使用します。 関数が必要とする関数データのみに渡し、それ以上（つまり、大きなアプリケーション状態オブジェクトはなし） 関数への引数が多すぎることは避けてください。 関数に渡されるパラメーターが多すぎるのを避けるために、関数にパラメーターをパックおよびアンパックするためだけに新しいオブジェクトを作成する必要はありません。複数のアイテムを単一のオブジェクトとして関数にパックする場合、一時的に構築されたものではなく、そのオブジェクトをそのデータの所有者にしたい Stateモナドはルール2に違反しているように思えますが、モナドを介して織り込まれているため明らかではありません。 どういうわけかレンズを使用する必要があると感じていますが、非機能言語についてはほとんど書かれていません。 バックグラウンド 演習として、既存のアプリケーションの1つをオブジェクト指向スタイルから機能スタイルに変換しています。私が最初にやろうとしているのは、アプリケーションの内部コアをできるだけ多く作成することです。 私が聞いたことの1つは、純粋に機能的な言語で「状態」を管理する方法であり、これは私がステートモナドによって行われていると信じていることです。 「そのままの世界」を選択し、関数が戻ると、変化した世界の状態を返します。 たとえば、純粋に機能的な方法で「hello world」を実行する方法は、プログラムに画面の状態を渡し、「hello world」が印刷された画面の状態を受け取るようなものです。技術的には、純粋な関数を呼び出しているので、副作用はありません。 それに基づいて、アプリケーションを調べました。1。最初に、すべてのアプリケーション状態を単一のグローバルオブジェクト（GameState）に入れます。2。次に、GameStateを不変にしました。変更することはできません。変更が必要な場合は、新しいものを作成する必要があります。これを行うために、コピーコンストラクターを追加しました。オプションで、変更された1つ以上のフィールドを使用します。3.各アプリケーションに、GameStateをパラメーターとして渡します。関数内で、予定通りの処理を行った後、新しいGameStateを作成して返します。 純粋に機能的なコアと、そのGameStateをアプリケーションのメインワークフローループにフィードする外側のループの仕組み。 私の質問： さて、私の問題は、GameStateには約15種類の不変オブジェクトがあることです。最下位レベルの関数の多くは、スコアの保持など、これらのオブジェクトの一部のみで動作します。それで、スコアを計算する関数があるとしましょう。今日、GameStateはこの関数に渡され、新しいスコアで新しいGameStateを作成してスコアを変更します。 それについて何かが間違っているようです。この関数はGameState全体を必要としません。スコアオブジェクトが必要です。そこで、スコアを渡すように更新し、スコアのみを返します。 それは理にかなっているように思えたので、私は他の機能をさらに使いました。一部の関数では、GameStateから2、3、または4つのパラメーターを渡す必要がありますが、アプリケーションの外側のコア全体でパターンを使用しているため、ますます多くのアプリケーション状態を渡しています。たとえば、ワークフローループの先頭で、メソッドを呼び出し、メソッドを呼び出すメソッドなどを呼び出して、スコアが計算されるまで続けます。つまり、一番下の関数がスコアを計算するという理由だけで、現在のスコアがこれらすべてのレイヤーに渡されます。 だから今私は時々数十のパラメータを持つ関数を持っています。これらのパラメーターをオブジェクトに入れてパラメーターの数を減らすこともできますが、そのクラスは、単に渡すことを避けるために呼び出し時に単純に構築されるオブジェクトではなく、状態アプリケーション状態のマスターの場所にしたいです複数のパラメータで、それらを解凍します。 だから今、私が持っている問題は私の関数があまりにも深くネストされていることだろうかと思っています。これは小さな関数が必要なためです。そのため、関数が大きくなったらリファクタリングし、複数の小さな関数に分割します。しかし、そうすることでより深い階層が生成され、外部関数が直接それらのオブジェクトを操作していない場合でも、内部関数に渡されたものはすべて外部関数に渡される必要があります。 この問題を回避する方法に沿って単にGameStateを渡すように見えました。しかし、関数が必要とする以上の情報を関数に渡すという元の問題に戻りました。

12 c#  functional-programming  immutability  state  monad 

：ここではSPOJから、簡単なプログラミングの問題であるhttp://www.spoj.com/problems/PROBTRES/が。 基本的に、iとjの間の数値に対して最大のCollat​​zサイクルを出力するように求められます。（数$ n $のコラッツサイクルは、最終的に$ n $から1に到達するためのステップ数です。） 私は、JavaまたはC ++のパフォーマンスと比較してパフォーマンスを解決するHaskellの方法を探しています（許可された実行時間の制限に収まるように）。既に計算されたサイクルのサイクル長をメモする単純なJavaソリューションは機能しますが、Haskellソリューションを取得するためのアイデアの適用に成功していません。 Data.Function.Memoizeと、この投稿/programming/3208258/memoization-in-haskellのアイデアを使用して、自家製のログ時間メモ化手法を試しました。残念ながら、メモ化は実際にはcycle（n）の計算をさらに遅くします。減速はHaskellウェイのオーバーヘッドによるものだと思います。（解釈する代わりに、コンパイル済みのバイナリコードで実行してみました。） また、iからjへの単純な反復処理にはコストがかかる（$ i、j \ le10 ^ 6 $）と思われます。そこで、http://blog.openendings.net/2013/10/range-trees-and-profiling-in-haskell.htmlからのアイデアを使用して、範囲クエリのすべてを事前計算しようとしました。ただし、これでも「Time Limit Exceeding」エラーが発生します。 このために、きちんとした競争力のあるHaskellプログラムに知らせるのを手伝ってもらえますか？

12 programming-practices  functional-programming  haskell 

私がLINQを使い始めて以来、私は4年前から関数型プログラミングの傾向にあります。最近、私はいくつかの純粋な関数型C＃コードを書いて、関数型プログラムについて読んでいることに最初に気付きました。 私はこれがなぜそうなのかを試してみましたが、成功していません。 OOプリンシパルの適用では、機能プログラムにはない「抽象化層」があり、この抽象化層により、実装が間違っていてもオブジェクト間のコントラクトを正しくすることができます。 誰かがこれを考えて、コンパイルの成功と関数型プログラミングのプログラムの正確性との相関関係の根本的な抽象的な理由を思い付きましたか？

12 functional-programming