问IT任务: F#脚本与Powershell脚本

EN

当F#更适合我工作的公司、使用它的团队以及手头的任务时，我会选择它。否则我会选择别的。

在没有更多细节的情况下，我不能比这更具体，但我可以建议你应该问的几个问题：

1. 您正在解决的问题是什么？
2. 用哪种语言更容易表达问题的解决方案？
3. 是现有的F#开发人员(例如，考虑到维护此代码的人的学习曲线是管理员(他们通常非常熟悉Powershell，而对F#一点也不熟悉)？

一个相关的提示:不要让大量的语言在您的产品代码和基础设施中开发。

一定要尝试找到最好的语言来解决你遇到的问题，但是如果你在五年的时间里发现有人用公司里任何人都不再理解的语言编写了你解决方案的核心组件，你可能会遇到一个严重的问题。

我个人的经验法则(当然也有例外)是，一个项目应该有一个核心语言和一个脚本语言来将其结合在一起，首先应该选择这些语言来适应问题领域，其次是最大限度地提高整个团队的熟练程度。在产品代码或基础设施中应该强烈反对‘'Pet’。

这取决于你的问题和谁来维护脚本。

PowerShell在管理领域非常强大(处理文件、活动目录、csv/xml、计算机等)，但它的编程能力相当有限(例如泛型)。PowerShell中的线程化并不像它应该的那样简单。但是没有人期望管理员会使用线程。取而代之的是满足管理员需求的后台工作。

另一方面，F#是真正的编程语言，这意味着它是相当低级的，因此很冗长(与PowerShell相比)。在PowerShell中编写的一些任务是一行程序，而在F#中则需要编写大量代码。除此之外，您将如何实现在远程计算机(Invoke-Command -computer myserver ...)上运行命令？

如您所见，这取决于您的问题。

谁来维护脚本也是非常重要的。您可能正在度假，您的同事将需要编辑脚本。这两种语言都需要一些时间来学习。我觉得学习PowerShell更容易；用函数式的方式思考需要低头。

在这个时间点上，如果除了您之外的任何人都可能需要，那么选择用F#编写脚本可能不是一个好主意。

1. 说F#的人很少，所以你创建的脚本很少人能读懂或编辑。
2. fsi可执行文件不是.Net框架附带的，也不是F#运行时重新分发包的一部分(据我所知)。这意味着脚本只能在安装了带有F#工具的Visual Studio的位置执行。

是一个明显的例外，当然，如果你是一个以F#为主要语言的项目的开发人员，因为这将意味着每个重要的人都可以运行和编辑你的脚本。

然而，我不得不说，我认为即使在这种理想/特殊的情况下，如果您的脚本任务涉及PowerShell中预先存在的cmdlet的任务(即:文件系统任务、注册表、数据库维护、active directory、exchange等等)，那么使用F#可能会有更多的工作。当然，如果你正在使用这些脚本作为学习语言的机会，你仍然可以选择这样做，但请记住要点1和2 ;-)