我们的基于.NET的集成开发环境需要使用什么脚本语言？

Question

我们有一个用于机器自动化的IDE，允许用户通过可视化地连接对象和组件来开发解决方案。他们也可以使用C++和C#编写"插件"。该IDE是使用.NET编写的。它的用户通常不是传统的软件开发人员和程序员，而更多地是技术/电气和自动化工程师，但他们都需要了解C#和C++编程的基础知识。

如果我们要为IDE本身引入宏/脚本语言，包括交互式控制台（仅在设计时），应该选择哪种语言？它应该是一种动态脚本语言，既具有良好的.NET和DLR基础，又具有良好的支持和不错的势头，但对我们特殊的开发人员来说学习曲线不应太陡峭。理想情况下，如果您了解C++和/或C#，它应该完全直观易用 - 即使您不是一名坚实的软件开发人员。

更新： 目前对我们最有吸引力的选择是使用动态编译的C#。我们的用户可以继续使用C#。正如CSI所证明的那样，甚至似乎可以构建一个交互式控制台。你对这个选择有什么看法？有没有潜在的陷阱/缺点，我们（由于我们在脚本方面缺乏经验）尚未意识到的？

- bitbonk

---

嗯，看起来 DLR 在未来不会得到支持，所以你要么放弃“未来可靠性”的要求，要么使用除了 DLR 之外的其他东西。 - Richard Anthony Freeman-Hein

@Richard - 他们为什么要那样做？ - ChaosPandion

它被合并到.NET 4.0框架中，并被C#的dynamic关键字使用。这并不是即将死亡的迹象。 - Hans Passant

@Lucas 嗯，IronRuby已经死了，而IronPython存活的疑虑很大，如果两者都不能存活，那么DLR也就没有意义了。请参见http://channel9.msdn.com/forums/Coffeehouse/565848-IronRuby-dead/和http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html。 - Richard Anthony Freeman-Hein

@Hans 和 Lucas：嗯，好的，我以为它们只是在 CLR 中使用了 DLR 技术进行动态支持，我错了。但根据事情的描述，IronRuby 和 IronPython 未来可能不会得到任何微软支持。那么社区将被期望接管，因为它们是开源的（采用 Apache 许可证）。 - Richard Anthony Freeman-Hein

Answer 1

我认为我们要么自己开发基于C#的脚本环境，类似于非常酷的CS-Script的简化版本，要么立即集成CS-Script。

- bitbonk

Answer 2

Python (IronPython)是我推荐的语言。它是一种动态语言，可以用于编写.NET程序的脚本，并且可以交互式地使用（虽然我没有尝试过IronPython的交互式使用，但你可以使用“常规”的Python）。不幸的是，对于C++和C#开发人员来说，这可能并不完全直观。

你可以使用C#作为你的脚本语言（你可以在运行时编译和执行代码），但你将无法获得交互式控制台，也不像脚本一样方便。

我认为简单性在脚本语言中非常重要。“Hello World”在Python中只需要写print "Hello World"，而在C#中，则需要命名空间、类、静态Main方法等。如果你想使用C#，你可以在编译之前将用户提供的代码包装在一个函数定义（或至少一个类）中，使他们的“脚本”可以简单地成为函数内容。这会在一定程度上限制他们在脚本中所能做的事情，这可能是好事或坏事，这取决于你想要什么。如果他们需要多个类和函数，也许他们需要编写一个完整的插件。

- Bob

---

“script-like” 在现实生活中实际上是什么意思？哪些特性使得脚本语言具有重要/有用的功能，而 C# 没有呢？ - bitbonk

我的评论变得过长，所以我编辑了我的回答。另外，区分脚本语言的主要特征之一是非常动态（和动态类型）。虽然在.NET 4.0中有新的动态扩展，但C#仍然是一种相对静态（和静态类型）的语言。 - Bob

那么动态类型语言的主要原因是为了能够输入更少的字符吗？ - bitbonk

不，那是两个不同的问题。另外，“动态”语言并不一定是动态类型的。如果我的回答有点令人困惑，我很抱歉。 - Bob

我认为“脚本语言”应该简单易懂，因为你的用户可能不是专业程序员。如果需要更强大和复杂的功能，我认为有很多基于C#的脚本选项可供选择。我编写了自己的解释器SILK，旨在使其更加简单易用。 - Jonathan Wood

Answer 3

我在一个应用程序中嵌入了一个小的C#编辑器，并编译/运行结果。

ala

var codeProvider = new CSharpCodeProvider( 
              new Dictionary<string, string> { { "CompilerVersion", "v3.5" } } );

var parameters = new CompilerParameters( );
// add any of your 'library' dlls as references
parameters.ReferencedAssemblies.AddRange( dlls.ToArray( ) );
parameters.OutputAssembly = outputPath;
CompilerResults r = codeProvider.CompileAssemblyFromFile( parameters, sourceFiles );

- µBio

---

C# 对我们的用户来说最具吸引力。我们只需要确保通常在脚本环境中所期望的一切（例如交互式控制台）都实际存在。 - bitbonk

Answer 4

如果你看一下微软在脚本/自动化产品方面的发展，PowerShell 就是你需要关注的东西。

开发你自己的主机和提供程序应该很好地集成到你的 .NET 应用程序中。

- Filburt

Answer 5

对于目前支持的动态语言IronRuby和IronPython，未来并不明朗。微软在这两个方面的方向还不清楚。在我听到Gu或更高层次的人发表意见之前，我会避免对其中任何一个做出决定。但这并不能帮助你今天为你的用户做出设计决策。我感觉IronPython将保留支持，但这只是毫无根据的猜测。

对于.NET脚本编程，也可以考虑Boo。

Boo是一种面向对象、静态类型的编程语言，旨在利用公共语言基础设施对Unicode、国际化和Web应用程序的支持，同时使用类似Python的语法1，并特别关注语言和编译器的可扩展性。一些值得注意的特点包括类型推断、生成器、多方法、可选鸭子类型、宏、真正的闭包、柯里化和一级函数。

• Boo官方网站
• Boo维基百科条目

- p.campbell

---

动态语言运行时（DLR）是.NET Framework 4中的一个新API。它提供了支持C#中动态类型的基础设施。 - µBio

@Lucas：复制/粘贴的东西非常棒。 C#是编译的，而不是解释的。原帖想要动态脚本语言的选项。不确定你的评论与Boo有什么关系。 - p.campbell

你说“DLR的未来并不明朗”。实际上，它的未来很明确，除非微软想在C# 5+中替换它。即使他们这样做了，DLR本身也会一直安全，直到C#4不再受支持。 - µBio

@Lucas：确实，你说得对。DLR已经就位，并且将至少在.NET 4存在，并希望更长时间地存在。我应该纠正我的措辞。 - p.campbell