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

コンピュータプログラミングの基本的なスタイル。

4
命令型プログラミング、手続き型プログラミング、構造化プログラミングの違いは何ですか?
(書籍、ウィキペディア、SEに関する同様の質問など)を調査することで、命令型プログラミングは主要なプログラミングパラダイムの1つであり、コンピューターが実行する一連のコマンド(またはステートメント)を記述する(つまり、特定のアクションを実行するように多くの順序を指定するため、「命令型」という名前が付けられます)。ここまでは順調ですね。 一方、手続き型プログラミングは、命令型プログラミングの特定のタイプ(またはサブセット)であり、プロシージャ(関数)を使用してコンピューターが実行するコマンドを記述します。 最初の質問:手続き型ではない命令型プログラミング言語はありますか?言い換えると、プロシージャなしで命令型プログラミングを使用できますか? 更新:この最初の質問には答えられているようです。言語は、手続き的または構造化されていなくても不可欠です。例は、純粋なアセンブリ言語です。 次に、構造化プログラミングもあります。これは、命令型プログラミングの別のタイプ(またはサブセット)と思われ、GOTOステートメントへの依存を取り除くために登場しました。 2番目の質問:手続き型プログラミングと構造化プログラミングの違いは何ですか?あなたは一方を他方なしで持つことができますか?画像のように、手続き型プログラミングは構造化プログラミングのサブセットであると言えますか?

3
C#/ OOPでは貧弱なドメインモデルが悪いと考えられますが、F#/ FPでは非常に重要なのはなぜですか?
でブログの記事楽しさと利益のためにF#上、それは言います: 機能設計では、動作をデータから分離することが非常に重要です。データ型は単純で「ダム」です。そして、別に、これらのデータ型に作用する多くの関数があります。 これは、動作とデータを組み合わせることを意図したオブジェクト指向設計の正反対です。結局のところ、それはまさにクラスです。実際にオブジェクト指向の設計では、振る舞い以外は何もありません。データはプライベートであり、メソッドを介してのみアクセスできます。 実際、OODでは、データ型の周囲に十分な動作がないことは悪いことと見なされ、「貧血領域モデル」という名前さえあります。 C#では、F#から借用し続け、より機能的なスタイルのコードを記述しようとしているようです。なぜデータ/動作を分離するという考えを借りず、それを悪いと考えるのでしょうか?定義がOOPを伴わないというだけなのでしょうか、それともC#で悪いのに何らかの理由でF#に適用されない(そして実際には逆になる)具体的な理由がありますか? (注:私は、ブログ投稿のどちらかの意見に同意しない個人ではなく、善/悪の意見を変える可能性のあるC#/ F#の違いに特に興味があります)。

7
Haskell AND Lisp vs. Haskell OR Lisp [終了]
現在、C、C ++、およびPythonを使用してコーディングしています。関数型プログラミング言語を使いたいと思っていますが、今はHaskellに傾倒しています。ここで「Haskell vs Lisp」戦争を始めたくありません。私が知りたいのはこれです:主に関数型プログラミングに触れるためにHaskellを学んだ場合、後でLispを学ぶことでどんな利益が得られますか?

9
コーディング時に解析によって麻痺を克服するにはどうすればよいですか?
新しいプロジェクトを始めるとき、私はしばしばすぐに実装の詳細について考え始めます。「DataBaseHandlerはどこに配置しますか。どのように使用する必要がありますか?それを使用するクラスはいくつかの抽象スーパークラスから拡張する必要があります..?インターフェイスを使用する必要がありますか?を含むクラスで使用する抽象化のレベルリクエストを送信してデータを解析する方法は?」 拡張性と再利用性のためにコーディングしたいので、私は長い間行き詰まってしまいます。しかし、完全に実装する方法について過去の考えを得るのはほとんど不可能だと感じています。 そして、「ネジを締めて、やるだけだ!」と言うと、コードが整理されていないため、抽象化のレベルが混在しているなどの理由で、レンガの壁にすばやくぶつかります。 新しいプロジェクトを立ち上げながら、拡張性の高い論理/モジュール構造をセットアップするためのテクニック/方法は何ですか? - - EDIT - - まあ、これはすでに答えを受け入れるのが難しいタイプの質問ですが、いくつかのコンセンサスがあるかどうかを確認して、より多くのフィードバックを取得したいです。TDDは本当にクールに聞こえますが、率直に言って、JUnitなどの使用方法をもっと理解することを意味してきました。同時に、TDDのファンは、TDDに関連する1つの正当な点が特定の問題は、TDDが実際に設計の問題に対処していないように見えることです。確かに、TDDは自分がやりたいことを定義するのに役立ち、徐々にその方法を進めることができますが、ユニットテストをすべて通過できるさまざまな全体的なデザインパターン/構造があります。それだけです:単一のUNITSをテストします。私は少し混乱していると思います...私は知らない。多分、私' ありがとう!

