动态和静态语言之间的架构差异

在设计将基于静态语言（例如C＃或Java）和动态语言（例如Ruby或Python）构建的应用程序时，在体系结构上是否存在重大差异？

哪一种设计可能对某一种类型是好的选择而对另一种却是不好的呢？一种类型可以实现任何其他类型都不能实现的有用功能（当然在设计和体系结构上）？

另外，是否有任何动态特定的设计模式？

让我们直接讲几件事：

1. 交互式脚本和静态语言不是相互排斥的。F＃和Haskell都具有REPL接口。
2. 动态语言和高性能并不是相互排斥的，尽管有一些优化。如今，JavaScript在大多数浏览器上都能快速运行。
3. 即使使用动态语言，您仍然需要记录，记住和考虑类型。
4. 由于类型推断的日益普及，许多静态语言不必再频繁地注释类型了。在具有强类型推断的静态语言中，编译器会在大多数情况下从代码中找出类型，并告诉您是否做过违反类型定义的事情。就语法而言，这提供了两全其美的优势。
5. OOP和动态语言不是互斥的。PHP现在支持类，甚至继承。

除了所有这些令人惊讶的相似之处，还有一些实际差异确实会影响开发过程：

1. 动态语言提供了一种有趣的方式来传递小数据。
2. 静态语言使您无法进行多种错误，从而减少了测试量。
3. 同样，静态语言允许有趣的验证和自动转换功能，例如F＃中的度量单位。
4. 更极端的是，静态语言允许代码协定和形式验证，从而可以记录和扩展防止潜在的零除，无限循环，空引用，无效的列表大小或索引，范围错误和其他逻辑上无效的状态之类的东西。您可能会定义。
5. 更进一步，可以基于这些静态约束进行CPU优化，从而获得更好的性能。

如果没有静态类型，则永远无法制作出一种程序：Singularity，一种没有硬件进程边界的操作系统。它用少量的C，一些C＃和称为Spec＃的C＃方言编写，该方言支持代码协定。

尽管是用垃圾收集的语言编写的，但由于所有进程都在一个内存空间中运行，并且由于进行了正式的验证优化，因此该OS上的多任务处理和进程间通信性能实际上比那里的其他任何工具都要好。上文提到的。如果没有静态类型，您将无法做到这一点，因为为了使程序不能够危害系统的其余部分，通信对象必须是可静态验证的。

但是，在大多数情况下，架构应该看起来非常相似。在许多情况下，静态语言可能使程序更易于推理，因为类型是定义明确的，但是编写良好的动态语言程序也将至少具有在开发人员心中定义明确的类型。

有很大的体系结构差异。性能。

根据您的硬件预算，预期的工作量和服务水平协议，可能无法使用动态语言来满足要求。

动态语言提供的开发速度和灵活性通常可以抵消较慢的响应时间，较高的cpu和内存消耗。但是对于具有预算或性能约束的大型系统，动态语言的开销可能会很高。

我从来没有想过这些方针。因此，什么时候使用Google，彼得·诺维格（Peter Norvig）的博客是最受欢迎的博客之一。它说，某些设计模式比起诸如C ++之类的传统面向对象语言，更容易在动态语言中实现。我认为在设计/架构上也应该有所区别，因为他指出动态语言中的实现更容易。在我进一步学习时，我将尝试在答案中添加更多内容。

在设计将基于静态语言（例如C＃或Java）和动态语言（例如Ruby或Python）构建的应用程序时，在体系结构上是否存在重大差异？

没有。

为动态语言编写精美的框架要容易一些。但这不是应用程序。

哪一种设计可能对某一种类型是好的选择而对另一种却是不好的呢？

没有，真的。

您可以用任何一种语言写好东西。

一种类型可以实现任何其他类型都不能实现的有用功能（当然在设计和体系结构上）？

没有。

区别在于动态语言是“编写，运行，修复”。您可以尝试并快速修复。

静态语言是“编写，编译，构建，运行，修复”。您无法轻松进行实验。

除此之外，它们的功能几乎相同。

是否有任何动态特定的设计模式？

也许。Python eval()和execfile()函数（以某种方式）指出了一种动态语言功能，该功能很难（但几乎不可能）以静态语言进行处理。在同一进程空间中编译和执行代码将需要很多代码行。

它不是动态语言特定的。这很容易。