【问题标题】:.NET and Dynamic Languages.NET 和动态语言
【发布时间】:2010-10-05 07:13:47
【问题描述】:

当 Microsoft 开始发布 DLR 和相关语言时,您是否计划使用这些语言(例如 Iron Ruby 或 Iron Python)?

如果是这样,您这样做的动机是什么?

【问题讨论】:

    标签: .net dynamic-languages


    【解决方案1】:

    是的,我当然打算找一些非必要的项目来熟悉 IronRuby。

    我确信有真正的项目会从使用动态语言的形式中受益,但我认为在我用该语言编写一些有意义的代码之前我不能正确判断,所以我认为这需要有意识的努力打破先有鸡还是先有蛋的局面。

    我认为 IronRuby 将提供机会专注于语言中的新功能,而不会因新开发环境的差异而分心(我几乎是 C# 语言)。

    我昨天在看IronRuby: The Right Language for the Right Job,所以这可能会影响我的回答;-)

    【讨论】:

      【解决方案2】:

      在某些情况下是的。

      主要动机是重用已经在 Ruby 和 Python 中实现的现有代码和库,从而更轻松地与用 C# 编写的其他代码进行交互。对我来说,这一切都与跨语言集成的好处有关。

      【讨论】:

        【解决方案3】:

        如果它们适合我正在进行的项目,我计划使用它们。如果该项目同样容易用 C# 完成,我可能会坚持使用静态语言,因为 dynamic 关键字将允许许多相同的功能。

        【讨论】:

          【解决方案4】:

          我不是 .NET 开发人员,但考虑到以下条件,我会使用它:

          • 速度/内存消耗(与其他实现相关);
          • 可移植性(或:“它仍然是 Python/Ruby/等吗?同样的代码会在官方实现上运行吗?”);
          • 不错的额外功能(只要它们不会过多地破坏第 2 项)。

          【讨论】:

            【解决方案5】:

            这些语言中的大多数都可以托管在您的应用程序中,这就是有趣的地方。

            如果您正在编写一个允许您的用户编写脚本以实现可扩展性的应用程序,那么您应该考虑使用它们。

            【讨论】:

              【解决方案6】:

              我当然打算看看Cucumber。同样,我认为至少看一下 Rails 和 Django 是我的疏忽。

              【讨论】:

                【解决方案7】:

                没有。除了一些元编程(反射很烂)之外,动态语言对具有良好类型推断的静态类型语言没有任何吸引力。

                一方面,由于 IDE 薄弱而导致的生产力损失相当严重。

                【讨论】:

                  猜你喜欢
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 1970-01-01
                  • 2016-09-26
                  相关资源
                  最近更新 更多