1
表形式プログラミングとは何ですか?
ファルコンプログラミング言語は、表形式のプログラミングをサポートしているとして自分自身をアドバタイズします。 Falconは、手続き型、オブジェクト指向、プロトタイプ指向、機能指向、表形式、メッセージ指向の6つの統合プログラミングパラダイムを提供します。そして、それらすべてを習得する必要はありません。好みの材料を選んで、コードがインスピレーションに従うようにするだけです。 ドキュメントには、(単純な例から明らかであるものを当然のを除いて)平板プログラミングの言語の味がどのように機能するかのビットを展開していますが、言語の独自の構造と構文に焦点を当てていますし、本当にパラダイムのメリットを説明していません。 私はファルコンTableがリレーショナルテーブルとして多かれ少なかれ機能するネイティブ構造であり、リレーショナルクエリ機能を備えたネイティブレコードセットとして記述することができるネイティブオブジェクト構造であると理解していることから、全体が内部的にどのように機能するかについて少し混乱しています。恐ろしい説明、私は知っている(私のOOルーツとテキーラを乱用の長年を非難します)。 表形式プログラミングとは何か、内部でどのように機能するかをよりよく理解するのを手伝ってもらえますか? 明確化:私はないについての質問表形式モデルプログラミング。
34 paradigms 

