说服高层管理人员考虑使用函数式编程，有什么好的事实依据？[关闭]

对于为什么函数式编程是一个好主意，有大量的“理论”论证（要解决一个开放的问题，太多了，这是正确的）。

但是，大多数都是基于理论（“优雅”等）或针对开发人员的论证。

问题是，当他们的目标是向大公司的高级管理层介绍这个想法时，大多数人完全没有用，其中一些人甚至都不是开发人员，而所有人都在乎业务论点：成本，人力资本管理，产品交付，客户服务和收入；以及理论上无法完全支持的定量事实。

就考虑将功能性编程作为一种概念（不是任何特定的语言）进行考虑，相对于过程/ OOP的典型组合，例如Java / C ++ /（Perl | Python），是否有任何令人信服的论点可以解决这些业务问题？。

最好是，我正在寻找定量的和/或基于研究或案例研究的论据。例如，“根据此参考，Lisp / F＃中的多线程系统的错误率是Java的10％”或“ 80％的顶尖毕业生表示对期望的技术（称为函数式编程）的偏爱是前三大兴趣之一”。

我知道Graham提出了函数式编程的用例以备不时之需，并假设他的某些论点对较大的成熟公司有效，对此他持开放态度。

_{psI完全意识到，您可以在Perl中完成类似于函数式编程的工作，可能是Python，甚至（甚至）Java 8或C ++14。但是，这并不意味着使用Perl，C ++或Java的组织会认可函数vs即使是那些语言中的OOP /过程方法}

_{就此语言而言，“大”定义为足以拥有专门的开发工程/工具组的大小，该组指示允许所有开发人员使用/执行的操作；至少有数百名低端开发者}。

有一个非常简单的论点，至少可以使管理层感到有趣。

众所周知，现代计算机并没有像以前那样变得“更快”，因为目前频率缩放已达到极限。他们通过添加核心来提高潜在的生产力。

这意味着要从该体系结构中受益最多，必须对程序进行并行化。但是并行编程比顺序编程要困难得多，因为它带来了许多新的挑战（有关全面概述，请参阅Wiki文章）。

函数式编程有助于摆脱其中的一些挑战，例如，如果仅使用不可变的变量和方法而没有副作用，则竞争条件将不适用。函数式编程的学习曲线通常很陡峭，但是并行编程的学习曲线可能更陡峭，而且一点也不直观。

因此，如果挑战在于以更有效的方式编写更高效的程序，则可以将培训人员编写并行程序的成本与培训人员学习功能编程的成本进行比较，这两种方法都可能带来风险。

关于混合语言（同时支持功能性和命令式编程风格）：从某一角度来看，它们可能会很方便地过渡（人们可能开始以“熟悉”的方式使用它们并逐渐学习新的方法）。从另一个角度来看，这可能是一种变相的祝福，因为函数式编程带来的潜在优势可能会因为某人的笨拙代码而被抵消。可以通过建立明确的编码准则（例如，参见Twitter的“ Effective Scala ”）来减轻这种情况，尽管遵循准则需要一定程度的团队成熟度。从这个角度来看，纯功能语言对于软件开发可能是“更轻松”的，因为它们是由设计强加的严格规则。

您正在从错误的方向进行处理。在大多数公司中，管理层不负责“选择编程范式”，而是（至少应该负责）使团队高效工作。如果您的整个团队都相信函数式编程可以提高您的工作速度或质量，那么说服管理人员也不会太困难。此外，如果您的团队刚刚开始使用您已建立的编程语言来使用功能构造，并且每个人都对此感到满意，那么您甚至不必寻求许可（哎呀，非程序员可能甚至不了解非编程语言之间的区别）。功能和功能结构，为什么您要与他讨论这个问题？）。

但是请注意，如果您团队的其他成员对FP有不同的看法，并且他们开始抱怨其他团队成员不理解的您的功能代码，则您可能会遇到管理方面的麻烦-有充分的理由，因为在这种情况下，情况下，团队会失去效率。

因此，要旨是：说服其他团队成员或您的团队负责人，但不要说服高层管理人员！

