什么情况下动态语言不适合？

Question

什么因素表明项目解决方案不应该用动态语言编码？

Answer 1

速度通常是主要答案。尽管这些日子已经不再是一个问题。

Answer 2

速度至关重要。动态语言变得越来越快，但仍然不能接近编译语言的性能。程序员的

Answer 3

熟悉并愿意与语言进行工作。

您的动态语言可能是我的静态语言。

Answer 4

系统级开发是一个关键的软件组，通常不应该是动态语言。 （驱动程序，内核级别的东西等）。

基本上任何需要具有的性能和低级别的硬件访问每盎司，应该是在一个较低的水平语言。

另一个指标是如果它是高度数字运算，如科学数据的数字运算。也就是说，如果它需要快速运行并进行数字运算。

我认为一个共同的主题是处理器密集型的问题......在这种情况下，你会很容易看到的性能差异，你会发现，动态语言就是不能让你有效地使用硬件的功率。

这就是说，如果你是做处理器密集型的工作，你不介意的性能命中，那么你仍然可以潜在地使用动态语言。

---

更新：

注意，对于数字处理，我是说真的长期运行在科学领域的数字运算，其中进程正在运行数小时或数天......在这种情况下，2倍的性能增益是极大的相...如果它的规模小得多，那么动态语言仍然可以使用。

Answer 5

interop怎么样？是否有可能从Ruby或Python调用COM组件？

Answer 6

动态语言完全可以使用Interop。 （还记得经典的Visual Basic，它有“懒惰绑定”？）它需要COM组件编译一些额外的，虽然帮助他们的呼叫者按名称呼叫。

我不认为数字运算必须被静态编译，最常见的是如何解决的问题。 Matlab是数字运算的一个很好的例子，它有一个非编译语言。然而，Matlab对数字和矩阵有非常特定的运行时间。

Answer 7

我相信你应该总是选择静态类型的语言尽可能。我并不是说C＃或Java具有良好的静态系统，但C＃正在接近。良好的type inference是关键，因为它会给你动态语言带来的好处，同时还给你静态类型的安全和功能。问题解决了 - 没有更多的火焰战。

Answer 8

嵌入式系统的系统级代码。一个可能的问题是动态语言有时会隐藏单个简单前瞻性语句的性能影响。

像这样说的Perl声明：

@contents = <FILE>; 

如果文件是一个几兆，那么这是一个消耗资源的语句 - 你可能会耗尽你的堆，或导致看门狗超时，或一般减缓嵌入式系统的响应。

如果你想“更接近金属”，你可能想要使用静态类型和“中等”语言。

Answer 9

视频卡的设备驱动程序

Answer 10

在很大程度上，编程语言是一种风格的选择。使用你想使用的语言，你将获得最大的生产力和快乐。如果出于某种原因，这是不可能的，那么希望你的最终决定将基于一些有意义的事情，比如你必须面对的平台或真实的经验性能数字，而不是别人的任意样式选择。