多种语言或者多种语言的解决方案使我们可以将语言应用于最适合的问题。但是，至少根据我的经验，软件商店倾向于将"超级"语言应用于他们要解决的问题的所有方面。即使使用另一种可以简单自然地解决问题的语言，坚持使用该语言也会"打出高潮"。我们为什么还是不使用多语言解决方案来实现？

解决方案

回答

我遇到的一个问题是Visual Studio不允许在一个项目中混合使用多种语言，这迫使我们将每种语言抽象为单独的DLL，这不一定是理想的选择。

但是，我怀疑主要原因是人们认为在许多不同语言之间来回切换会导致程序员效率低下。这有些道理，我经常在JavaScript，C＃，VBScript和VB.NET之间切换，当我从一种语言切换到另一种语言时，由于混合了一些语法，因此会浪费一些时间。

当然，肯定还有更多"多语言"解决方案的空间，尤其是扩展到不使用JavaScript和任何后端编程语言的地方。

回答

我很幸运能够在小型项目中工作，并有可能为我的任务建议合适的语言。例如，将C语言作为一种低级语言，将Lua扩展为高级/原型已很好地发挥了作用，并在新的嵌入式平台上迅速提高了速度。对于任何较大的项目，我总是希望使用两种语言，一种针对特定项目的特定于领域的语言。它为快速试用新功能增加了很多表现力。

但是，这可能最适合我们使用敏捷开发方法，而对于更传统的项目，首先要克服的障碍是选择使用哪种语言，而脚本语言往往会立即成为"新手"，而其推销或者"严肃性"却较少图像。

回答

在解决方案领域，我几乎总是提倡使用一种以上的语言(实际上，由于SQL是许多项目的一部分，因此使用了两种以上的语言)。即使客户喜欢具有显式打字和大量人才的语言，我还是主张将脚本语言用于管理，测试，数据清理等。

多语言的优势可以归结为"正确的工作工具"。

但是，存在合法的缺点：

• 很难拥有集体代码所有权(并非每个人都精通所有语言)
• 集成问题(在托管平台中有所减少)
• 基础结构库增加了运行时开销(这通常很重要)
• 工具成本增加(IDE，分析工具等)
• 从一个切换到另一个时的认知"碰撞"。这是一把双刃剑：对于那些精通技术的人来说，不同的范例是互补的，并且当一个问题出现时，通常会出现"但是在X中我会用Z解决！"问题得以迅速解决。但是，对于那些不太理解范例的人，在尝试理解"这是什么？"时可能会出现真正的放慢脚步。

我还认为应该说，如果我们要使用多种语言，我认为我们应该选择使用截然不同的语言。我认为通过将两个Cand VB都放在一个项目上，我们在解决问题方面不会获得太多收益。我认为，除了主流语言之外，我们还希望拥有一种脚本语言(用于完成较小的一次性任务的高生产率)和一种具有截然不同的认知风格的语言(Haskell，Prolog，Lisp等)。

回答

多语言解决方案的最大问题是涉及的语言越多，找到具有适当技能的程序员就越难。特别是如果任何一种语言甚至都有些深奥，或者来自完全不同的设计学派(例如功能性，过程性，面向对象)。是的，任何优秀的程序员都应该能够学习到他们所需要的东西，但是无论他们有多不切实际，管理人员通常都希望有人能够"扎根"。

其他原因包括代码重用，不同语言之间接口的复杂性增加以及特定代码所属的语言不可避免的争端。

综上所述，请意识到，许多系统在设计上都是多语言的-使用数据库的任何事物除具有某些其他语言外，还将具有SQL。而且，实际代码或者构建系统也经常涉及脚本。

我几乎所有的专业编程经验都属于上述类别。通常，有一种核心语言(C或者C ++)，不同程度的SQL，shell脚本以及外围可能有一些perl或者python代码。

回答

我雇主的态度一直是使用有效的方法。

这就是说，当我们找到一些有用的Perl模块(例如实现"本福德定律"的模块，" Statistics :: Benford")时，我不得不学习如何使用ActiveState的" PDK"。

当我们决定在项目中添加区间数学时，我不得不学习Ada以及如何同时使用GNAT和ObjectAda。

当需要高速字符串库时，我不得不重新学习汇编器，并习惯了" MASM32"和" WinAsm"。

当我们想要一个libiconv的COM DLL(基于Delphi Inspiration的代码)时，我重新认识了Delphi。

当我们想使用Bill Poser博士的libuninum时，我不得不重新学习C以及如何使用Visual C ++ 6的IDE。

我们仍然在VB6和VBScript中制作原型，因为它们很擅长。

也许某个时候我最终会用Forth，Eiffel或者D做事，或者天堂帮助我Haskell(我对语言本身没有任何反对，这只是一个非常不同的范例。)