为什么在一种产品或软件的开发中使用多种编程语言？

我是一名刚毕业的研究生，旨在攻读计算机科学硕士学位。我遇到了多个真正吸引我并鼓励我为它们做出贡献的开源项目（CloudStack，OpenStack，moby和Kubernetes仅举几例）。我发现它们中的大多数有一个共同点，就是使用多种编程语言（例如Java + Python + Go或Python + C ++ + Ruby）。我已经看过另一个问题，它涉及如何使多种编程语言相互通信：如何使两种不同的编程与两种不同的语言交互？

我想了解提示企业使用多种编程语言的要求。什么样的要求或要求类型使软件架构师或项目负责人说：“我建议对于任务1使用语言X，对于任务2使用语言Y”？我似乎无法理解在同一产品或软件中使用多种编程语言的原因。

这个答案涵盖了极好的范围，并且链接了为什么不同的语言可以为项目带来独特的好处。但是，项目最终使用多种语言的原因不仅仅涉及语言的适用性。

项目最终使用多种语言的原因有六个：

1. 重用其他语言编写的代码的成本效益；
2. 需要包括和容纳遗留代码；
3. 提供特定语言的编码器；
4. 需要特殊语言以满足特殊需要；
5. 传统语言偏见；和
6. 项目管理不佳（计划外使用多种语言）。

原因1-4是积极的原因，在某种意义上说，直接解决这些问题可以帮助项目更快，更有效地完成，拥有更高质量的产品并获得更轻松的长期支持。原因5和6是负面的，对需要的更改有抵抗力的症状，计划不力，管理不力或所有这些因素的组合。不幸的是，这些负面因素是“偶然”使用多种语言的常见原因。

原因1，即重用的成本效益，由于开源软件的更大作用以及改进的在Web上查找正确的代码组件的能力而成为允许在项目中使用多种语言的越来越强大的原因。面对经济现实，过去几十年的“内部全部编码”理念一直在消失，对于任何新项目而言，它从根本上不是最具成本效益的方法。反过来，这使得在项目中严格执行使用单一语言的机会减少了。

特别是在项目重用管理良好的开源组件的情况下，使用多种语言可以带来巨大的总体成本收益，因为重用的组件既隐藏在设计良好的界面后面，又由零成本的外部组独立维护。在最佳情况下，通过这种重用来混合语言对于项目而言，与使用操作系统组件相比，其成本不会更高。我没有比微软在其浏览器中大规模采用开源软件更好的例子说明这种方法的价值。

原因2（容纳遗留代码的需求）在任何大型项目中都被忽略。然而，遗留代码可能会带来很多麻烦，天真的假设可以轻松地用一种新语言替换新代码会带来极大的风险。遗留代码，甚至是糟糕的遗留代码，通常也包含了使用遗留产品的社区所期望的隐式“合同”。该社区通常是公司收入的主要来源，或者是支持政府软件的主要目标。简单地抛弃隐含的合同可以成群结队地追赶有意识的客户，并且如果其他选择随时可用，则可以在一夜之间使公司破产。

同时，不替换旧语言的旧代码与批发替换旧代码一样危险。最糟糕的例子是美国退伍军人管理局，它拥有大量的重要系统，这些系统是用称为MUMPS（不开玩笑）的语言编码的，这种语言是由医生而非计算机科学家设计的。没有人愿意学习MUMPS，而真正了解MUMPS的人快要死了。因此，程序员在尝试使用其他更常见，功能更强大且维护更好的语言时，必须适应MUMPS。

这种多语言使用需要仔细计划。该计划必须在一方面失去数十年的客户知识与另一方面失去支持软件的能力之间的最前沿。可以在明确定义的接口后隔离旧代码，并在其行为得到充分记录后，使功能更强大的新代码替换旧代码的技术可以提供帮助。但是，这种遗留方案绝非易事，并且已经（并将继续成为）各种规模的许多公司和组织消亡的原因。

原因3（提供各种语言的编码器）是一个务实的因素，项目会忽略这些危险。无论项目组织者可能（正确或错误地）感觉到某种特定的语言最适合其目标，如果该语言与他们可用的语言专业知识库相冲突，则学习的进度和质量都会受到影响。弯曲的程序员试图学习一种新语言。

