問題に対処するためのプログラミングパラダイムの選択に関する経験的証拠

C2 wikiには、オブジェクト指向プログラミングの経験的証拠に関する議論があり、基本的には、権威への訴求以上のものはないと結論付けています。これは、ここでは、2008年の議論で最後に編集されたこのアウトを負担するようです：上の質問OOが古いされているかどうか、関数型プログラミングは悪い選択であるときとAOPの利点と欠点がすべての証拠に頼ることなく、貢献者の意見に答えています。

もちろん、定評のある有名な開業医の意見は歓迎すべきものであり、貴重なものですが、実験データと矛盾しない場合はより妥当です。この証拠は存在しますか？証拠に基づいたソフトウェアエンジニアリングが重要であることは知っていますが、この文脈で実践できますか？具体的には、Pソフトウェアを書くことで解決したい特定の問題がある場合、Pプログラミングパラダイムの選択に依存するような問題解決の結果がどのように決まるかを知ることができる知識、研究、研究がありますか？

「正しい答え」としてどのパラダイムが出てくるかは、特定の研究が注意を払うメトリックス、研究が一定または変動する条件、そして疑いなく他の要因に依存することを知っています。これは、この情報を見つけて批判的に評価したいという私の願望には影響しません。

私は「クランクを回す」ソリューションを探していると考える人がいることが明らかになります-私の問題に関する情報を入れ、その中から「機能的」または「構造化」のような言葉が出てくるソーセージマシンです。これは私の意図ではありません。私が探しているのは、方法についての研究です-ここには入りませんが、問題に関する良い文献がありますが、多くの警告と仮定があります-ソフトウェアの特定の特性は、問題とパラダイムの選択によって異なります。

言い換えれば、「OOの方が柔軟性が高い」または「機能プログラムのバグが少ない」と言う人もいます-（一部）私が求めているのはこの証拠です。残りは、これに対する証拠、またはこれらの記述が真であるという仮定、またはこれらの考慮事項が重要ではないことを示す証拠を求めています。あるパラダイムが他のパラダイムよりも優れている理由については、多くの意見があります。これらの背後にある目的はありますか？

前のテイクについては、この回答のリビジョン1を参照してください。ただし、質問に対するコメントと編集により、質問が求めているものがさらに明確になり、より明確になります。

はい、証拠ベースのソフトウェアエンジニアリング（EBSE）は重要です。ダーラム大学でのこれや、Cal Polyの教授によって始められたSEEDなど、EBSEデータベースへの取り組みがいくつかあるようです。これらのすべての努力と、IEEE XploreサーバーまたはACM Digital Libraryを通じて入手できる多数の論文で議論されているもの（両方の多くの論文に登録または購入が必要）、証拠に基づいた医学に基づいています。彼らは公開された経験的（観察と実験）データの文献レビューを提供します。実際、出版物検索の検索文字列に「文学レビュー」を含めると、ほとんどのトピックに関する情報が得られます-ACMで14000ヒット、IEEEデータベースで1000ヒット（コンピューティングトピックのみに限定）。

これらのEBSEデータベースと文献レビューで説明されているトピックの一般的なタイプを見ると、共通のスレッドがあります。これらはテクノロジーに依存しない傾向があります。ソフトウェアエンジニアリングの実施に使用される特定のツールではなく、プロセスと方法論に重点を置いているようです。

したがって、この概念はソフトウェアエンジニアリングに存在します。アカデミアはエビデンスに基づいた概念を認識しており、ソフトウェアエンジニアリングにうまく適用できます。

具体的には、EBSE手法をパラダイムの選択に適用するという質問は、膨大な数の変数が関係するため困難であるように思われ、仮定を強制し、実験または観察を繰り返す能力を低下させます。「正しい答えとして出てくるパラダイムは、特定の研究がどの指標に注意を払うか、研究が一定または変動する条件に依存し、他の要因にも疑いの余地はない」という質問で正しいと言われています。それは、どのパラダイムが特定の状況で「最良」であるかを研究することを意味するものではありませんが、これらの文書のあらゆる種類の文献レビューを完了し、それら全体の情報を抽出することは非常に困難です。

