核心和UI的语言

与任何其他计算机程序一样，包管理器也具有计算核心和用户界面（UI）。

在这种情况下，用户界面不是图形用户界面，而是一些具有预定义语法的文件，允许用户（程序员）定义、使用和管理包。例如，Java的Maven使用pom.xml文件，而Node（JavaScript）的NPM使用package.json文件。

计算核心将这些文件作为输入，并根据这些输入配置的任务执行，例如从互联网上的某个位置获取文件，或在本地构建一些工件。

选择Python的理由

使用Python作为包定义的UI语言可以是一个安全的默认选择

  • 许多C和C++开发人员已经在使用Python进行脚本编写。公司也经常使用Python开发自己的开发工具。
  • 它是一种非常简单的语言，即使以前不了解，经验丰富的C或C++开发人员也可以非常、非常快地学习Python的基础知识。模板元编程、未定义行为、概念、硬核优化和零成本抽象、SFINAE、RAII……如果学习Python是一个问题，休斯顿，我们遇到了麻烦。
  • 其动态的、解释性的特性，为用户提供了友好简洁的语法。

当然还有其他不错的选择。一个很好的例子是广泛使用的Mac OSX的Homebrew项目，它同时使用Ruby语言作为其UI和核心。Python在C和C++开发人员中可能仍然更受欢迎，但Homebrew已经证明，实现语言并不是成功的先决条件。

鉴于Python被用作UI语言，使用Python作为核心也可能有其他优势

  • Python凭借其简单性和生态系统，以允许非常快速的原型设计和开发而闻名，这使得可以快速迭代开发的工具，快速修复错误，以及快速发布周期。
  • 当从互联网上检索数百兆字节的包或在本地构建完整的库时，工具的性能可能不是问题。
  • Python具有很高的可移植性，可以移植到许多系统、架构和平台，这减轻了开发人员分发工具的很多负担。

有人可能会说，如果核心代码库使用不同的语言，可能会阻止那些不了解Python的潜在贡献者修复问题和贡献功能，但开源项目的现实情况是，项目维护者承担了大部分开发工作，因此，只要上述理由对他们来说是合理的，项目就会从这种语言决策中受益。

最大的谬误

但是，没有任何一个是C++包管理器不能用C++编写的原因。原因是标题本身隐藏的一个大谬误。拥有一个C++包管理器是一个谬误，这样的东西（在正常思维中）是不可能存在的。

无论好坏，存在的是C和C++包管理器。这并不是说这样的包管理器可以或将会分别处理这两种语言的包，而是C库也广泛用于C++项目中。OpenSSL和ZLib只是C++项目中非常流行的几个C库。

这是C++开发工具的典型问题，它们很少仅仅是C++开发工具。CMake是一个C和C++元构建系统，所有流行的IDE，如Visual Studio或CLion都处理C和C++。

现在，既然这一点已经清楚，我们可以看到，“在包管理器的核心使用哪种语言？”这个问题没有好的答案。有人可能会说，共同点是C，根据一些指标，它甚至比C++更受欢迎。但这肯定会让许多C++开发人员感到恼火，甚至愤怒，并且是有理由的。无法使用许多高级C++特性和STL，而这些特性很多时候是绝对零成本的，甚至可以提高性能，这可能会令人沮丧。

如果选择的语言是C++，C开发人员也会感到非常失望。有一些著名的案例，例如Linus Torvalds关于C++的观点。撇开语言之争不谈，确实存在许多优秀且有用的C项目（Linux、Git、Cpython……），因此在做出决定时不能仅仅忽略它们。

结论

因此，虽然“C++包管理器不能用C++实现”由于上述谬误而成立，但可以说“C和C++包管理器可以用C++实现”。但正如我们所看到的，试图将“C和C++包管理器必须用C++实现”作为普遍真理也是毫无意义的，因为这种说法没有逻辑依据。

那么“它应该用什么语言实现呢？”。对我们来说，上面解释的原因明显超过了可能的缺点。从几个月前做出的决定来看，我们仍然对此感到非常满意，并相信这是一个好的决定：Python为UI和核心提供了统一的语言，用户和贡献者都理解和喜欢，同时允许我们在开发新功能、修复错误和发布新版本时保持高效。