编辑：由于您的评论-实际上，这是您问题的答案;-)。我谈论的一个事实论据是“整个团队都认为FP对完成这项工作很有帮助。恕我直言，这是高层管理人员接受蜜蜂的机会最高的论据，并且在实践中非常适用。尝试使用技术论据非技术人员很少直接工作，不是因为他们“太愚蠢而无法理解技术推理”，而是因为他们足够聪明，知道应该由技术专家做出技术决策，并且他们也足够聪明，不依赖仅根据一位专家的意见。

要了解为什么函数式编程尚未普及，您必须了解编程语言决策背后的公司思想。暂时选择Java：

1. 有大量的程序员可以编写大量的普通Java代码。对于Lisp或Haskell（甚至Scala）程序员而言，情况并非如此。
2. 其他人都在使用Java，所以它一定很好。烦人的：管理人员不必为选择Java辩护，而不必使用命令结构中从未听说过的晦涩的语言。

如果您的组织已经扎根于名词王国，那么根本不会对函数式编程进行全面更改。语言选择（以及围绕它的所有其他选择）已经深深植根于企业文化中。

假设您的目标是成为一名软件开发人员，那么最好的选择是

1. 将功能性概念合并到您现有的程序中，使它们有用且适当，
2. 使用新的功能性语言功能，因为它们已添加到语言中，并且
3. 学习面向对象的设计模式，为了克服面向对象的设计模式，这些模式可以克服功能语言中不存在的OO语言中的语言缺陷。

保罗·格雷厄姆（Paul Graham）的论点实际上仅适用于初创公司，并且有很多关于公司开始使用纯功能语言的告诫故事，但后来又被另一家公司收购，该公司的首要业务是立即转换功能代码库OO语言，以便他们现有的软件开发人员可以理解它。

根据我的经验（有点愤世嫉俗），曾在一家我们使用函数式编程的商店工作过，并接受了其他几篇采访：

1. 总会有一位CTO和其他高级技术人员具有函数式编程的经验，并且设法说服了非技术人员。（顺便说一下，这些人比我更有资格回答您的问题。）
2. 一旦这些人离开公司，并被没有这种意愿的人所取代，事情就会朝南走。新手会把所有出错的地方（包括，尤其是自己的失败）归咎于用于构建以前版本的怪异编程语言和范例。他们将利用功能编程技能将其余人员边缘化，将他们赶出公司。基于功能语言构建的系统将恶化，无法维护。在我看来，如果采用功能性语言，这是企业承担的最大风险，因此不能低估。
3. 该组织必须具有“建立而不是购买”的文化才能使之起作用。因为采用功能语言将意味着更少的“购买”选项。
4. 几乎总是对这个想法的技术上和非技术上的破坏者有所妥协。这些折衷方案中最常见的是，任何非JVM语言都没有考虑在内。提出了Clojure和Scala，Haskell和O'Caml刚出局。

当/如果高层管理人员参与选择编程语言时，高层管理人员应考虑的事情（这很奇怪，他们应该将其交给可信任的，知识渊博的人（技术和业务精通）：

• 生产率
  • 现在和将来的员工
  • 所有角色（架构师，开发人员，测试人员，OP等）
• 支持平台
  • 操作系统（硬件？）
• 语言/平台的发布者
  • 执照
• 语言/平台的成熟度
  • 发布者和/或社区的支持/
  • 图书馆
• 迁移当前代码库
  • 或与

请注意，这些不是特定于功能编程语言的。除非您提供这些参数，否则它们也不是参数。我们无法为您提供数据，因为它们完全取决于您的业务环境。我们唯一能做的就是从网络上收集数据，以显示特定语言的知识和兴趣。将StackOverflow上的许多问题或Linkedin上的许多标签翻译成流行的语言时，请务必小心。

我认为论点或事实不会有所帮助。当然也要说明您要解决的问题。

与普遍的信念和典型的自我评价相反，许多决定都是基于直觉。通常，这些决策是非常好的决策，因为它们在潜意识层面上融合了决策者的大量经验。

如果您想挑战诸如“我们将坚持使用C语言直到所有计算机结束”之类的决定，那么您要做的不只是提供一些参数。