3
エラー処理の考慮事項
問題: 長い間、私はexceptionsメカニズムが本当に何をすべきかを実際には解決しないと感じているため、メカニズムについて心配しています。 クレーム:このトピックについては長い議論があり、それらのほとんどはexceptionsエラーコードの比較と返送に苦労しています。これは間違いなくここのトピックではありません。 エラーを定義しようとすると、Bjarne Stroustrup&Herb SutterのCppCoreGuidelinesに同意します エラーは、関数が公示された目的を達成できないことを意味します クレーム:exceptionメカニズムは、エラーを処理するための言語セマンティックです。 クレーム:私には、タスクを達成しないための機能には「言い訳」がありません:機能が結果を保証できないように事前/事後条件を誤って定義したか、開発に時間を費やすために特定の例外的なケースが十分に重要ではないと考えられます解決策。IMOでは、通常のコードとエラーコードの処理の違いは(実装前に)非常に主観的なものだと考えています。 クレーム:例外を使用して、事前または事後条件が維持されていないことを示すことはexception、主にデバッグの目的で、メカニズムの別の目的です。私はexceptionsここのこの使用法をターゲットにしません。 多くの書籍、チュートリアル、およびその他のソースでは、エラー処理は非常に客観的な科学として示される傾向がexceptionsありますが、それは解決され、catchあらゆる状況から回復できる堅牢なソフトウェアが必要です。しかし、開発者としての数年間は、別のアプローチから問題を見るようになりました。 プログラマは、特定のケースがあまりにもまれに慎重に実装できないと思われる場合に例外をスローすることにより、タスクを単純化する傾向があります。この典型的なケースは次のとおりです。メモリ不足の問題、ディスクの空き容量の問題、破損したファイルの問題など。これで十分かもしれませんが、必ずしもアーキテクチャレベルから決定されるわけではありません。 プログラマは、ライブラリの例外に関するドキュメントを注意深く読んでいない傾向があり、通常、関数がスローするタイミングとタイミングを認識していません。さらに、たとえ知っていても、実際には管理していません。 プログラマーは、十分早くに例外をキャッチしない傾向があります。そして、それらをキャッチする場合、ほとんどの場合、ログに記録してさらにスローします。(最初のポイントを参照)。 これには2つの結果があります。 頻繁に発生するエラーは、開発の初期段階で検出され、デバッグされます(これは良いことです)。 まれな例外は管理されず、ユーザーのホームでシステムがクラッシュします(素敵なログメッセージが表示されます)。エラーが報告される場合もあれば、そうでない場合もあります。 それを考慮すると、IMOのエラーメカニズムの主な目的は次のとおりです。 特定のケースが管理されていないコードで可視化する。 この状況が発生した場合、問題のランタイムを関連コード(少なくとも呼び出し元)に伝えます。 回復メカニズムを提供します exceptionエラー処理メカニズムとしてのセマンティックの主な欠陥はIMOです。throwソースコードのどこにa があるかは簡単にわかりますが、宣言を見ることで特定の関数がスローできるかどうかはわかりません。これは、上で紹介したすべての問題をもたらします。 言語は、言語の他の側面(たとえば、強力なタイプの変数)の場合ほど厳密にエラーコードを適用およびチェックしません。 解決策を試す これを改善するために、非常に単純なエラー処理システムを開発しました。これは、通常のコードと同じレベルのエラー処理をエラー処理にしようと試みます。 アイデアは次のとおりです。 各(関連する)関数は、success非常に軽いオブジェクトへの参照を受け取り、場合によってはエラー状態に設定することがあります。オブジェクトは、テキスト付きのエラーが保存されるまで非常に軽いです。 提供されたオブジェクトに既にエラーが含まれている場合、関数はそのタスクをスキップすることが推奨されます。 エラーを無効にしないでください。 完全な設計では、明らかに各側面(約10ページ)を徹底的に検討し、OOPへの適用方法も検討します。 Successクラスの例: class Success { public: enum SuccessStatus { ok = 0, // All is fine error = 1, // …

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

8
依存関係を他のプログラマーに非常に明白にすることを促進するプログラミングパラダイムはありますか?
私は、さまざまなアーティファクトをリンクする迷路のような依存関係を持つ多くのストリームとレイヤーを介して複数のシステムを調達するデータウェアハウスで働いています。ほぼ毎日、このような状況に陥ります。何かを実行しますが、機能しません。大量のコードを調べますが、数時間後には、今わかっていることのごく一部のプロセスマップを概念化することができました。後日必要になるので、誰かに尋ねて、この他のストリームを最初に実行する必要があることと、ここでチェックした場合(他のコード化された依存関係の巨大なスタックの一見arbitrary意的な部分を示す)、これを見た。とてもイライラします。 再帰的なレベルのコードや、さらにはデータにオブジェクトを深く埋め込むのではなく、オブジェクト間の依存関係をより明確に見えるようにするためにもっとや​​った方がいいだろうとチームに提案できた場合おそらく、よく知られ、試行され、テストされたソフトウェアパラダイムを参照することで、別のストリームが存在するために存在する必要があります。 私のチームにこの利点を説明するのはちょっと難しいです。彼らは物事をありのままに受け入れる傾向があり、システム全体を新しい方法で概念化できる利点を見るという点で「大きく考える」ことはしません。巨大なシステムをモデル化できるなら、効率的な場合、メモリの非効率性、ストリーム停止の一意の制約、重複キー、ナンセンスデータに遭遇する可能性が低くなります。元のビジョンに沿って設計する方がはるかに簡単で、後でこれらすべての問題に遭遇することはありません私たちは現在、過去の仕事では珍しいことを知っていますが、彼らは避けられないと考えているようです。 では、依存関係を強調し、理想の長期的な順守を確保するために、システムの一般的な概念モデルを促進するソフトウェアパラダイムを知っている人はいますか?現時点ではかなり混乱しており、すべてのスプリントは「こことこことここにこのものを追加するだけ」であるように見えます。

13
関数型プログラミングに対するあなたの最も強い意見は何ですか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 関数型プログラミングは、最も古いプログラミングパラダイムの1つです。ただし、より一般的なパラダイムと比較して、業界ではあまり使用されていません。しかし、それは主に学界で強調されてきました。 関数型プログラミングに対するあなたの最も強い意見は何ですか?

5
プログラミング言語の各タイプを学ぶ
私は、すべてのプログラマーがそれぞれのタイプの言語の1つを学ぶべきだと何度か聞いたことがあります。今、これは必ずしも真実ではありませんが、私はそれが良い考えだと思います。 手続き言語(Perl)を学びましたが、他のタイプは何ですか? それらの違いは何ですか、それぞれの例は何ですか?

5
関数型プログラミングがよく合わない一般的な問題は何ですか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 関数型プログラミングは宣言的なパラダイムです。FPの長所の1つは、副作用が回避されることです。いくつかの問題では、FPは適切ではないと言われています。 関数型プログラミングが適合しない一般的な問題は何ですか?

11
OOPは実世界で支配的なプログラミングモデルですか?
オブジェクトはありませんか?まあ、ほとんどこれまで ACMのコミュニケーションのVIEWPOINTセクションで、「Objects Never?Well、Hardly Ever」という興味深い記事を見つけました。これは、オブジェクトファーストまたはオブジェクトレイトとは根本的に異なる視点です。彼は「オブジェクト-決して」または多分「オブジェクト-大学院」を提案します。 著者はOOPについて話し、OOPが実際のプログラミング環境でどのように使用されるかについて質問しました。彼は、OOPは支配的なプログラミングモデルではないと考えています。たとえば、プログラミングの70%は、OOPがあまり適していない組み込みシステム向けに行われていると彼は言います。 大学の一部の教授は、OOPの利点について話したい場合、コードの再利用について話します。別の例として、再び、彼は、これは現実世界の実際のケースではない、と主張します。コードの再利用は大学で主張されているものよりも難しい: OOPの使用は、ほとんどの人が信じているほど普及しておらず、支持者が主張するほど成功していないため、CSカリキュラムの中心的な位置は正当化されないと主張します。 スタックオーバーフローの人々がこれについてどのように考えているかを知るのは興味深いですか?OOPは、プログラマーの観点から見れば、主要なプログラミングモデルですか? アプローチを1つだけ選択/学習/使用する必要がある場合、それはOOPですか?どうして?

6
JavascriptでUIを100%実行し、APIを介してデータを提供することをお勧めしますか?
私の主な仕事はHTMLアプリケーションの作成です。それは、編集可能なグリッドビュー、テキストボックス、ドロップダウンなど、多くの内部でCRUDタイプのアプリケーションを内部で使用することを意味します。現在、ASP.NET Webフォームを使用しています。あなたが必要なものを得るためにフープを飛び越えなければなりません。天井から垂れ下がって炎を放つフープ。 だから、すべてのUIをJavaScript側に移動することはおそらく良い考えだろうかと思っています。特にニーズに合わせて調整された強力な再利用可能なコントロールを開発し、サーバーとのみデータを交換します。はい、私は「コントロール」(別名「ウィジェット」)パラダイムが好きで、そのようなアプリケーションに非常に適しています。したがって、サーバー側では、現在のASPXマークアップと同様の基本的なレイアウトがまだありますが、クライアントに送信されるのは1回だけであり、Javascript部分が後続のすべてのUI更新を処理します。 問題は、私がこれをやったことがなく、誰もこれをしているのを見たことがないので、問題がどうなるかわかりません。特に、私は心配しています: まだパフォーマンス。ベンチマークでは、現在、ブラウザがAJAX更新後にページのほとんどを再レンダリングしようとするときに、主な遅延がクライアント側にあることが示されています。ASP.NET webformsで生成されたマークアップは、「web」という言葉に新しい意味を与えます。また、豊富なDevexpressコントロールは、その上に独自のJavascript複雑さのレイヤーを追加します。しかし、JavaScript側で必要なすべての変更を再計算し、更新する必要があるものだけを更新する方が速いでしょうか?いくつかの編集可能なグリッドビュー、多数のテキストボックス、それぞれに50万個のフィルター可能なアイテムが含まれるドロップダウンなどがあるフォームについて話していることに注意してください。 開発のしやすさ。Javascriptはもっと多くなり、おそらくページのHTMLマークアップと混ざります。それまたは何らかの種類の新しいビューエンジンを作成する必要があります。JavascriptのIntellisenseはC#コードよりもはるかに悪く、Javascriptの動的な性質のため、はるかに良くなることは期待できません。コーディングの慣行により少し改善できますが、それほど改善することはできません。また、ほとんどの開発者は主にC#開発者であるため、ある程度の学習曲線と最初の間違いがあります。 セキュリティ。多くのセキュリティチェックを2回(サーバー側とUI側)行う必要があり、データ処理サーバー側にはさらに多くのチェックを含める必要があります。現在、サーバー側でテキストボックスを読み取り専用に設定した場合、その値がクライアントのラウンドトリップを通じて変わらないことに依存できます。フレームワークには、それを保証するのに十分なコードが既にあります(ビューステートの暗号化により)。データのみのアプローチでは、すべてを手動で確認する必要があるため、難しくなります。一方、心配する必要があるのはデータだけなので、セキュリティホールを見つけるのは簡単です。 全体として、これは問題を解決するのか、それとも悪化させるのか?誰かがこれを試みたことがありますか?その結果はどうでしたか?この種の取り組みに役立つフレームワークはありますか(jQueryと道徳的な同等物は別として)?

7
どのような問題に対して、オブジェクト指向プログラミングは良い選択ではありませんか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 この質問にある程度触発されました:関数型プログラミングはどのような一般的な問題に適していませんか?-しかし、それでも私はいつも欲しかった質問ですが、尋ねるのは怖すぎました。 私は... でした。まあ、それは工学ソフトウェア開発とほぼ一生涯呼んでいます。その間ずっと、オブジェクト指向は常に存在していましたが(ほとんどの場合)、使用する必要はありませんでした「その方法」、またはそのパラダイムを学ぶこと。私たちは常にかなり単純なプログラム構造、ルーチン/関数/モジュールを使用してきましたが、それらのプログラムを管理する今日のベストプラクティスとは反対ですが(約300k LOCまでのプログラム、大きすぎない)、決して難しいことはありませんでした。 それで、私はあなたに尋ねたいと思いました、どのオブジェクト指向パラダイムは良い選択ではないでしょうか?手続き型プログラミングと比較して?
19 paradigms 

5
アスペクト指向プログラミング以外のクロスカッティングの懸念には、どのような選択肢がありますか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 アスペクト指向プログラミングは横断的な関心事に対処することを約束しますが、私はまだ完全に売り切れていません。この問題に対処する他の試みはありましたか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.