多语言编程:使用多种语言构建应用程序是一种很好的做法吗?

时间:2008-09-26 20:11:45

标签: architecture polyglot

我正在考虑构建一个混合了动态语言(python或ruby)和编译语言的应用程序,需要一些帮助来说服自己这是一个好主意。

我的想法是我可以使用动态语言快速编写大量代码,然后下载到c / c ++这样的编译语言来实现性能关键代码。

我可以看到这种方法有很多好处:

  1. 主要使用动态语言进行编码,提高工作效率
  2. 两种语言库的可用性
  3. 但也存在一些缺点:

    1. 维持两种语言之间的桥梁
    2. 依赖于两种语言和语言/库错误而不是一种
    3. 这种方法的其他优点/缺点是什么?有没有人知道有关这方面的任何资源和/或最佳实践?

11 个答案:

答案 0 :(得分:12)

我认为你的方法非常明智。解决缺点的方法是提前找出在决定是否将它用于项目之前将动态语言与C或C ++接口是多么容易。

此外,您需要考虑是否希望您的应用程序是跨平台的。与编译的语言相比,动态语言可能不依赖于平台。这可能是决定应该用C或C ++完成应用程序部分的一个因素。

答案 1 :(得分:6)

我刚刚重新阅读了您的问题 - 您建议将C用于性能关键代码。任何有价值的动态语言都有工具可以让你有效地访问本机代码。首先,用动态语言编写整个内容。你可能会发现你毕竟不需要C.

但是,如果你这样做,打破一个分析器,仔细选择要优化的东西,然后去实现它。

答案 2 :(得分:5)

Ja,bien sur,mein freund。它确实是un'idea meravigliosa。 Boa sorte。

我正在开玩笑。 Web开发人员每天都会这样做,甚至没有注意到:Java,JSP,EL / OGNL,HTML,CSS,Javascript,ant,XML,XSLT ......

我认为多语言编程是自然的,强大的,高效的,而不是很酷。当然,它必须以正确的方式使用,以挖掘每种语言的最大功能,并且不要混淆团队中的其他人。

答案 3 :(得分:3)

是。许多程序是高级语言(如Python或Ruby)和低级语言(如C)的混合体。您可以在垃圾收集的OO语言中获得编码逻辑的好处,并且仍然可以在紧密的内部循环中手动管理寄存器

答案 4 :(得分:2)

您可能会发现直到稍后您才需要实施任何性能关键的内容。所以,我会努力反对其中一个性能关键的主要变化,直到你确定你需要这样做。

否则只需选择一种根语言,perl和ruby使用c,所以它们的结合非常简单。您还可以在Java VM上运行python(jython)或ruby(jrunby),这将为您提供java作为后端。虽然它可能会提供一些其他问题,因为我不熟悉针对相应语言的那些版本进行开发。

并非所有的性能问题都需要你降低到低级语言,所以在你快速跳到另一个语言之前,先尝试在一个语言中解决它。

祝你好运,

答案 5 :(得分:2)

我赞成使用最好的工具。在软件工程的情况下,这意味着是多语言。无论他/她正在建造什么,你都不会指望木匠只使用锤子。为什么我们会有所不同?

答案 6 :(得分:2)

@ Zorkerman

我对Jython和JRuby都有经验......使用JRuby还有很多。

我必须说它们是很棒的平台,你可以获得动态语言的巨大好处,加上Java的丰富的第三方和第一方库支持,PLUS高度平台独立的基本编译语言,两种语言的PLUS垃圾收集(它是对于理解内存管理很重要,但是我最好避开它,除非你真的需要它,比如你是在做驱动程序或内核级别的东西,还是需要每一盎司性能的东西你可以鼓起来

我只是想给一个快速的轶事。我最近正在构建一个ruby脚本来索引一个Solr实例,我需要访问一个DB2数据库(我们要索引的数据源)。直接Ruby失败了......它有可怕的DB2支持,这需要完整安装DB2 express版本......它仍然没有像宣传的那样工作(我在完成安装后无法编译Ruby驱动程序)。解决方案是切换到JRuby并使用Ruby方面的JDBC,使用几个易于安装的jar(以及比DB2安装更多的小文件)。

我肯定会高度建议考虑JRuby或Jython而不是使用C作为你的后端...我发现算法和资源性能通常比你选择的语言对应用程序性能有更大的影响,并且Java平台有很多东西可以提供(自从早期人们谴责它比C / C ++慢得多)它已经走了很长的路。除非您正在进行非常繁重的计算密集型事情,这些事情无法通过算法进行重构,否则您很可能不需要下载到编译语言,无论您选择哪种语言。


PS在JRuby中与Java的集成是非常无缝的(无论如何从JRuby到Java端),因此维护桥接不是问题。 Jython我认为是相同的,但我对它的体验再次少了。

答案 7 :(得分:2)

值得注意的是,Gambit Scheme和Chicken(以及其他一些实现)以解释模式运行,然后可以编译为C.

答案 8 :(得分:1)

我认为这是一个好主意。

由于大多数(几乎所有?)操作系统都是用C或C ++编写的,因此每种动态或解释语言都会在某种程度上回归到低级别的编译优化语言。

答案 9 :(得分:1)

有些人认为我们的程序员必须掌握太多语言。他们认为添加一种语言是一件坏事。

SQL中的整个数据访问,HTML / CSS中的表示似乎是不可逆转的。

XML的东西有点令人厌倦:有些人试图用XML做所有事情,好像XML具有使软件更好的神奇力量。

此外,由于多种语言,还有相当多的冗余。所有的语言间绑定意味着事情会被写入两次,每种语言一次。

答案 10 :(得分:0)

这很常见,但要确保你知道为什么要像你那样设计它。

一个例子是游戏编程。在许多游戏中,性能关键型游戏引擎是用C语言编写的,而级别脚本编写则是用Python,Scheme,本土语言或其他任何东西完成的。

这意味着性能极客们正在使用他们喜欢的语言,并为他们提供所需的低级别控制,而关卡设计师可以使用更高级别的语言,他们不需要担心管理内存等等。类推。