如果函数式语言真的很简洁，为什么它们在语言大战中没有取得更好的排名呢？

Question

我比较了语言枪战游戏中的语言 仅按代码大小。这是我得到的总结（最短的第一个，按相似的分数分组）。

1. Python、Ruby、JavaScript、Perl、Lua、PHP、Mozart/OZ
2. OCaml、Erlang、Racket、Go、Scala、F#、Smalltalk
3. Pascal、Clean、Haskell、Common Lisp、C#、Java、C
4. C++、Ada、ATS

我想知道为什么。获胜者似乎是普通的旧动态语言。 Erlang、Racket（née PLT Scheme）和 F# 都表现良好。 Haskell 和 Common Lisp 看起来并不比声称冗长的 Java 更简洁。

更新：

我发现了一篇富有洞察力的帖子 关于这个主题的图表。我还发现了大型程序的类似语言比较（一个简单的光线追踪器）。总而言之，我不会说我得到了“正确”的答案，但我得到了一些值得思考的东西。

Answer 1

如果函数式语言真的是
简洁...

1 - 大型编程与小型编程不同。

这些微小的基准游戏程序不应被视为每种语言提供的抽象和模块化如何应用于大型编程的示例。

2 - 您在基准测试游戏摘要页面中看到的大部分内容仅指为每种语言实现贡献的最快程序（较慢的程序通常会在一段时间后从网站上删除 - 何时以及哪些较慢的程序被删除删除大多是任意的）。

{编辑：Adam，因为您不想相信我的话，即摘要页面仅指最快的程序 - 查看过滤数据行的脚本以查找“哪种编程语言是最好的？”页。查看 lib_scorecard.php - Alioth 颁发自己的安全证书，因此您的浏览器会抱怨。}

因此，以 Haskell 为例，您正在查看的代码大小已贡献的最快的 Haskell 程序。

3 - 流星竞赛程序均未被删除，流星竞赛是一场没有限制的编程竞赛 - 最小的流星竞赛 Haskell 程序是最慢的流星竞赛 Haskell 程序。

Answer 2

1. 没有一种语言总是优于另一种语言（嗯，有一些例外......；）），因此这同样适用于一组广泛分类的语言。基准测试涵盖了广泛的主题，X 可能比 Y 更不适合其中一个
2. 。源代码是压缩的，我们真的不知道程序有多少行，长度是多少（是的，这是一个指标
3. ）许多函数式语言仍然比广泛使用的命令式静态语言做得更好 - 这并不是说函数式编程语言不简洁，而是动态语言允许更简洁的程序
4. 至少在 Haskell 中，简洁性的很大潜力来自于你可以的抽象自己构建 - 但您必须自己构建它们并将它们包含在您的解决方案中。聪明的 Haskell 黑客可能会用 20 行实现一个 monad，这样就可以用 20 行而不是 30 行来解决一个小问题 - 这种抽象对于一个小程序来说并没有什么回报，但可以在更大的程序中节省许多行（例如，200 行）共 300 个）计划。我想这同样适用于 Lisps（只有宏而不是 monad），
5. 不要太认真地对待粉丝们。 FP 很棒，值得研究，但它不能治愈癌症，也不能神奇地将任何代码缩短 25%
6. 他们仍然可以在某些领域击败动态语言：例如，树状数据结构及其处理表达极其得益于代数数据类型和模式匹配，在许多函数式语言中自然如此。

Answer 3

这似乎是一个发泄的机会：

是否有统计研究表明Python“更有生产力”？

重点是，最初的问题是试图使用一些（微不足道的、不恰当的）数据来对编程语言之间的比较进行概括。但事实上，几乎不可能使用任何数据对编程语言进行任何合理的一般定量比较。

不过，这里有一些值得深思的地方：

• 在所有条件相同的情况下，动态类型语言可能会更简洁，因为它们不需要花时间描述数据类型
• 在所有条件相同的情况下，在静态类型语言中，类型 -对我来说，推断语言可能更简洁，因为它们不需要到处声明类型在
• 所有条件相同的情况下，在静态类型语言中，那些具有泛型/模板的语言可能更简洁，因为没有它们的语言需要重复代码或强制转换和间接
• ，具有简洁 lambda 语法的语言可能会更加简洁，因为 lambda 可能是编程中避免重复和样板代码的最重要的抽象

在所有条件相同的情况下 远射。

Answer 4

Alioth 游戏中的程序并不能真正代表一般语言中的程序。其一，其中的实现针对 Shootout 的特定基础设施进行了高度优化，这可能会导致函数式语言中的代码不太惯用且更加臃肿。这类似于一些 Ruby 库用 C 语言编写性能关键型代码的方式 — 查看该 C 代码并声明 Ruby 臃肿且低级，这实际上不会给该语言带来公平的震动。

另一方面，函数式语言被吹捧为如此简洁的一个重要原因是它们擅长进行抽象。这在大型程序中往往比在单函数奇迹中更有帮助，因此专门为简单简洁而设计的语言在那里赢得了巨大的胜利。 Python、Perl 和 Ruby 是专门为缩短程序而设计的，而大多数函数式语言都有其他目标（尽管这并不是说它们只是忽略代码大小）。

Answer 5

我最近将一个相对较短的 Java 程序移植到 OCaml 中。我过去涉足过 SML 和 Haskell，并且在 C 方面拥有丰富的经验。