パラダイムを選択するための「クランクを回す」ソリューションは絶対にありません。

プログラミングパラダイムが与えられると、そのパラダイムがソフトウェア開発のさまざまな側面（品質、欠陥、効率など）にどのように影響するかについて、さまざまな学術データベースおよび業界データベースで調査を見つけることができます。チームを問題の領域に結び付けます。厳密な文書は、データが収集された条件と仮定を明確に識別する必要があります。問題は、これらの各条件でそれを良くする要因を分離しようとするようになります。

学術的には、調査しやすいステートメントがいくつかあります。たとえば、関数型パラダイムは、並行性を必要とするアプリケーションに適しているという声明は、チャーチ・ロッサーの定理に由来しています。このため、関数型言語で記述されたソフトウェアシステムは、手続き型言語またはオブジェクト指向言語で記述された同じシステムよりも、並行性に関連する欠陥が少ない可能性があります。

ただし、実用的な観点から、ソフトウェアチームは、研究がそれを示しているという理由だけで、仕事に常に「最高の」ツールまたは手法を使用できるとは限りません。私たちは最高品質のソフトウェアシステムの生産に努めていますが、制約の範囲内で業務を行っています。多くの場合、方法論の有効性を議論するとき、これらの制約は最小化されます（または方程式から削除されます）。

開業医として、使用するテクノロジーの選択に携わっているとき、私は可能な限り最良のツールを特定しようとします。しかし、それから私は、自分が持っているチームによって知られ、よく理解されていることに自分自身を制約します。前の例に戻って、C ++で並行アプリケーションを構築することに精通したチームがいて、Haskellでの経験がない場合、Haskellでシステムを構築することを提案するのは意味がありません。スケジュールと予算の制約があり、ツールチェーンの経験が不足しているため、私の品質が低下する可能性があります。

要約すると、エビデンスに基づいたソフトウェアエンジニアリングは一般に存在する良いものであり、文献レビューは存在し、すぐに利用できます。ただし、証拠に基づいたアプローチを適用してもほとんど価値がないソフトウェアエンジニアリングの側面があります。大規模な開発努力に対するプログラミングパラダイムの選択は、これらの1つです。

オブジェクト指向が関数型プログラミングの再利用性や欠陥にどのように対処しているかを知りたい場合は、それらに関する出版物を簡単に見つけることができます。しかし、実際のソフトウェアエンジニアリングプロジェクトの広範囲にわたるパラダイムの選択に効果的に対処できる出版物を見つけませんでした（また、私は信頼しません）。

エリック・S・レイモンド著「The Art of Unix Programming」を読んでいます。現在、当たり前のことについて非常に興味深い歴史的洞察があります。彼は、欠陥密度のような経験的証拠を使用するIEEEソフトウェアの優れた研究を引用しています。学術スタイルの研究を探しているなら、それは良い情報源かもしれません。

関数を使用したモジュール化などの手法でさえ、常に一般的な方法ではありませんでした。これまでの本からの私のお気に入りの引用の一つ：

Dennis Ritchieは、Cで関数呼び出しが本当に非常に安価であるとすべての人に伝えることでモジュール性を奨励しました。誰もが小さな関数を書き、モジュール化するようになりました。数年後、PDP-11では関数呼び出しが依然として高価であり、VAXコードは多くの場合、その時間の50％をCALLS命令で費やしていることがわかりました。デニスは私たちに嘘をついていた！しかし、手遅れでした。夢中になった...

-スティーブジョンソン

ただし、経験的になりすぎると、実際には2つの問題が生じます。1つ目は、コードの品質は非常に主観的なものであることです。コードはひどい場合がありますが、それでも正しい場合があります。プログラミングパラダイムに対する人々の認識は非常に有効な測定基準です。なぜなら、コードは人々がコンピューター以上に読めるように書かれているからです。