一种更合理的方法是根据功能区域分析项目的语言需求。例如，仔细查看该项目可能会发现，只有少量的“高价值”代码“顶点”（例如，用于实施某些专有算法的代码）需要使用一些不那么常用的语言进行编码的专业知识。大型项目的其他部分通常可以很容易地用更通用的语言，或者（甚至更好）通过管理良好的开源产品来容纳。因此，根据语言需求分析项目可以提供一种更为现实且更具成本效益的方法来聘用或租用特殊语言的特殊专业知识，还可以帮助加强单个项目中语言之间的界面。

原因4使用不同的语言满足不同的需求，从对项目需求进行的这种分析中可以立即得出结论。还应注意这一点，因为在单个项目中选择太多的语言来进行支持会导致支持和组件之间的接口的复杂性组合爆炸式增长。最安全的成本明智的做法是始终首先找到最大的重用机会，尤其是如果存在可以通过定制而满足更多需求的好的软件包。接下来，应该对可以满足大多数已确定需求的少量语言做出某种决定。在重用密集型开发中，这通常是粘合代码的一种。

通常选择一个具有非常相似功能的多种语言不是一个好主意，因为项目的某些成员很喜欢。但是，如果存在可以从特殊语言技能中受益的明确识别，定义明确的功能子集，则这可能是使用多种语言进行新代码开发的一个很好的理由。

原因5（对使用的语言进行必要的更改的抵制）可能导致严重的项目中断和内部冲突。作为用户Daveo在对此答案的评论中指出，对于某些项目人员而言，变更可能非常困难。同时，抵制变革绝不是一个简单的问题，这就是为什么它会引起很多冲突的原因。如果遗留语言功能足够强大，则使用遗留语言技能可以极大地提高项目的生产率，并且可以使团队运作顺畅并尊重质量，从而获得质量卓越的产品。但是，必须在许多高级语言，组件可用性，开放源代码选项和智能工具套件支持方面无法与许多较旧的语言与最新的语言一起完成这一事实之间达到平衡，同时要兼顾传统语言技能。

到现在和现在，继续使用较弱，可读性较低或生产率较低的遗留语言的最常见（且具有讽刺意味的是，最正确的）说法是，较旧的语言可以生成更有效的代码。这是一个古老的论点，可以回溯到1950年代，当时汇编语言的用户常常对FORTRAN和LISP中编程的兴起表示愤慨。在处理密集型代码（例如，操作系统内核）中，即使在现在，代码效率参数仍然可以具有有效性的示例仍然可见，其中C仍然是C ++的首选语言（尽管出于超出简单效率的原因）。

但是，在新世纪的全球联网且功能强大的机器支持的项目环境中，作为选择项目语言的主要论据的代码效率变得越来越弱。计算和网络硬件的爆炸式增长使人工智能应用得以大规模营销，这也意味着人类编程的成本可以轻易地使相对便宜的硬件和云软件上相对高效的代码执行成本相形见war。如果将其与组件库，开放源代码选项和高级智能工具包等最新语言的更高可用性结合起来，则仅出于效率原因而保留一种语言的情况就变得非常狭窄。即使在确实适用的情况下，

当项目出于任何原因而很少或根本没有改变人员的选择时，就会出现一个使项目保留传统语言的更有说服力的理由。例如，当一个主要的旧产品线完全用仅能熟练使用现有员工的语言编码时，就会发生这种情况。在这种情况下，项目必须要么继续尝试使用旧语言编程，要么尝试培训现有员工如何使用新语言。

用一种新的语言来培训传统语言人员本身就可能是一种危险。我仍然记得有一个案例，一个刚刚接受过培训并从C过渡到C ++的项目成员向我真诚地抱怨说，他只是不了解面向对象方法的优点。当我查看他的代码时，他已将其较早的103 C函数转换为单个C ++对象类的103方法...并且理所当然地看不出这有什么帮助。

更深刻的信息是，当人们用一种语言和一种语言风格进行编程长达数年或数十年时，即使拥有良好的培训计划，使他们以新的方式“思考”的困难也变得几乎无法克服。在某些情况下，别无选择，只能招募更适应当前趋势和方法的年轻设计师和程序员。

原因6是项目管理不善，不言而喻。语言的选择和在项目中的使用应始终予以明确考虑和评估，而不是偶然发生。至少，语言选择会对项目的长期命运和支持成本产生巨大影响，因此应始终加以考虑和计划。不要成为MUMPS！

