选择编程范例来解决问题的经验证据

C2 Wiki讨论了面向对象编程的经验证据，该结论基本上得出结论，没有什么可以超越权威。这是在2008年最后一次编辑。这里的讨论似乎可以证明这一点：关于OO是否过时的问题，当函数编程是一个错误的选择，并且AOP的优缺点都可以由贡献者的意见来回答，而无需依赖证据。

当然，欢迎既有知名的从业人员的见解，也可以提供有价值的东西，但是当它们与实验数据一致时，它们似乎更加合理。这个证据存在吗？我知道基于证据的软件工程是一回事，但是我可以在这种情况下实践吗？具体来说，如果我有一个P想通过编写软件来解决的特定问题，是否存在大量的知识，研究和研究，这些知识，研究和研究会让我看到解决问题的结果如何P取决于编程范例的选择？

我知道哪种范式作为“正确答案”可以取决于特定研究关注的指标，研究保持不变或变化的条件，以及其他因素。这不会影响我寻找此信息并进行严格评估的愿望。

显而易见，有些人认为我正在寻找“曲柄”解决方案-某些香肠机将我的问题信息放入其中，而其中出现了“功能”或“结构化”之类的词。这不是我的意图。我正在寻找的是如何进行研究-尽管有很多警告和假设，但我不会在这里讨论，但是有很多关于此事的文献会-有关软件的某些属性的变化取决于问题和选择的范式。

换句话说：有人说“ OO可以提供更好的灵活性”或“功能程序的bug更少” –我要的（部分）证据就是这一点。其余人则要求提供证据证明这一点，或者要求这些假设正确的假设，或者表明这些考虑并不重要的证据。关于为什么一种范例比另一种范例更好的观点有很多。这些背后有什么目标吗？

对于以前的拍摄，请参阅此答案的修订版1。但是，对该问题的评论和编辑进一步阐明了该问题在寻找什么，并使我更加清楚。

是的，基于证据的软件工程（EBSE）是一回事。似乎在EBSE数据库方面做出了一些努力，例如达勒姆大学（Durham University）和SEED的这一工作是由Cal Poly的一位教授发起的。所有这些努力，以及通过IEEE Xplore服务器或ACM数字图书馆可以找到的许多论文中讨论的努力（两种论文均需要订阅或购买）均基于循证医学。他们提供了已发表的经验（观察和实验）数据的文献综述。实际上，在任何出版物搜索的搜索字符串中包含“文学评论”都会产生有关大多数主题的信息-ACM上的点击次数超过14000，IEEE数据库上的点击次数超过1000（仅限于计算主题）。

通过查看这些EBSE数据库和文献评论中讨论的主题的一般类型，我看到了一个共同的话题-它们往往与技术无关。重点似乎主要围绕流程和方法论，而不是用于进行软件工程的特定工具。

因此，这个概念存在于软件工程中。学术界了解基于证据的概念，并将其成功地应用于软件工程。

具体而言，由于涉及的变量数量众多，因此要解决的问题是将EBSE技术应用于范式的选择似乎很困难，这迫使人们做出假设，并降低了重复实验或观察的能力。在这个问题上说对了：“哪种范式作为“正确答案”出来可以取决于特定研究关注的指标，研究保持不变或变化的条件，并且毫无疑问也取决于其他因素”。尽管这并不意味着研究在给定情况下哪种范例是“最佳”的，但是这使得对这些文档进行任何形式的文献综述都极其困难，并且仍然难以从中提取信息。

绝对没有选择范式的“曲柄”解决方案。

在给定编程范例的情况下，您可以在各种学术和行业数据库中找到有关该范例如何在各种特定条件下影响软件开发各个方面（质量，缺陷，效率等）的研究，范围包括软件开发人员的知识和经验。团队到问题领域。任何严格的文件都应明确指出收集数据的条件和假设。问题变成试图找出在每种情况下都使其变得良好的因素。

在学术上，有些陈述易于研究。例如，功能范式非常适合需要并发的应用的说法源于Church-Rosser定理。因此，用功能语言编写的软件系统与并发相关的缺陷可能要比用过程语言或面向对象的语言编写的软件系统少。