2番目の問題は、開発者の50％が平均以下のプログラミング才能を持っていることです。美しく、よく設計されたソフトウェアは言うまでもなく、「瓦ble」がそれを使用して動作するソフトウェアを書くのに苦労するなら、トップ開発者が関数型プログラミングを使用して生産性を高めてもかまいません。同様に、TMTOWTDIプログラミング言語でも、トップ開発者はクリーンでモジュール化されたコードを記述しますが、構造が不足しているため、才能の低いコーダーは回線ノイズを記述します。

だからこそ、OOPはその欠陥にもかかわらず人気でトップになったと思います。それは、最も才能のある人をつまむほど制限的ではありませんが、その構造は、才能の低い人に良いデザイン原則を伝え、課す簡潔な方法を提供します。

私たちの仕事では、技術的なメリットだけに基づいてソリューションを評価する傾向があります。成功するためには、方程式の人間的な側面も考慮する必要があります。

コンピューターグレーディングシステムを使用して、さまざまな言語で記述し、あらゆる種類の結果やものを投稿できるプログラミングコンテストがあります。彼らはあなたのために良いデータを持っているに違いない。ここに8のリストがあります：http : //www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

二乗和やフィボナッチ数列、またはブレゼンハムの線アルゴリズムを使用して直線を描くなど、非常に単純で明確な問題の解決策を意味のある比較ができると思います。ほとんどの実際のプログラミングタスクには、このような明確な目標の投稿がなく、すべての言語にスイートスポットがあります。言語の利点の多くは主観的です。コードの行数や欠陥の数を数えるよりも、プログラマーとクライアントの幸福度を調査することで、より意味のあるデータを見つけることができます。

私が最初のAwkプログラムの1つを書くのに半日費やしたとき、Javaで「同じ」ことをするのに1週間かかると思いました。しかしそれは、Awkソリューションが迅速で汚れていて、入力と出力を手動で微調整する必要があり、作業が終わったときに本当に捨てられていたため、私のJavaソリューションは堅牢であることに焦点を当てていたからです。AwkとJavaはどちらも優れており、同じことをするわけではありません。

私が言っていることは、実世界のアプリケーションでは、意味のある方法で言語やツールを比較することは非常に難しいということです。古いリンゴとオレンジの問題です。幸運を！私はあなたが見つけたものを見てみたいです。

私は30年以上にわたってソフトウェアを開発するさまざまな方法を研究してきました。パラダイムの選択に関して、公表されている優れた証拠は不足しています。

検索可能な大規模なASCII参考文献をまとめました。これには、IEEEおよびACMの多くの論文と記事が含まれます。提供された証拠の種類でアイテムにタグを付けます。最も一般的なタグは次のとおりです。

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

PARADIGMを検索して、タグを数えます

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

さらに深く掘り下げたい場合は、http：//cse.csusb.edu/dick/lab.htmlをご覧ください 。

多くの場合、ソフトウェア工学のある実践が他の実践よりも優れているかどうかについて一般的な結論を引き出すことができるほど十分に大きな研究や高品質の研究のコーパスはないようです。さまざまなパラダイムでの作業に関する研究を特に探していましたが、可用性の欠如はその分野に限定されないため、より広い意味で答えを組み立てます。

2004年のKitchenhamらによるEvidence-Based Software Engineeringの論文は、エビデンスに基づくアプローチから得られる利点と、それをソフトウェアエンジニアリングに実装する際の問題を非常に簡潔に扱っています。ここではメリットの側面については説明しませんが（この方法で仕事をしたいという質問からは明らかです）、問題は私が尋ねた質問への回答として関連しています。