我似乎无法理解为什么在同一产品或软件中使用多种编程语言的原因？

这很简单：没有一种适合所有需求和目标的编程语言。

阅读Michael L.Scott的书《Programming Language Pragmatics》

一些编程语言偏向于表达性和声明性（很多脚本语言，还有诸如Agda，Prolog，Lisp，Haskell，Ocaml 等高级语言）。如果开发成本很重要（人工和开发人员的成本），则适合使用它们（即使运行时性能不是最佳的）。

其他编程语言则偏向于运行时性能（许多低级语言，通常使用编译的实现，例如C ++，Rust，Go，C，汇编器，以及专用语言，例如OpenCL ...）；通常他们的规范允许一些不确定的行为。当代码的性能很重要时，最好使用这些语言。

一些外部库写入和特定语言和ABI和调用约定的初衷。您可能需要使用其他语言，并遵循外来功能接口约定，也许通过编写一些粘合代码即可。

在实践中，不太可能具有高度表达性的编程语言（因此，假设有足够熟练的开发人员团队，可以提高开发人员的生产率），并且在运行时性能非常出色。实际上，在表达性和性能之间需要权衡。

注意：但是，编程语言进展缓慢：Rust比C甚至C ++更具表现力，但其实现几乎与性能相同，并且可能会改进以生成同样快速的可执行文件。因此，您在职业生涯中需要学习新的编程语言。但是没有银弹

请注意，今天的开发成本越来越高（1970年代情况并非如此（当时的计算机非常昂贵，或者在某些嵌入式应用中具有大量产品）。经验法则（非常近似）是，熟练的开发人员每年可以编写约25,000行（调试和记录的）源代码，并且在很大程度上不依赖于所使用的编程语言。

一种常见的方法是在大型应用程序中嵌入某些脚本语言（或某些领域特定的语言）。这种设计思想（与特定领域的语言有关）已经使用了数十年（一个很好的例子是Emacs源代码编辑器，从1980年代开始就使用Elisp编写脚本）。然后，您将使用一个易于嵌入的解释器（例如Guile，Lua，Python，...）在更大的应用程序中。在大型应用程序中嵌入解释器的决定必须尽早完成，并且具有很强的体系结构含义。然后，您将使用两种语言：对于必须快速运行的低级内容，应使用某些低级语言，例如C或C ++。用于高级脚本，其他DSL或脚本语言。

还要注意，一个给定的软件可以在大多数当前操作系统（包括Linux，Windows，Android，MacOSX，Hurd等）中使用某种进程间通信技术在多个协作进程中运行。它甚至可以使用分布式计算技术（例如云计算，HPC，客户端服务器，Web应用程序等）在多台计算机（或其中的许多计算机）上运行。在这两种情况下，都可以轻松使用多种编程语言（例如，以自己的编程语言对在一个进程或计算机上运行的每个程序进行编码）。阅读操作系统：三篇简单文章。另外，外部功能接口（例如JNI），ABI，调用约定等...有助于在同一程序（或可执行文件）中混合多种语言-并且您会找到诸如SWIG之类的代码生成器来提供帮助。

在某些情况下，您必须混合使用几种编程语言：Web应用程序需要Javascript或Webassembly（大多数Web浏览器中运行的唯一语言）才能在浏览器中运行（具有一些框架来生成这些语言，例如ocsigen）。内核代码需要一些东西（例如调度程序或对中断的低级处理）才能部分地用汇编器编写，因为C或C ++无法表达那里的需求，RDBMS查询应使用SQL，GPGPU需要使用OpenCL编码的计算机内核或由C或C ++主机代码等管理的CUDA。...某些语言旨在促进这种混合（例如，C 语言中的语句，asm我晚期的GCC MELT中的代码块等）。

在某些情况下，您会使用元编程技术：您的大型软件项目的某些部分会使用其他工具（可能是项目专用工具）通过一些特殊的形式化生成的代码（例如，使用C或C ++）：解析器生成器（不当称为编译器，我会想到像野牛或ANTLR这样的编译器，还有SWIG或RPCGEN。并请注意，GCC内有十几个专门的C ++代码生成器（GCC内部每个内部DSL都有一个）。又见这个例子。注意，很难找到metabug。另请阅读有关自举编译器以及有关谐音和反射的信息（这是值得学习的Lisp，玩SBCL，并阅读SICP ;还考虑JIT编译样库GCCJIT ;在一些大的项目，你可能会产生使用它们在运行一些代码，了解格林斯潘第十定律）。另请参阅FOSDEM2018上的电路少人一谈。