但是，从实际的角度来看，软件团队不能总是仅根据研究表明使用“最佳”工具或技术来完成这项工作。尽管我们努力生产最高质量的软件系统，但我们确实在限制条件下运行。通常，在讨论任何方法的有效性时，我都会看到这些约束已最小化（甚至从等式中消除了）。

作为一名从业者，当我参与选择要使用的技术时，我会尝试找出最好的工具。但是随后，我将自己局限于自己的团队所了解和理解的东西。回到我之前的示例，如果我有一个精通C ++并发应用程序构建团队并且没有Haskell经验，建议在Haskell中构建系统是没有意义的，因为我很可能无法进度和预算限制，由于缺乏工具链方面的经验，我的素质可能会受到影响。

回顾一下，基于证据的软件工程通常是一件好事，而且文献评论确实存在并且很容易获得。但是，在软件工程的某些方面，应用基于证据的方法几乎没有价值。为大规模开发工作选择编程范例就是其中之一。

如果您想了解面向对象如何解决功能性编程中的可重用性或缺陷-您将很容易找到有关这些内容的出版物。但是，我没有找到（也不会给予任何信任）能够有效解决各种实际软件工程项目中范式选择问题的出版物。

我一直在阅读Eric S. Raymond 撰写的Unix编程艺术。对于我们现在认为理所当然的事情，它具有一些非常有趣的历史见解。他引用了IEEE软件的一些很好的研究，这些研究使用了诸如缺陷密度之类的经验证据。如果您正在寻找学术风格的研究，那可能是一个很好的来源。

甚至诸如使用功能进行模块化的技术也并非总是惯例。到目前为止，这本书是我最喜欢的名言之一：

丹尼斯·里奇（Dennis Ritchie）通过告诉所有人和杂项，告诉人们函数调用在C语言中确实非常便宜，从而鼓励了模块化。每个人都开始编写小型函数并进行模块化。多年后，我们发现在PDP-11上函数调用仍然很昂贵，并且VAX代码通常将其时间的50％花费在CALLS指令上。丹尼斯对我们撒谎！但为时已晚了; 我们都迷上了...

-史蒂夫·约翰逊（Steve Johnson）

但是，过于经验化确实存在两个问题。首先是代码质量是非常主观的。代码可能很糟糕，但仍然正确。人们对编程范例的理解是一个非常有效的度量标准，因为编写的代码供人们阅读，与供计算机阅读一样多，甚至更多。

第二个问题是50％的开发人员的编程天赋低于平均水平。如果您的顶级开发人员使用函数式程序编写程序时生产力提高，那么如果“小伙子” 用它来努力编写有效的软件，更不用说漂亮，结构良好的软件了，这无关紧要。与TMTOWTDI编程语言类似，您的顶级开发人员仍将编写干净的模块化代码，但由于缺乏强制性的结构，才华横溢的编码人员会编写行噪声。

这就是为什么我认为OOP尽管有不足之处，却已上升到最受欢迎的位置。它并没有那么严格，以至于阻碍了最有才华的人，但是它的结构提供了一种简洁的方式来交流和将最优秀的设计原则强加给最不才华的人。

在我们的工作中，我们倾向于仅根据技术优点来评估解决方案。成功的努力还必须考虑到方程式的人性方面。

有一些使用计算机评分系统的编程比赛，可以让您用多种语言编写文章并发布各种结果和事物。我敢打赌他们有适合您的数据。以下是8个列表：http : //www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

我想您可以对非常简单明了的问题（例如平方和或斐波那契数列）的解决方案进行有意义的比较，或者使用布雷森汉姆的直线算法绘制一条直线。大多数现实世界中的编程任务都没有明确的目标职位，每种语言都有其优点。语言的大部分好处是主观的。通过调查程序员和客户的满意度，您可能会发现比计数代码行或缺陷数更有意义的数据。

我记得当我花了半天时间写我的第一个Awk程序之一时，我认为花了整整一个星期的时间来用Java做“相同”的事情。但这是因为我的Java解决方案本来会专注于健壮性，因为Awk解决方案既快速又肮脏，并且需要对输入和输出进行一些手动调整，并且在完成后真的被丢弃了。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 ，希望对您有所帮助...

