在什么情况下动态语言不合适？ [关闭]

题

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

解决方案

速度通常是主要答案。虽然现在这个问题变得不那么重要了。

其他提示

程序员熟悉语言的熟悉程度和意愿。

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

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

基本上任何需要每一盎司性能或低级别硬件访问的东西都应该是较低级别的语言。

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

我认为一个常见的主题是处理器密集型问题......在这种情况下，您将很容易看到性能差异，并且您会发现动态语言无法让您有效地使用硬件。

也就是说，如果你正在进行处理器密集型工作并且不介意性能上的打击，那么你仍然可以使用动态语言。

更新

请注意，对于数字运算来说，我的意思是在科学领域真正进行长时间运行数字运算，这个过程运行了几个小时或几天...在这种情况下，2倍的性能提升是GINORMOUS ......如果它的数量要小得多规模，然后动态语言仍然可以使用。

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

视频卡设备驱动程序

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

使用动态语言绝对可以实现Interop。（记住经典的visual basic，它有“lazy binding”？）它需要编译一些额外的COM组件，以帮助他们的调用者按名称调用。

我不认为数字运算必须是静态编译的，通常是你解决的问题。 Matlab是一个用于数字运算的好例子，它有一个非编译语言。但是，Matlab具有非常特定的数字和矩阵运行时。

我相信你应该尽可能选择静态类型的语言。我不是说C＃或Java有很好的静态系统，但C＃越来越近了。良好的类型推断是关键，因为它会给你带来动态语言的好处，同时还能给你带来好处静态类型的安全性和特征。问题解决了 - 没有更多的火焰战。

嵌入式系统的系统级代码。一个可能的问题是，动态语言有时会隐藏单个易于查看的语句的性能影响。

就像说这个Perl声明：

@contents = <FILE>;

如果FILE是几兆字节，那么这是一个耗费资源的语句 - 您可能会耗尽堆，或导致监视程序超时，或者通常会降低嵌入式系统的响应速度。

如果您想“更接近金属编程”，您可能希望使用静态类型和“中间级别”。语言。

互操作怎么样？是否可以从Ruby或Python调用COM组件？

许可以下： CC-BY-SA 和归因