为什么Linux应用程序经常在摘要中使用它所使用的语言？

在展示应用程序时，Windows和Mac大多谈论功能。另一方面，Linux应用程序具有有关使用哪种语言（以及随附的库）而非功能编写的更多详细信息。这是为什么？

我能理解知道GTK +与QT之间的差异会仅仅因为桌面集成要求而有所不同，但是C，C ++，Python，Assembly与其他等等之间的差异呢？真？

例如：foo是用C / GTK +编写的简单等等。

我认为传统的Linux用户（实际上是由自己自行安装系统的怪异修补匠）确实关心此类信息（该工具背后的技术是什么？）。例如，我也是那些讨厌的人之一，他们会因为安装了我不喜欢的某些技术而避免安装和使用软件包。有些人当然称这种行为为宗教。是不是很傻？

无论如何，我可以想到两个原因：

• 打包程序也比那些Linux用户一样令人讨厌（如果不更多），因此他们发现添加此类信息是一个好主意。

• 我认为，当这些打包人员将此类信息放在其打包说明中时，他们很可能会将其作为某种形式的宣传来进行。它有时会起作用（对我有用很多次）。

当然，这只是一个猜测。

我的感觉是，它与四个软件自由中的第二个有关：

自由学习程序的工作原理，并对其进行更改以使其按您的意愿进行操作（自由1）。前提条件是访问源代码。

公开使用该语言（或其他技术功能）可以提高人们的选择能力，并鼓励精通这些语言的人们参与项目。

这可能是部分历史性的。即使在不太遥远的过去，单个系统管理员也通常会构建和安装他们系统上运行的所有内容。

关于使用哪种语言和库来实现工具的说明向管理员提示了该过程将对其系统进行多少工作。

在这个无处不在且影响深远的软件包管理工具的时代，这有点不合时宜，但是Unix文化是保守的，因为它不会抛出似乎有用的东西，因此习惯会消失还需要一段时间。

扩展jasonwryans的答案：

如果您命名了该语言的编写语言，则接收该语言的人可以估算出提供补丁，获得一些见识或扩展程序的难度。

当然，只有当您是程序员时，这才有意义。

您在哪里看到摘要？在存储库中，还是.deb或.rpm之类的包中？

如果从源代码构建它，则该信息可能有助于识别是否必须安装其他内容（编译器，库，构建工具）。

Unix，以及现在的LInux和BSD，一直都有一个非常脆弱的软件基础，​​并且在最近的过去存在着更加多样化的硬件基础。重要的是要知道您的系统上的解释器中运行了某些软件，或者您可以编译源代码。如果您没有Common Lisp解释器，Tcl解释器或任何其他解释器，则您不想打扰下载源，只是发现自己无法运行它。

对某种语言的描述可以避免浪费大量时间。

当提示“这是什么？”时，开发人员将倾向于描述其性质，对他们而言，其性质与源代码有关，而不是其功能。希望有人在最终将其描述打包之前将其重写为更以用户为中心，但是提及该语言仍可能是相关的，例如与可扩展性和可脚本性相关，或者对于吸引参与者有帮助。

从我的角度来看，此类信息对于吸引新的贡献者以及使潜在用户立即了解将应用程序集成到他们的系统中可能需要进行的工作至关重要。

• 一般方面是运行应用程序时使用的库。

某些安装仅限于一些选定的工具箱，例如GTK +，但不包括QT，反之亦然。对于维护系统并在很长一段时间内定期更新其组件的管理员来说，这可能仅仅是一个实际问题，而不是一个虔诚的问题。

• 另一方面是为了编译应用程序而使用的库和必要的先决条件。

即对于基于源的Linux发行版的用户而言，无论是用C还是用Objective-C编写应用程序，都会产生很大的不同，因为他们的编译器首先需要支持该语言。其他语言可能需要安装大量的库。接下来的问题是，您愿意接受多少工作来编译此应用程序。

• 另一个方面是吸引贡献者的意图。

大多数开发人员偏爱少数几种语言，或者可能只是缺乏其他语言的经验。为了允许更多的人为某个应用程序做出贡献，一些项目甚至将其源代码分为两种不同的语言（例如Wesnoth，Vega Strike，Naev，仅举几例）。其中一个用于核心应用程序（例如C或C ++），另一个用于简单修改（例如Python或Lua）。这是“开源应用程序体系结构”一章的链接，该章描述了在Wesnoth中如何以及为什么这样做。

• 最后，对于某些语言，显然存在很多偏见和偏见。

我只是说我已经看到过用任何一种语言编写的效率低下的软件。如果您问我，为了提高效率，应用程序的代码质量比其编写的语言重要得多。

我认为这很大程度上与表演广告有关。用编译语言（C，C ++等）编写的应用程序的性能要比使用脚本语言（perl，python等）编写的应用程序好得多。

但这也与兼容性有关。用脚本语言编写的应用程序也可能几乎不需要修改就可以跨体系结构和OS移植。

在当今的台式机/服务器系统上，它可能不那么相关，但是对于较小的系统（从嵌入式系统到SSD上网本和平板电脑），由于大小和大小的原因，程序使用的语言或库可能是成败的问题。便携性考虑。

关于大小：添加解释器以使用其他语言，以及所有标准模块和通常使用的附加模块，可以轻松为存储需求增加数百兆字节。库家族，尤其是与主要桌面环境（如Gnome和KDE）相关的家族也是如此。更糟糕的是，从运行n到n+1Perl程序可能不会增加太多的内存使用需求，因为可以共享很多内存，但是从nPerl程序和0个Python程序到nPerl程序和1个Python程序导致内存使用显着增加。当每个愚蠢的编写自由软件的人都想要使用自己喜欢的脚本/ radtool语言进行编程时，这将成为一个更大的问题。Perl，Python，PHP，Ruby，JavaScript，Bourne shell，Bash，Csh等。

关于可移植性：许多解释语言（以及库框架）大量使用了可能在大型Linux桌面/服务器系统上可用但在较小/嵌入式/无MMU的系统上可用的功能。我.so想到了对运行时动态模块加载的依赖...