有时，您希望使用某些专门的注释语言（可能被视为DSL）来提供代码的正式注释（例如，帮助证明，静态分析器，编译器）。考虑ACSL与邮资-C注释C程序（安全关键的），或OpenMP的编译指示HPC。注意：编写此类注释可能需要大量技能和开发时间。

顺便说一句，这表明一些有关编译器和解释器的技能对每个开发人员都是有用的（即使没有在编译器内部工作）。因此，即使您不使用编译器，也请阅读《龙书》。如果您编写自己的解释器（或设计DSL），则另请阅读Lisp In Small Pieces。

又见这个和那个和那个和那个关系到你的问题我的答案。

还研究一些大型免费软件项目的源代码（在github上或从您的Linux发行版中），以获取启发和启发。

另外，某些编程语言是通过向现有语言添加注释（如pragma或comment）而演变而来的。对于例子，认为ACSL（注释扩展标注C程序通过，以使他们的证明邮资-C ）或OpenCL的或（一个C方言GPGPUs程序）的OpenMP和OpenACC的 #pragma小号或Common Lisp的类型标注。

PS：混合编程语言还有社会，组织或历史原因；我在这里忽略了它们，但我知道实际上这些原因是主要的。另请阅读《神话人月》

许多项目不是用多种编程语言构建的。但是，通常使用其他语言的脚本来辅助软件。

• 作为单独程序的管理工具有时会用不同的语言编写。
• 库和API经常提供多种语言的绑定，以便开发人员可以使用他们喜欢的任何语言。
• 构建脚本和相关的开发脚本通常使用专门的语言。
• 应用程序的端到端测试不需要使用相同的语言。

一些项目确实在应用程序中使用多种语言，例如，可以将插件集成为脚本语言的低级语言的核心。在某些生态系统（例如JVM或.NET）中，使用的确切语言不太重要，因为同一语言运行时上的多种语言具有良好的互操作性。例如，我可以使用现有的Java库在Scala中编写一个项目，并将脚本功能与Groovy集成在一起。

如果一个项目包含多个工具，则也可以使用不同的语言来开发这些工具。尽管一致性会很好，尤其是对于开源项目，但可用的开发工作可能会成为瓶颈。如果有人愿意开发有用的工具但不熟悉主要语言，那么该工具可能比一致性更有价值。

这有两种形式，很多组织介于两者之间：

糟糕的形式 -组织太混乱了，没有人可以确保对这项工作只有一个技术愿景。开发人员很可能会使用他们最熟悉的语言，或者最近尝试使用新的框架或语言，并由于天真的乐观而决定开始使用该语言。

良好的形式 -组织具有真正良好，干净的架构，非常适合多语言编程；将应用程序解耦到具有明确定义的边界上下文的独立组件中，并且这种组合使他们可以选择最简单的编程语言来编写特定组件。

现实 -通常情况下，前者更多。我已经看到一些公司为自己的业务领域选择一种语言，为他们的Web服务器选择另一种语言，并且通常为数据库管理选择第三种语言，这在技术上是可以的，但是很快他们缺乏技术上的了解（或拒绝听其员工的话）意味着它们最终将所有三个模糊在一起，变成一团糟，并经常引入更多适用于解决团团中特定部分的语言。

我可以举一个例子，该例子已经运行了32年，并且看起来还有很多生命。它是商业性的而不是开源的。

核心以特定于领域的语言编写，专门为项目创建。事实证明，这非常有用，特别是因为它将回滚功能集成到了基本体系结构中，但是又将其编译为C代码，然后我们使用平台的编译器对其进行编译。在那段时间里，它已经支持了大约二十个平台，还不包括32位和64位版本的差异，目前已在其中六个版本上发布。

它有一个用C ++编写的附加组件，该附加组件是在项目的前任负责人确信C ++ / MFC / Windows / x86将取代所有其他体系结构和平台时启动的，因此有必要提供C ++工作来能够雇用员工。事情没有像他预期的那样。

除了领域语言和C ++，开发人员还使用LISP进行工作，该LISP使用测试工具中嵌入的解释器来编写测试用例。我们曾经考虑过用Java替换LISP，但是很幸运的是我们没有这么做。