在这个答案中，我对命令式代码与纯函数式代码（即没有突变）进行了比较。如果您允许命令式代码潜入其他功能程序中，您在比较什么？

根据我的经验，纯函数式编程（PFP）很优雅，但并不比命令式更简洁。 PFP 中的“声明”样板较少，但“转换”样板较多；例如，从元组中解包、尾递归辅助函数等。因此，这两种范式都不允许不受阻碍地表达程序的纯粹“内容”。

PFP 运行某些东西的成本较低，并且编写一个程序来证明给定算法原则上可以工作在 PFP 中效果很好。但是，增强它以使其成为“现实世界”，让它处理错误条件和非法输入和打印诊断会增加很多膨胀，而这些膨胀在命令式语言中更容易克服。

Answer 6

必须与可用于您的第 1 级中的大多数语言的扩展 OOP 库有关，并且只是简单的旧技巧，例如 shell 调用的反引号和 perl 正则表达式语法。 如果不是面向对象语言中充斥着抽象概念，那么放弃 python

pw = file("/etc/passwd")
for l in pw:
    print l.split(':')[0]

打印系统上的所有用户名将需要更多代码。我并不是说这在其他范式中不能完成，但趋势是每种类型都有很多成员函数，使繁琐的任务变得简单。就我个人而言，我发现纯函数式语言仅对学术目的有用（但话又说回来，我知道什么）。

Answer 7

您应该考虑这样一个事实：您的第 1 组语言（脚本）比 C/C++ 慢 30 到 100 倍，对于函数式语言来说则慢 2 到 7 倍。列表中的程序针对速度进行了优化，测量其他任何内容是次要问题，这并不是语言真实状态的良好指标。
查看 表，其中代码大小和运行时间的权重均为 1。通过这种方式，您可以比较速度/可维护性比率，这似乎是比代码大小更好的指标。

Answer 8

获胜者似乎是普通的老式动态语言。

Lisp 是一个明显的反例，它是一种极其冗长的简单古老的动态语言。另一方面，APL/J/K 可能比任何其他语言都简洁得多，而且它们是动态的。还有数学...

Haskell 和 Common Lisp 看起来并不比声称冗长的 Java 更简洁。

您的数据适用于已针对性能进行优化的小型程序，并且测量的是在特定设置上使用 GZIP 算法压缩后的代码大小，因此您不可能仅从它们得出一般性结论。也许更有效的结论是，您正在观察性能优化导致的膨胀，因此数据中最简洁的语言是那些无法优化的语言，因为它们从根本上来说效率低下（Python、Ruby、Javascript、Perl、Lua、PHP）。相反，Haskell 可以通过足够的努力进行优化，以创建快速但冗长的程序。这真的是 Haskell 与 Python 相比的劣势吗？另一个同样有效的结论是，Python、Ruby、Perl、Lua 和 PHP 在该设置上使用 GZIP 算法可以更好地压缩。也许如果您使用游程编码或算术编码或 LZ77/8 重复实验，也许使用 BWT 预处理或其他算法，您会得到完全不同的结果？

该网站的代码中还存在大量毫无价值的代码。查看这段 OCaml 代码片段，仅当您的 OCaml 安装已过时两代时才需要：

(* This module is a workaround for a bug in the Str library from the Ocaml
 * distribution used in the Computer Language Benchmarks Game. It can be removed
 * altogether when using OCaml 3.11 *)
module Str =
struct
  include Str

  let substitute_first expr repl_fun text =
    try
      let pos = Str.search_forward expr text 0 in
      String.concat "" [Str.string_before text pos;
                        repl_fun text;
                        Str.string_after text (Str.match_end())]
    with Not_found ->
      text

  let opt_search_forward re s pos =
    try Some(Str.search_forward re s pos) with Not_found -> None

  let global_substitute expr repl_fun text =
    let rec replace accu start last_was_empty =
      let startpos = if last_was_empty then start + 1 else start in
      if startpos > String.length text then
        Str.string_after text start :: accu
      else
        match opt_search_forward expr text startpos with
        | None ->
            Str.string_after text start :: accu
        | Some pos ->
            let end_pos = Str.match_end() in
            let repl_text = repl_fun text in
            replace (repl_text :: String.sub text start (pos-start) :: accu)
                    end_pos (end_pos = pos)
    in
      String.concat "" (List.rev (replace [] 0 false))

  let global_replace expr repl text =
    global_substitute expr (Str.replace_matched repl) text
  and replace_first expr repl text =
    substitute_first expr (Str.replace_matched repl) text
end

单核版本通常包含大量并行代码，例如 OCaml 中的正则表达式-dna。看看 fasta 中的怪物OCaml：整个程序被复制两次，并且它会切换字大小！我的磁盘上有一个旧的 OCaml 版本的 fasta，其大小还不到该版本的五分之一...

最后，我应该指出，我已向该站点贡献了代码，但由于它太好了而被拒绝。撇开政治不谈，OCaml 二叉树曾经包含“由 Isaac Gouy 去优化”的语句（尽管注释已被删除，但去优化仍然存在，使得 OCaml 代码更长、更慢），因此您可以假设所有结果经过主观修改，专门引入了偏差。

基本上，利用如此低质量的数据，你无法得出任何有洞察力的结论。您最好尝试找到已在语言之间移植的更重要的程序，但即使如此，您的结果也将是特定于领域的。我建议完全忘记点球大战......