什么时候应该使用脚本语言而不是像 C++ 这样更冗长的编译语言。C# 还是 Java?
为了让这个问题更有趣,让我们回答这样的问题:
当...空白...时,您应该使用脚本语言
当你需要 A 时,使用脚本语言 X。
当您需要 B 时,请使用脚本语言 Y。
当您需要 C 时,请使用脚本语言 Z。
什么时候应该使用脚本语言而不是像 C++ 这样更冗长的编译语言。C# 还是 Java?
为了让这个问题更有趣,让我们回答这样的问题:
当...空白...时,您应该使用脚本语言
当你需要 A 时,使用脚本语言 X。
当您需要 B 时,请使用脚本语言 Y。
当您需要 C 时,请使用脚本语言 Z。
当开发速度比执行速度更重要时,您应该使用脚本语言。
添加脚本语言作为大型编译系统的组件是一种常见模式:系统的编译部分针对执行速度进行了优化,但更难修改(因为必须编译和重新加载),而系统的脚本部分该系统针对灵活性进行了优化,运行速度较慢,但任何人都可以使用文本编辑器快速轻松地进行修改。
如果您想让应用程序的部分功能易于定制,您将使用此模式。
这有点宗教问题。我将脚本语言用于临时任务,例如:
所有这些也可以用编译语言来完成,但对我来说,用脚本语言来完成它们更快更容易(我使用 ruby,但 PERL 和 python 就可以了)。
我倾向于使用脚本语言进行快速原型设计、实验和数据处理。例如,如果我有一堆文本文件需要预处理并作为一次性操作构建到数据库装置中,我通常会编写脚本。
然而,如今,“脚本”和“编译”之间的界限变得越来越模糊,出现了像 groovy 和 ruby 这样的语言。对于上面提到的任务,我将使用 ruby,但我也将使用它来构建一个带有 rails 的生产 webapp。我将用 java 编写桌面应用程序,但 groovy 也允许我融入脚本。即使在用 C/C++ 编写时,我发现一个有用的模式是嵌入特定领域的脚本语言(例如 tcl,虽然我不太喜欢那种语言)。
我认为语言的实际选择是一种宗教选择,尽管有一些显而易见的权衡(例如可读性 - perl 很有用,但太容易编写神秘的脚本。在某些方面它是“只写”语言 :-)。在过去,我使用过 bash+awk+sed、一些 perl、ruby 等……对于一次性任务,这主要取决于您和您团队的其他成员对什么感到满意。这些天我有意识地选择使用 ruby,即使我在 bash/awk/sed 中做同样的事情会更快一些,但这只是为了通过在其中做尽可能多的任务来提高我的 ruby 技能。
这是我的层次结构:
尝试使用 grep。
如果你不能用 grep 做到这一点,请使用 sed。
如果 sed 不够强大,请使用 awk。
如果 awk 不够强大(或开始变得非常难看),请使用 C、C++ 或您选择的其他成熟的通用编程语言。
请注意,在 awk 和 C 之间没有“脚本语言”。这是故意的。
我发现脚本语言在有适合该语言优势的特定任务时非常有用(例如,使用 perl 进行字符串处理,使用 ruby 进行 Web 开发等等)。特别是对于 Web 开发脚本语言具有更快地向您显示代码更改结果的特性。
在某些情况下,您将编译语言与脚本语言混合在一起——比如在某些游戏中。当您可以在脚本语言中比在编译语言中更快、更清晰、更简单地表达少量行为时,这样做很有用。例如,C++ 是一种表达能力很强的语言——但它的开发成本比 lua 高。
我认为何时使用脚本语言没有一般规则。脚本语言很容易开发,但有时很难维护,尤其是当脚本应该在不同平台(操作系统)下运行时。
脚本语言的优点当然是:
反派是:
我使用脚本语言来挖掘数据并将它们作为 cron 作业提供给数据库。它更容易,因为我可以在 unix 中使用 windows 调度程序或 crontab 轻松设置它们,并且由于 perl 中的一些关键特性(如 regex),我发现它更容易编写。
加上 CPAN 提供给我的数百万个模块......
当交互操作很重要时使用脚本语言,例如命令行外壳,或者您正在导出功能供其他用户在简单操作中使用。(他们不应该编译;脚本就足够了)
如果您打算编写一次或保持简单,请使用脚本语言。一旦您的项目变得更大,强类型语言会更好。想想看,一个大型项目花费了多少时间进行初始开发与集成和维护。您是否愿意维护大量脚本或强制类型行为的强类型语言?