它也有其主要API的包装，该包装使用C＃编写。这是在客户要求时完成的，以便他们可以用C＃重写应用程序。它由Perl脚本创建，该脚本读取API的C头文件以及重要的配置文件，然后为包装器编写C＃代码。在Perl中进行所有文本处理比在C ++中进行文本处理要容易得多。

它具有自己的构建系统，并且需要它们，因为领域语言不适合基于make的构建系统。一个用于类UNIX平台的程序是用Shell脚本，Perl和一些小程序用领域语言编写的。用于Windows平台的是用批处理语言，Perl和域语言中的相同小程序编写的。旧的VMS构建系统是用DCL编写的，但是十多年来一直没有使用。

领域语言的编译器中有一些YACC / Bison编程。有一些用Objective-C ++编写的Apple平台测试代码。团队的一些内部网站（用于项目管理，不属于可交付成果的一部分）是用ASP编写的，而其他网站则是用Perl编写的CGI脚本。

基本上，这是从一个解决难题的项目开始的，因此值得创建专门的工具，它似乎比其他任何工具都更适合这项工作。该团队认为编程是一种与所用语言无关的技能，因此，如果这会使任务变得更容易，他们愿意使用一种新语言。但是，时尚并没有在他们的优先事项列表中排在首位，因此他们不会通过免费引入一种新语言来分散任务。

此代码的功能是在工作站和服务器上使用的数学建模（如果我不识别产品，我可以说得更自由一点）。当前的LoC约为2500万，团队总数约为50。

在某些情况下，需要使用一种工具（例如操作系统的UI工具包），该工具最容易从给定的语言访问。例如，在iOS和macOS上，如果要使用UIKit和AppKit编写GUI应用程序，则用Swift或Objective-C编写是最快，最简单的方法。（可能有其他语言的绑定，但它们可能在您要针对的最新操作系统版本的背后，因此可能不提供所有功能。）

因此，经常发生的情况是，当一个应用程序是跨平台的时，该应用程序的核心逻辑是用两种语言都可以访问的，而UI / OS特定部分则用它们本机工作的任何语言编写。

因此，如果您要编写Windows和macOS应用程序，则可以用C ++编写核心逻辑，并在Windows上的UI上使用C＃，在macOS上的UI上使用Swift。这样可以节省时间，因为您不需要编写两次核心逻辑并处理两个应用程序中的不同错误集，等等。但是，它还允许使用真正的本机UI，而该UI不能满足使用之间平台的最低公分母跨平台的UI库。

除了某些编程语言可以更好地适合某些特定任务这一事实之外，还有实际的现实。

在实际中，要考虑两个特别重要的方面：

1. 人们对不同的编程语言有不同的经验和兴趣水平。-在某些情况下，允许人们以自己喜欢的语言和精通的语言工作可能会比强迫他们使用通用语言带来更好的最终结果。
2. 大型代码库是由不同的人长时间构建的。-一旦出现更适合的语言，就无法获得重新编写整个项目所需的资金或志愿者数量。

当然，应用程序的某些特定部分通常具有完全不同的需求，例如：

• 用编译语言开发的性能敏感领域。示例语言：C ++
• 使用脚本语言开发的价格便宜，易于更改且可能可自定义的区域。示例语言：Lua。
• GUI布局。示例语言：HTML
• 安装程序。示例语言/工具：WiX。
• 建立。语言/工具示例：太多要列出，通常一次列出几个。

最重要的是，复杂的代码库使用了许多工具，其中许多工具允许使用其他语言进行必要的自定义和插件。

除了已经指出的其他正确观点之外：
根据经验，许多语言或环境决策都是通过“如果您有锤子，一切看起来都像钉子”来做出的，这意味着人们倾向于使用他们所熟悉的工具。

此外，引入新的环境甚至语言是对许可证，培训甚至硬件的一项重大投资，并且会浪费大量的生产时间- 在一家大公司中采购，安装，配置和培训每个过程要花费数周的时间，而您基本上就结束了和一堆初学者开发人员。
基本上没有时间在更现代或更合适的环境或语言上进行“投资”，因此他们会坚持自己拥有的，直到无法使用为止。