第一步可能是找出决策者和高级管理人员在此类技术决策中应有发言权的原因。当然，我只能在这里猜测，但是很可能他们对技术人员做出的错误决定具有良好的跟踪记录。让我们面对现实：大多数开发人员都不擅长在公司一级做出（甚至是技术上的）决策。

一旦找到这些人，他们就会与他们交谈以获得信任。最好的方法可能是：听他们讲。他们关心的是什么，看到的风险和机会是什么。他们面临的挑战是什么？您可能会从这里开始，让技术人员参与这种决策。管理层通常并不想真正做出这些决定，但是并不信任其他人。因此，如果您的团队开始参与体系结构决策并证明您提出的决策是健全的管理，则可能愿意信任您/您的团队。

为了提出合理的架构决策，重要的是：

• 收集利益相关者（管理，用户，管理员，销售，客户...）的输入
• 根据该输入做出决策
• 明确沟通：（建议的）决定是什么；他们打算减轻什么风险；利益冲突是什么，并且有一些延迟：它们的工作情况如何。

如果您为拥有超过1万名员工的大公司工作，请准备学习以下一些课程。

• 编码速度与底线并没有真正的关系。
• 诸如数十年规模的可维护性之类的东西。
• 您认为可以使用功能语言解决的问题与底线并没有真正的关系
• 诸如培训1000名开发人员，对变更的自然抵制和维护由使用了不到5年技术经验的开发人员编写的代码库等问题。

一旦您达到了可以听到并考虑到您的论据的信任水平，您还将建立一种收集和考虑您，您的团队和管理层信任的需求的方法。

如果此过程提出了在某些领域使用功能性方法的建议，那么您就可以完成。

如果此过程产生了建议，则可以忽略当前的主要编程语言所提供的功能方法。

坏消息是：根据公司的规模和风格，这可能很容易花费数年或数十年的时间。

好消息是：您将在中学到很多东西。

由于第一步是开始交谈，尤其是听高级管理层讲话，所以我建议从阅读Just Listen开始。

一种好的方法是证明它在行业中显示出良好的效果并被采用。

您可以从以下获得一些数据：

• http://www.quora.com/What-c​​ompanies-use-a-functional-language-as-an-official-language

• http://pchristensen.com/blog/lisp-companies/

理想情况下，请尝试与某些上市公司的经理进行交流，尤其是在您所在行业的经理中，并从中获取数字和推荐。

Google为Haskell，OCaml等提供了许多其他类似的链接。

您是从错误的方向来的。

您正试图说服自己管理娱乐模式向功能范式的转换，并且试图提出支持这一论点的论点，而这些论点与您想要它的真正原因无关。否则，您将不需要提出问题，因为您可以从头开始列出您的论点。

相反，您应该考虑的是当前业务需求是什么以及如何最好地满足需求。如果发生这种情况，最好使用功能范式来实现，那么-是的！-你去玩。但是，如果您进行公平的分析，并且考虑到运营业务需求，对同事的必要培训，未来程序员的背景，维护等等等等，通常情况就不会如此。

没有技术技能的高级管理人员不应在意技术方面，例如功能范式的使用。这不是他们的专业领域，并且散发出微观管理的味道。他们为什么不将那些决定权委托给实际需要技能的人？

话虽如此，这里有一些提示可以说服具有技术背景的人（第一种情况）和没有技术背景的人（第二种情况）。

第一种情况

如果您正在与了解编程的人交谈，那么比较没有功能性编程范例编写的代码和以功能性风格编写的相同代码可能会令人信服：

使用命令式样式的示例C＃代码：

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

考虑到功能编程重写的相同代码：

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

然后问他们：

1. 程序员在第一个示例中可能犯多少个错误？那第二个呢？

2. 发现错误有多难？

3. 修改代码有多困难？

所有这三个因素都会影响生产率，因此也会影响产品的成本。

第二种情况

如果您要与不懂编程的人打交道，那么您可以告诉他们的技术知识不多。令人信服的方法之一是显示功能范式对您的工作和同事的工作的实际影响。

例如，比较同一团队的两个项目，一个使用FP，另一个不使用它。说明错误的数量要少得多，或者这是公司按时实际交付的第一个项目，应该足以令人信服。