选择脚本语言而不是 C# 的原因是什么？
选择非 DSL 脚本语言而不是静态编译语言（例如 C#）的原因是什么？
-编辑- 到目前为止很好的答案。 我觉得我应该进一步解释一下。 我很确定人们使用 Python 而不是 C# 的原因不仅仅是品味，还有其他情况下使用 C# 而不是 Python。
What are reasons to choose a non DSL scripting language over statically compiled language such as C#?
-edit-
Good answers so far. I feel I should explain further. I am pretty sure people use Python over C# for more reasons than just taste and C# over Python for other situations.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
我想在列表中添加另一点：用户定义的逻辑。
如果您编写的软件需要用户定义一些逻辑以使程序正常工作，那么像 Python 这样的脚本语言是理想的选择。 用例包括游戏任务脚本、数据集统计评估和邮件过滤器等。 要设置复杂的过滤规则，您不希望用户启动 Visual Studio 将某些代码编译到 DLL 中，然后将 DLL 作为插件加载，您只希望用户提供定义过滤器的一些文本定义过滤逻辑。
当您的软件是用脚本语言编写时，包括用户编写的代码通常是微不足道的。
I would like to add another point to the list: user defined logic.
If you write a software where the user is supposed to define some logic for the program to work, scripting languages like Python are the ideal choice. Use cases include things like, e.g., mission scripting for games, statistical evaluation of a data set, and mail filters. To setup a complex filter rule, you do not want your user to start up Visual Studio to compile some code into a DLL and then load the DLL as a plugin, you just want the user to provide some textual definition of the filter that defines the filtering logic.
When your software is written in a scripting language, including user written code is usually trivial.
仅使用过静态类型语言的程序员可能会认为这是一种必要的做事方式。 一旦您体验了鸭子类型，您就会意识到多态性真的可以这么简单 - 不需要所有额外的代码行来指定类型。
所有类型声明的东西都不是程序工作所必需的——这解放了经验——它只是让编译器可以检查某些类型的错误。
如果您不使用动态语言进行测试，则可能会遇到编译器在静态类型语言中捕获的运行时错误 - 但事实证明，这对于静态类型语言来说并不像您那样有利可能会想，因为无论如何你都应该用两种类型的语言进行测试。 您需要使用静态类型语言进行测试，以捕获类型检查无法捕获的其他逻辑错误 - 并且在许多情况下，通过的这些类型的测试无论如何都会排除与类型相关的错误 - 因此您不需要足够的额外内容使用动态语言进行测试以抵消您不必执行的类型声明编码。
结果不仅是提高了生产力，而且是专注于你想做的事情、问题的症结所在的乐趣，而不是陷入告诉编译器一堆东西的困境，这样它就可以保护你免受错误的影响。无论如何都要（至少应该）进行测试。
性能是一种权衡，因为动态语言在运行时不能承担这么多 - 但很多时候性能不是问题。 当它出现时，您可以用较低级别的语言重写性能关键模块。 像 Python 这样的语言让这一切变得简单。
具有类型推断功能的语言是值得考虑的中间立场。
Programmers who have only used a statically typed language may just accept that that's a necessary way of doing things. Once you experience duck typing, you realize that polymorphism can really be just that simple - without all the extra lines of code to specify types.
All that type declaration stuff is not required for the program to work - and this is liberating to experience - it is merely so the compiler can check for certain types of errors.
If you don't do testing in a dynamic language, you can get hit by run-time errors that the compiler would catch in a statically typed language - but it turns out this is not as much of a win for statically typed languages as you might think, because you should be doing testing in both types of languages anyway. You need to test in statically typed languages to catch the other logical errors that the type checking won't catch - and in many cases, those types of tests passing would rule out the type related errors anyway - so you don't need enough extra testing in dynamic languages to offset the type declaration coding you don't have to do.
The result is not just increased productivity, but the pleasure of just focusing on what you want to do, the crux of the problem, rather than getting bogged down in telling the compiler a bunch of stuff so it can protect you from errors you're going to (should, at least) test against anyway.
Performance is the tradeoff, since a dynamic language can't assume so much at run time - but a lot of times performance is not the issue. And when it is, you can rewrite the performance critical modules in a lower level language. Languages like Python make this easy.
Languages with type inference capabilities are a middle ground worth considering.
主要缺点是这些功能通常过于强大，如果没有严格的纪律，很容易编写出无法维护的代码。
The main drawback is that those features are often too powerful, and without an strict discipline it's very easy to write code that is unmaintainable.
开发速度 一般来说，脚本语言消除了编译任何东西的需要 - 只需键入并执行它。 一般来说，如果您在调试器中停止它时对其进行编辑，则可以在它运行时键入它 - 无需重新编译，不需要“编辑并继续”支持，什么都没有。
许多脚本语言对静态类型之类的范围也有较少的限制，您可以直接编码，而不必担心字符串是否需要转换为整数，反之亦然，您只需按原样使用它即可工作。 这是好事还是坏事还有待商榷，但我认为这是一种在用于某些任务时有利而对另一些任务不利的事情之一。
附加组件和库通常也更容易使用 - 您不需要注册或安装任何东西，也不需要担心程序集或 GAC 或签名的东西，您只需包含源文件就可以了。
因此，脚本通常是最容易工作的东西，这就是人们使用它的原因。
Speed of development generally, a script language removes any need to compile anything - just type away and execute it. Generally, you can type away as it runs if you edit it whilst you've stopped it in a debugger - no recompile, no need for 'edit and continue' support, no nothing.
Many script languages also have less restrictive scope for things like static types, you can just code without worrying whether your string needs to be converted to an integer or vice versa, you just use it as-is and it works. It's debatable whether this is a good or a bad thing, but I reckon it's one of those things where it's good when used for some tasks and bad for others.
Add-ons and libraries are also generally much easier to use - you don't need to register or install anything, or worry about assemblies or the GAC or signed stuff, you just include the source files and you're done.
So script is the easiest thing to make work in general, that's why people use it.
鸭子打字：如果它走路像鸭子，说话像鸭子，那么它就是鸭子。
Duck typing: if it walks like a duck and talks like a duck, it is a duck.
因为Python就像飞翔：
Because Python is like flying:
可移植到其他平台，以及更简单的开发环境（通常只是文本编辑器，而不是 Visual Studio）。
Portability to other platforms, and simpler development environment (usually just a text editor, not Visual Studio).
这有点离题，但问题的措辞将“静态类型”与“脚本”进行了对比，这是一种错误的二分法。 在像 F# 这样的语言中，两者都是可能的，其中有简洁的语法、类型推断和
交互式REPL。 双方都存在一些权衡和紧张关系，但你会得到两全其美的好处。
It's kind of been mentioned tangentially, but the question as phrased contrasts 'statically typed' versus 'scripting', and it's a false dichotomy. It's possible to have both, in languages like F#, where there is succinct syntax, type inference, and an
interactive REPL. There are some trade-offs and tensions on both sides, but you get a lot of the best of both worlds.
根据我的经验，在开始设计/编码之前，有两件事是您必须做出的最重要的决定：
如果您甚至不了解模板或 OOP 的一般概念，那么使用 C++ 是没有用的。
恕我直言，最重要的一点是，因为 ie 你想像 twitter 一样编码，你可以用 Lisp 编写你自己的全能网络服务器，并将 javascript 或 form-convenience-functions 等东西一起破解 - 但为什么不只使用 ie Tomcat/Java/Wicket或者分别是 Apache/PHP/Synfony？ 因此，所有基础知识都已涵盖、经过充分测试，并且拥有许多在线资源。
更重要的是，您应该考虑 ORM 框架/数据库包装器 - 它们可以节省大量时间和错误 - 如果您需要它们。
经验法则：如果您完全从头开始（即研究），请选择您最喜欢的语言（ofc 对于您的任务来说足够强大），如果您在公共领域（即网站）进行开发，请根据以下情况选择语言您的技能和已有的工具。
如果性能确实是一个迫在眉睫的问题，请坚持使用编译语言。
只是我的 0.02 美元
In my experience two things are the most important decision that you have to make before you start designing / coding:
There is no use in going with C++ if you don't even get the idea of templates or OOP in general.
Imho the most important point, because i.e. you want to code sth like twitter, you can write your own omnipotent webserver in Lisp and hack things like javascript- or form-convenience-functions together - but why no just use i.e. Tomcat/Java/Wicket or respectively Apache/PHP/Synfony? So all the basics are covered, well-tested and with many resources online.
Even more you should consider ORM-frameworks/database-wrappers - they save a real lot of time and errors - if you need them.
As a rule of thumb: If you start completely from scratch (i.e. research) pick the language you like most (and ofc is powerful enough for your task), if you do development in an common field (i.e. websites) pick the language according to your skills and the already available tools.
If performance is really an immediate concern, stick with the compiling languages.
Just my $0.02
脚本语言主要在 2 个领域表现出色：
中小型项目，其中性能不是首要任务，而运行时环境的灵活性才是首要任务。
领域特定语言的构建。 脚本语言的鸭子类型、动态方法调用功能使其成为设计特定领域语言的理想选择。 当然，Ruby on Rails 是这种功能的典型代表，但是还存在许多其他示例，尤其是在专有的内部开发软件中。
Scripting languages excel primarily in 2 areas:
Small to medium sized projects where performance is not a top priority and flexibility in the runtime enviroment is.
The construction of domain specific languages. The duck typing, dynamic method invocation capabilities of a scripting language make it ideal for designing domain specific languages. Ruby on Rails, of course, is the poster boy for this capability, but numerous other examples exist especially in proprietary in-house developed software.