针对您的问题，如果有多个人员/团队参与解决方案的开发，则每个小组都倾向于坚持他们最了解的知识，因此整个解决方案中可能包含多种语言，并且是在多个环境中进行开发。

这个问题（和一些答案）似乎假设应用程序是单片代码块-不一定是这种情况。

像Stack Exchange这样的典型网站实际上是一堆彼此独立运行的不同服务，它们之间具有某种消息传递。这些服务可以（通常）以不同的语言实现，每种语言都有自己的优势。

我在一个很小的网上银行平台上工作，主要针对较小的社区银行和信用合作社。该平台具有多个组件-Web前端，数据库层，第三方通信层等。这些都是在具有不同操作系统的不同服务器上运行的独立应用程序。您在浏览器中的客户端上运行了Javascript，在服务器端上运行了Perl，您使用C ++编写了多个服务，这些服务充当了Perl代码和银行核心处理器之间的抽象层，这是另一套C ++应用程序，在各个层之间路由消息，少量C ++应用程序和Perl脚本以监视各个进程的运行状况，并将其状态报告给内部监视器等，等等。

整体应用程序仍然存在，但是即使出于不同的原因，它们也可以利用不同的语言。您可以用Java编写90％的应用程序，但可以使用JNI将C或C ++用于更关键的性能部分。

我想指出一个非常具体的实例，即“不同的语言具有不同的优势”主题：FORTRAN。

Fortran最初是为了使工程师更易于进行数值分析而开发的，此后，为了使Fortran编译器发出非常有效的数值代码，已经进行了很多努力。另一方面，自从早期以来，计算机的使用已向一千个方向爆炸，其中没有一个涉及数值分析，并且编程语言的发展在很大程度上跟随了忽略“真实”世界的过程。

SO：今天，您会发现自己在一家产品相当庞大的公司工作，其中大部分是用Java编写的（我是根据个人经验讲的）。但是您发现该产品的核心功能之一将是重新进行某种形式的数值分析，并且该特定分析的所有最佳代码都已经在网上提供-Fortran。所以你会怎么做？您可以下载其中一个Fortran代码，找出其接口（即，最顶层子例程的参数），然后用C为其生成JNI包装，并将其打包为Java类。AM！您只需要一次用三种语言进行开发。[尤其是如果您发现您的Fortran代码使用COMMON块-即静态存储-并且必须进行修改以确保线程安全性]

因为编程不是一项任务。即使创建产品也不是一项任务。有多种类型的任务，最好用不同的语言表达。

为了更加具体，让我们假设一个简单的事情，例如一个独立的应用程序（分布式应用程序还有更多的任务要执行）。

产品需要

• 书面
• 放在一起（这涉及用于部署的图像和字体等资源的编译和收集）
• 部署
• 已配置
• 受监控

一种可能对编写产品的运行时有利的语言不太可能与将产品组合在一起一样好。等等。

但是，即使是编写产品的过程也可能不是用一种语言来最佳地完成的。

假设产品中处理了许多结构化数据。在撰写本文时，数据的结构是否已知？如果是这样，您将需要在部署时配置一些数据库。最好使用一种可以生成可编译为您的运行时语言的语言来完成此操作。

现在，如果数据结构可以不时改变怎么办？比您需要一种将新的数据构造转换为代码和数据库配置的结构化方法。最好用另一种语言完成。

可以用相同的语言完成所有操作吗？当然。但是，您的效率取决于完成项目的速度以及对更改的适应能力。如果您可以使用现有工具将很多工作自动化，那么您花3个月的时间就可以由其他人在2天内完成。但是有人会使用其他语言来自动化您通过重复进行的操作。

软件开发已经发展到可以在同一项目中使用不同的编程语言的程度，并且可以使其正常工作。

然后是一个问题，为什么您会使用不止一种语言。

原因之一是语言已过时，并逐渐被更新的语言所取代，如果幸运的话，可以一点一点地完成。因此，您的项目将混合使用新旧语言。

另一个原因是这样的情况，其中语言X很大程度上是平台A上使用的语言，语言Y非常是平台B上使用的语言，但是两种平台都支持语言Z。因此，通用代码是用语言Z编写的，然后根据平台将其与X或Y组合在一起。

人们喜欢使用别人编写的代码（换句话说，他们不必花费时间自己编写代码）。他们可以随意使用他人用任何语言编写的代码，然后以他们喜欢的语言添加代码。