.net - c# 环境中动态功能运行时的 future ？

Question

因此，c# 已经演变为静态类型语言，并且在使用 .net 框架开发业务线应用程序方面做得非常出色。

现在，很明显，在最近的过去，微软已经开始向其他基本范式飞跃，直到最近，c# 和 .net 才真正声称自己是工具。

其中之一是 DLR

好的语言多样性 - 太好了，我在想，只是现在看来，如果我想利用该功能，我必须改变我在编写业务实体时的思维方式......这很酷，而且我我都在学习新东西。但在此之前，我有一些关于这方面受人尊敬的社区的问题。现在为了澄清起见，我对 DLR 和 CLR 的应用更感兴趣。

所以我们开始:

在您看来，DLR 是否是一个值得从企业商业软件开发的角度看待的可行功能？意思是，c# 真的需要将其作为一项功能来继续做它正在做的事情，还是在那时切换到标准的动态类型语言更有意义？

与 CLR 和 DLR 结合开发和编写代码在业务适用性方面的优势在哪里？具体的例子对我来说是最有值(value)的。

好处。

现在msdn这样说:
Provides Future Benefits of the DLR and .NET Framework
Languages implemented by using the DLR can benefit from future DLR and .NET Framework improvements. For example, if the .NET Framework releases a new version that has an improved garbage collector or faster assembly loading time, languages implemented by using the DLR immediately get the same benefit. If the DLR adds optimizations such as better compilation, the performance also improves for all languages implemented by using the DLR.
很好，但究竟如何？如果我只是升级我的框架，我不会得到同样的结果吗？为什么我需要为此写在 DLR 中？

您能否发布代码示例以展示 DLR 可以比常规 c# 做得更好？

学习成为一名有市场的 .net 工程师是否值得，或者只是说:“哦，我们比 Ruby 更好，因为我们也可以做得更多”，这或多或少是一个独立的特性？

将这两者结合起来或仅在应用程序中单独使用 DLR 的开销是多少？发展？

DLR 可以与 f# 一起使用吗？

问候。

Answer 1

可能值得澄清的是，DLR 是一个位于 CLR 之上的 API，以降低实现动态类型语言功能的阈值。您可以像 IronPython、IronRuby、Clojure 和其他语言一样端到端使用它来实现您的语言。您可以像 C# 或 VB 一样使用它来获取动态调用站点缓存(搜索内联多态缓存以获取有关概念的一般信息)。所以，C#添加了'dynamic'关键字，它使用了DLR的CallSites、binders、DynamicMetaObjects等，来实现这个语言特性。

是的，DLR 是一个可行的功能，并且对 C# 有意义。 C# 落后于 VB，用于 COM 互操作、无类型数据源(DB、XML 等)，以及用于网页后面的轻量级语法(例如 button.text = "yo")。当我喜欢一种语言，发现它普遍有用，或者已经调整了我的能力时，我喜欢尽可能多地使用这种语言。我不想通过使用多种语言拼凑并在我的解决方案中产生维护开销，除非我真的需要这样做。 C# 的“动态”让我可以用一种更简单、更美味的方式来完成我在 C# 中已经可以做的事情，这当然意味着我不必求助于纯动态或可选的显式类型语言来更轻松地编写更多代码现在的情况。

如果您尝试将动态类型功能添加到语言或大型、丰富的系统中，使用 DLR 开发代码会大放异彩。正如经常引用的那样，“任何足够复杂的......程序都包含一个特别的......实现...... Lisp。”如果您发现您需要对数据或对象进行一些动态类型的访问，并在给定一些输入的情况下计算某个操作的含义，并希望缓存该操作以在程序中的该位置进行后续类似计算，那么 DLR 可以帮助您做到这一点以更低成本的方式。问题是，您甚至可能不需要在此级别使用 DLR，因为 C# 为您引入了“动态”。但是，您可能希望在表示您的数据源的某些对象上实现 IDynamicMetaObjectProvider，以便它们可以参与 C# 的动态调度调用站点执行的绑定(bind)操作。例如，如果 XmlElement 实现了 IDMOP，那么您可以编写如下内容:
动态 x = source.GetXmlElement(…);
… x.Customers[i].Address.City == "Erie"…

好处是针对本质上是动态的数据或对象编写的代码具有更高程度的可表达性，而不必表达复杂的中间类型声明并执行大量 o.GetBlahByName("whatever") 调用。

您从 DLR 文档中引用的段落是关于基于 DLR 的语言实现。是的，当然您的应用程序也能从中受益。重点更多地在于，例如，IronPython 如何变得更快，这不仅是因为 DLR 的出现，还因为 CLR 本身的工作间接改进了 DLR 上的 IronPython 实现。

除非您需要为您的语言或系统添加一些缓存的动态访问权限，否则不要费心学习 DLR。大多数人不会以这种复杂程度进行编码。大多数人使用语言和框架，很少有人实现它们。

F# 可以使用 DLR，但一个常见的误解是 F# 是一种动态语言。它不是。它是严格静态类型的，但并不是在所有情况下都显式类型，这是让人困惑的地方。由于大量使用类型推断和重要的空白，它在语法上看起来很轻巧。如果有一天 F# 决定像 C# 那样添加一个“动态”类型模型，那么使用 DLR 来简化实现并与 C#、.NET 上的动态语言、动态库和框架进行互操作是有意义的， ETC。

账单