似乎在许多情况下，没有足够大的研究或足够高质量的研究来得出关于软件工程的一种实践是否比另一种实践更好的一般结论。我一直在寻找针对不同范式工作的研究，但是缺乏可用性不仅仅限于那个领域，所以我将在更广泛的意义上阐述我的答案。

Kitchenham等人于2004年发表的一篇论文《基于证据的软件工程》非常简洁地介绍了基于证据的方法所带来的好处以及在软件工程中实现该方法所遇到的问题。我不会在这里讨论收益方面（从问题上很明显，我希望能够以这种方式工作），但是这些问题与我所提出问题的答案相关。

• 首先，如果您不是ACM的成员，那么您可能根本看不懂上面的链接，这涵盖了第一个问题：并非所有现有研究实际上都可供从业人员使用。
• 作为商业机密流程的一部分，许多软件工程实践都是秘密进行的，因此无法了解对这些人有效或无效的工作。
• 软件工程是一种熟练的实践，因此很难（不是不可能，只是很难）安排适当的研究。
• 软件生命周期的不同部分会在每个实验中都难以控制的程度上影响彼此的结果。
• 正如此处讨论所证明的，许多从业人员并不认为“文献”（或软件工程的学术方面）与他们的工作相关。

因此，我追求的答案是“否”，我正在寻找的证据可能不存在。我应该根据我所知道的，流行的和专家意见的现有流行标准来选择我的范例。

我不认为这种研究存在。人们会相信，与所使用的实际算法一样重要的不是编程范例。例如，给定任何依赖于小空间算法的非平凡系统，而依赖于小时间算法的系统将生成不同的度量。时间更好的那一台机极有可能被认为更有效，除非空间成为问题，然后反之成立。我发现它类似于铺路。尽管在所有过程中用于制造材料的算法或配方都是恒定的，但有可能一家公司认为一次在道路的同一侧铺两个车道（在道路的两侧）比在道路的同一侧铺两个车道更好。 。归根结底，这并不重要，因为制作黑色顶部的过程仍然相同，唯一的区别是方法。回到编程，如果您有一组C开发人员，请以过程方式编写代码，如果您有一组Java开发人员以OO编写代码。不要像执行算法那样挂在范式上。因为在一天结束时，您可以像C一样编写Java，并且可以尝试像Java一样编写C。

更新

要回复格雷厄姆的评论，我离开了：
我认为通过体系结构，您的意思是编程范例。如果您打算使用Clojure，也许您应该雇用一组Clojure程序员。但是，基于快速搜索，Clojure是一种基于Java的语言，因此恰好可以起作用。鉴于这些信息，我将聘请Java程序员（因为从技术上讲，他们只能编写Java，并且会给您相同的结果），或者寻找功能程序员，例如Haskell开发人员。现在，选择最佳方案完全取决于您的团队。我永远不会有一个关系数据库专家团队为我组织云解决方案，也永远不会有一个功能程序员团队为我构建面向对象的解决方案。您必须利用团队的实力，而不是脑海中拥有荣耀的愿景来应对团队“应该”做什么

不同的范式导致不同的解决方案。哪种“最佳”匹配很大程度上取决于：

• 解决方案
• 开发团队
• 运作环境

我知道没有这样的确定性研究，即使有一项我也不相信。

那是建筑师的工作。

用可能无关紧要的结论代替建筑师的智慧是灾难的根源。

注意：评论中提到先确定“算法”，然后选择语言。算法是过程语言的主要结构机制。面向对象的语言集中于协作/通信的类和模式。如果您（作为架构师）确信以算法为中心的解决方案是“最佳”的，那么请坚持使用过程或功能语言。

附录：不信任研究不是“迷信”，这是常识。科学实验必须客观且可重复。软件项目是高度主观的，但更糟糕的是，它们是无法重复的实验。您根本无法与团队Y一起实施项目X，无法测量结果，然后回滚时间，擦除内存并与同一团队重新执行相同的项目。研究发现或暗示的信息可能对架构师有用，但永远无法确定。