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

2
機能的リアクティブプログラミングとアクターモデルはどのように相互に関連していますか?
FRPは、純粋な機能によるイベントと動作のストリーミングに関するものです。少なくともAkkaで実装されているアクターモデルは、アクターと呼ばれる不純なオブジェクトを介した不変メッセージ(離散イベントと見なすことができます)のストリーミングに関するものです。 したがって、表面上はそれらは関連しているように見えます。 それらがどのように関連しているかについて、他に何を言えますか?また、それらのどれが異なるアプリケーションドメインにより適切であるかもしれないかについて何が言えるでしょうか?

4
関数型プログラミングで永続データ構造を使用するのはなぜですか?
関数型プログラミングでは、永続的なデータ構造と不変オブジェクトが使用されます。私の質問は、なぜこのようなデータ構造をここに持つことが重要なのですか?データ構造が永続的でない場合、どうなるかを低レベルで理解したいですか?プログラムはより頻繁にクラッシュしますか?

7
ラムダ計算は抽象的に見えませんでした。そして、私はそれのポイントを見ることができません
根本的な質問: ラムダ計算は、中学校の代数で一般に学んだ基本的な関数のプロパティと表記法ではできないことを私たちに何をしますか? まず、ラムダ計算の文脈で抽象とはどういう意味ですか?抽象という言葉の私の理解は、概念の概念的な要約である機械から離婚したものです。 ただし、ラムダ関数は、関数名を廃止することにより、特定のレベルの抽象化を防ぎます。例えば: f(x) = x + 2 h(x, y) = x + 5 y しかし、これらの機能の仕組みを定義しなくても、その構成について簡単に話すことができます。例えば: 1. h(x, y) . f(x) . f(x) . h(x, y) or 2. h . f . f . h 必要に応じて引数を含めることも、完全に抽象化して何が起きているのかを概観することもできます。そして、それらをすぐに単一の機能に減らすことができます。構成2を見てみましょう。強調に応じて、学生の詳細なレイヤーを書くことができます。 g = h . f . f . h g(x, y) = h(x, …

8
OOPは実際に手続き型プログラミングのどのような問題を解決しますか?
私は本「C ++ Demystified」を研究しました。今、私はRobert Laforeによる「Turbo C ++のオブジェクト指向プログラミング初版(第1版)」を読み始めました。これらの本を超えるプログラミングの知識はありません。この本は20年前のものなので、時代遅れかもしれません。私は最新版を持っています、私はそれが好きなので古いものを使用しています。主に、ラフォーの本の初版を通してC ++で使用されるOOPの基本概念を研究しています。 Laforeの本は、「OOP」が大きくて複雑なプログラムにのみ役立つことを強調しています。すべてのOOP本(同じくLaforeの本)で、手続き型のパラダイムはエラーを起こしやすいと言われています。たとえば、グローバルデータは関数によって簡単に脆弱です。プログラマーは、誤ってデータを破壊する関数を作成するなど、手続き型言語で正直なエラーを犯す可能性があると言われています。 正直に言って、この本に記載されている説明を把握していないため、質問を投稿しています。C++(4版)のオブジェクト指向プログラミングラフォーの本に書かれたこれらのステートメントを把握していません。 オブジェクト指向プログラミングは、プログラミングへの以前のアプローチで制限が発見されたために開発されました....プログラムがますます大きく複雑になるにつれて、構造化プログラミングアプローチでさえ緊張の兆候を示し始めます... ....これらの失敗は、手続き型パラダイム自体に弱点があることを明らかにしています。構造化プログラミングのアプローチがどれほどうまく実装されていても、大規模なプログラムは過度に複雑になります。...関連する2つの問題があります。まず、関数はグローバルデータに無制限にアクセスできます。第二に、手続き型パラダイムの基礎である無関係な関数とデータは、現実世界の貧弱なモデルを提供します... 私はジェフ・ケントによる「dysmystified C ++」という本を研究しました。この本がとても好きで、この本では主に手続き型プログラミングが説明されています。手続き型(構造化)プログラミングが弱い理由がわかりません! Laforeの本は、いくつかの良い例を使って概念を非常にうまく説明しています。また、OOPは手続き型プログラミングよりも優れているというLaforeの本を読んで、直感を理解しましたが、実際には手続き型プログラミングがOOPよりも弱いことを知りたいと思います。 手続き型プログラミングで直面する実際的な問題とは何か、OOPがプログラミングを容易にする方法を自分で確認したいと思います。私はLaforeの本を黙想的に読むだけで答えが得られると思いますが、手続き型コードの問題を自分の目で見たいです。プログラムのOOPスタイルのコードが、同じプログラムが手続き型パラダイムを使用して記述されていました。 OOPには多くの機能があり、これらのすべての機能が手続き型のコードを記述することによって発生する前述のエラーをどのように除去するかを説明することは不可能だと理解しています。 だから、ここに私の質問があります: OOPは手続き型プログラミングのどの制限に対処し、実際にこれらの制限を効果的に削除するのですか? 特に、手続き型パラダイムを使用して設計するのは難しいが、OOPを使用して簡単に設計するプログラムの例はありますか? PS:https : //stackoverflow.com/q/22510004/3429430からクロス投稿

2
純粋なデータフロースタイルで「増分更新」関数を構成するためのパラダイムはありますか?
この質問をするための正しい用語がわからないので、代わりにたくさんの言葉で説明します。 背景、同じページにいるだけです。プログラムにはキャッシュが含まれていることが多く、時間とメモリのトレードオフです。プログラマーのよくある間違いは、上流のソース/前例の1つを変更した後、キャッシュされた値を更新するのを忘れることです。しかし、データフローまたはFRPプログラミングパラダイムは、そのような間違いの影響を受けません。純粋な関数がいくつかあり、それらを有向ディペンデンシーグラフで接続している場合、ノードは出力値をキャッシュし、関数の入力が変更されるまで再利用できます。このシステムアーキテクチャは、Dataflowベースの環境でのキャッシングペーパーで説明されており、命令型言語では、メモ化とほぼ同じです。 問題:関数への入力の1つが変化しても、関数全体を実行し、キャッシュされた出力を破棄して、最初から再計算する必要があります。多くの場合、これは私にとって無駄に思えます。「トップ5なんでも」リストを生成する簡単な例を考えてみましょう。入力データは、何も並べ替えられていないリストです。ソートされたリストを出力する関数への入力として渡されます。これは、最初の5項目のみを受け取る関数に入力されます。疑似コード: input = [5, 20, 7, 2, 4, 9, 6, 13, 1, 45] intermediate = sort(input) final_output = substring(intermediate, 0, 5) ソート関数の複雑さはO(N log N)です。ただし、このフローは、1つの要素を追加することで、入力が一度に少しだけ変化するアプリケーションで使用されることを考慮してください。毎回最初から再ソートするよりも、実際にはO(N)の方が、新しい要素を正しい位置に挿入することにより、古いキャッシュソートリストを更新する関数を使用する方が高速です。これはほんの一例にすぎません-多くの「最初から」の関数には、そのような「増分更新」の対応物があります。また、新しく追加された要素は5番目の位置にあるため、final_outputにも表示されない場合があります。 私の直感は、このような「増分更新」関数を、既存の「最初から」関数と並べて、データフローシステムに何らかの方法で追加できる可能性があることを示唆しています。もちろん、すべてを最初から再計算すると、常に一連の増分更新を実行した場合と同じ結果が得られます。システムは、その性質を持っている必要がある場合は、個々のプリミティブFromScratch-インクリメンタルペアのそれぞれが常に同じ結果が得られ、その後、彼らから構築された大規模複合機能も自動的に同じ結果を与える必要があります。 質問:FromScratch関数とそのインクリメンタル関数の両方をサポートし、効率を高めるために協力し、大きなフローに構成できるシステム/アーキテクチャ/パラダイム/メタアルゴリズムを使用することは可能ですか?そうでない場合、なぜですか?誰かがこのパラダイムをすでに研究して公開している場合、それは何と呼ばれ、どのように機能するかの簡単な要約を入手できますか?

3
プログラミングモデルとプログラミングパラダイムの違い?
プログラミングモデルとプログラミングパラダイムの関係と違いは何ですか?(特に、プログラミングモデルとプログラミング言語のプログラミングパラダイムについて話すとき。) ウィキペディア は1で私の質問に答えようとします: プログラミングパラダイムは、コンピューターシステムを抽象化したプログラミングモデルと比較することもできます。たとえば、「フォンノイマンモデル」は、従来のシーケンシャルコンピュータで使用されているプログラミングモデルです。並列計算の場合、通常、プロセッサを相互接続するさまざまな方法を反映した多くの可能なモデルがあります。最も一般的なものは、共有メモリ、メッセージパッシング付きの分散メモリ、またはこの2つのハイブリッドに基づいています。 しかし、私はそれを理解していません: フォンノイマンモデルはhttps://en.wikipedia.org/wiki/Von_Neumann_architectureの建築モデルであることを理解しているため、ウィキペディアの引用に「「フォンノイマンモデル」はプログラミングモデルである」と記載されているのは間違い ですか。 並列プログラミングモデルは「通常、プロセッサを相互接続するさまざまな方法を反映していますか」?それとも、代わりに「プロセッサを相互接続するさまざまな方法を反映した」並列アーキテクチャモデルですか? 1の質問に答えるために、プログラミングモデルとは何かを明確にできますか? プログラミング言語またはAPIライブラリによって提供/実装されたプログラミングモデルであり、そのような実装は一意ではないのは正しいですか。 Rauberの並列プログラミングの本、「プログラミング・モデル」、「アーキテクチャ・モデル」以上の順番である「計算モデル(すなわち計算モデル)」上記の抽象化です。プログラミングモデルは、並列コンピューティングで使用されるだけでなく、プログラミング言語またはAPIライブラリでも使用されていると思います。

2
関数型プログラミングは、変装した命令型プログラミングではありませんか?
私が見ていたYouTubeビデオでは、命令型プログラミングと関数型プログラミングの違いについて、JavaとHaskellでそれぞれ1to からtoまでの数を10合計する方法を説明することで説明しました。 Javaでは、各ステップを明示的に記述し、各ステップの結果を変数に割り当てる必要があります-次のようなもの int total = 0; for (int i = 1; i <= 10; i++){ total = total + i; } return total; Haskellでは、次のように簡単に言うことができます。 sum(1..10) 私の質問は次のとおりです。関数型言語のバックグラウンドで何かが起こっていることは明らかであり、その何かはある種の命令型プロセスでなければなりません。関数型言語は、実際には一種の命令型言語のAPIのようです。たとえばsum(int start, int end)、Javaでメソッドを定義することにより、関数型言語の一部を作成できます。私は本当に新しいタイプの言語をすぐに作成しましたか、それとも命令命令をユーザーから隠す一連の命令メソッド呼び出しを定義しただけですか? 私が理解するのに苦労していることがはっきりしているといいのですが。

1
「状態」が許容されない場合、関数型言語を使用して命令型言語ですべてを実行できますか?
私はMITのコンピュータープログラムの構造と解釈(SICP)を読んでいました。私が理解したのは、純粋な関数型プログラミング言語では、ローカルな状態などは存在しないということです。SICP、pg 230は言う: 「この本の最後の2つの章で行ったように、割り当てを使用しないプログラミングは、関数型プログラミングと呼ばれています。」 私は命令型プログラミングのバックグラウンドを持っており、実際のシステム(単純な銀行やライブラリ管理ソフトウェアなど)をモデル化して、状態を意識せずにプログラムを作成する方法を理解できていないようです。 関数型プログラミングに状態の概念がない場合、どうすればよいですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.