• まず、ACMのメンバーでない場合は、おそらく上記のリンクをまったく読むことができません。これは、最初の問題をカバーしています。実務者が実際の研究のすべてを利用できるわけではありません。
• 多くのソフトウェアエンジニアリングの実践は、機密情報のプロセスの一部として秘密裏に行われているため、それらの人々にとって何が機能したか、または機能しなかったのかがわかりません。
• ソフトウェアエンジニアリングは熟練した実践であるため、適切に盲検化された研究を準備することは困難です（不可能ではなく、単に困難です）。
• ソフトウェアライフサイクルのさまざまな部分は、他の実験で制御するのが難しい程度に互いの結果に影響します。
• ここでの議論から明らかなように、多くの実務家は「文献」（または一般的なソフトウェア工学の学術的側面）を自分の仕事に関連しているとは考えていません。

したがって、私が求めている答えは「いいえ」です。探している証拠はおそらく存在しません。私が知っていること、クールで専門家の意見の既存の一般的な基準に基づいて私のパラダイムを選択する必要があります。

この種の研究が存在するとは思わない。使用される実際のアルゴリズムほど重要なのは、プログラミングのパラダイムではないと考えられます。たとえば、小さなスペースのアルゴリズムに依存する自明でないシステムと、小さな時間のアルゴリズムに依存するシステムでは、異なるメトリックが生成されます。より良い時間を持っているものは、スペースが問題であり、逆が真でない限り、より有効であると考えられるでしょう。道路を舗装するのと似ています。材料を作成するためのアルゴリズムまたはレシピはすべてのプロセスを通して一定ですが、ある会社は、2つの車線を一度に舗装する（道路の両側に1つずつ）ことは、道路の同じ側に2車線を舗装するよりも良いと考える可能性があります。結局のところ、黒のトップを作るプロセスは同じままなので問題ではありません。唯一の違いはアプローチです。プログラミングに戻ります。C開発者のチームがいる場合は、Java開発者のチームがOOで記述している場合は、手順に従ってコードを記述します。アルゴリズムの実装ほどパラダイムにこだわらないでください。結局のところ、CのようなJavaを書くことができ、JavaのようなCを書くことができるからです。

更新

コメントに返信するために、グラハムは私を残しました：
アーキテクチャとはプログラミングのパラダイムを意味すると思います。Clojureを使用する場合は、Clojureプログラマーのチームを雇う必要があります。ただし、簡単な検索に基づいて、ClojureはJavaベースの言語であるため、偶然機能します。その情報があれば、Javaプログラマー（技術的にはJavaを書くだけで同じ結果が得られるため）を取るか、Haskell開発者などの機能的なプログラマーを探します。最適なものを選択するという点では、チームに完全に依存しています。リレーショナルデータベースの専門家のチームが私のためにクラウドソリューションを編成することも、機能プログラマのチームが私のためにオブジェクト指向ソリューションを構築することもありません。あなたは、チームが「すべき」ことに対して、頭にある栄光のビジョンを持っていないチームの強みを使わなければなりません。

さまざまなパラダイムがさまざまなソリューションにつながります。どの適合が「最良」であるかは、主に以下に依存します。

• ソリューション
• 開発チーム
• 運用環境

私はそのような決定的な研究を知りませんし、たとえそれがあったとしても私はそれを信用しません。

それが建築家の仕事です。

建築家の知恵を研究のおそらく無関係な結論に置き換えることは、災害のレシピです。

注：コメントには、「アルゴリズム」を決定してから言語を選択することが記載されています。アルゴリズムは、手続き型言語の中心的な構造メカニズムです。オブジェクト指向言語は、コラボレーション/コミュニケーションのクラスとパターンに焦点を当てています。（アーキテクトとして）アルゴリズム中心のソリューションが「最良」であると確信している場合は、手続き型言語または関数型言語を使用してください。

補遺：研究を信頼しないことは「迷信」ではなく、常識です。科学実験は客観的で再現可能でなければなりません。ソフトウェアプロジェクトは非常に主観的ですが、さらに悪いことに、再現性のない実験です。チームYでプロジェクトXを実装し、結果を測定してから、時間をロールバックし、記憶を消去し、同じチームで同じプロジェクトをやり直すことはできません。研究によって発見または暗示された情報は、建築家にとって有用かもしれませんが、決定的なものになることはありません。