在哪些领域使用 F# 比 C# 更合适? [英] In what areas might the use of F# be more appropriate than C#?

问题描述

在过去的几年里，F# 已经发展成为微软完全支持的语言之一，它采用了在 OCaml、ML 和 Haskell 中孵化的许多想法.

Over the last few years F# has evolved into one of Microsoft's fully supported languages employing many ideas incubated in OCaml, ML and Haskell.

在过去几年中，C# 通过引入越来越多的函数式语言特性来扩展其通用特性:LINQ(列表推导式)、Lambdas、闭包、匿名委托等等......

Over the last several years C# has extended its general purpose features by introducing more and more functional language features: LINQ (list comprehension), Lambdas, Closures, Anonymous Delegates and more...

鉴于 C# 采用这些函数式特性和 F# 的分类法作为一种不纯的函数式语言(它允许您访问框架库或在调用函数时更改共享状态，如果您愿意的话)这两种语言之间有很强的相似性，尽管每个都有自己的极端相反的主要重点.

Given C#'s adoption of these functional features and F#'s taxonomy as an impure functional language (it allows YOU to access framework libraries or change shared state when a function is called if you want to) there is a strong similarity between the two languages although each has its own polar opposite primary emphasis.

我对在您的生产多语言程序中使用这两种语言的任何成功模型以及您在过去一年左右用 F# 编写的生产软件(Web 应用程序、客户端应用程序、服务器应用程序)中的领域感兴趣以前会用 C# 编写.

I'm interested in any successful models employing these two languages in your production polyglot programs and also the areas within production software (web apps, client apps, server apps) you have written in F# in the past year or so that you would previously have written in C#.

推荐答案

我编写了一个应用程序，用于平衡发电站组合的国家发电计划与能源公司的交易头寸.客户端和服务器组件是用 C# 编写的，但计算引擎是用 F# 编写的.

I have written an application to balance the national power generation schedule for a portfolio of power stations to a trading position for an energy company. The client and server components were in C# but the calculation engine was written in F#.

使用 F# 来解决此应用程序核心的复杂性问题，清楚地展示了企业软件中语言的最佳位置，即大型数据集的算法复杂分析.我的经历是非常积极的.特别是:

The use of F# to address the complexity at the heart of this application clearly demonstrates a sweet spot for the language within enterprise software, namely algorithmically complex analysis of large data sets. My experience has been a very positive one. In particular:

计量单位 我工作的行业充斥着各种单位.我实现的方程(通常是几何性质的)处理时间、功率和能量的单位.让类型系统验证函数输入和输出单元的正确性可以节省大量时间，无论是在测试还是阅读/理解代码方面.它消除了以前系统容易出现的一整类错误.

Units of measure The industry I work in is littered with units. The equations I implemented (often of a geometric nature) dealt with units of time, power and energy. Having the type system verify the correctness of the units of the inputs and outputs of functions is a huge time saver, both in terms of testing and reading/understanding the code. It eradicates a whole class of errors that previous systems were prone to.

探索性编程 与更传统的编辑/编译/运行/测试循环相比，使用脚本文件和 REPL (F# Interactive) 使我能够在提交实施之前更有效地探索解决方案空间.对于程序员来说，这是一种非常自然的方式来建立他们对问题和游戏中的设计张力的理解.

Exploratory programming Working with script files and the REPL (F# Interactive) allowed me to explore the solution space more effectively before committing to an implementation than the more traditional edit/compile/run/test loop. It is a very natural way for a programmer to build their understanding of the problem and the design tensions in play.

单元测试 使用无副作用函数和不可变数据结构编写的代码很容易测试.没有复杂的依赖于时间的交互来搞砸事情，也没有要模拟的大量依赖项.

Unit testing Code written using non-side effecting functions and immutable data structures is a joy to test. There are no complex time-dependent interactions to screw things up or large sets of dependencies to be mocked.

互操作 我在 C# 中定义了计算引擎的接口，并在 F# 中实现了计算.然后可以将计算引擎注入到任何需要使用它的 C# 模块中，而无需担心互操作性.无缝的.C# 程序员永远不需要知道.

Interoperation I defined the interface to the calculation engine in C# and implemented the calculation in F#. The calculation engine could then be injected into any C# module that needed to use it without any concerns at all about interoperability. Seamless. The C# programmer need never know.

代码减少 输入计算引擎的大部分数据都是向量和矩阵的形式.高阶函数以最少的麻烦和最少的代码将这些作为早餐.很漂亮.

Code reduction Much of the data fed into the calculation engine was in the form of vectors and matrices. Higher order functions eat these for breakfast with minimal fuss, minimal code. Beautiful.

缺乏错误 函数式编程可能会让人感到奇怪.我可以研究一种算法，努力让代码通过类型检查器，但是一旦类型检查器满意，就是这样，它就可以工作了.它几乎是二进制的，要么无法编译，要么正确.奇怪的边缘情况错误被最小化，递归和高阶函数删除了大量引入边缘情况错误的簿记代码.

Lack of bugs Functional programming can feel strange. I can be working on an algorithm, trying hard to get the code to pass the type checker but once the type checker is satisfied thats it, it works. Its almost binary, either it wont compile or its correct. Weird edge case errors are minimised, recursion and higher order functions remove a lot of book-keeping code that introduces edge case errors.

并行性 最终实现的功能纯度使得利用处理数据向量的内在并行性变得成熟.也许这就是我接下来要去的地方，因为 .NET 4 已经出来了.

Parallelism The functional purity of the resulting implementation makes it ripe for exploiting the inherent parallelism in processing vectors of data. Maybe this is where I will go next now that .NET 4 is out.

这篇关于在哪些领域使用 F# 比 C# 更合适?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！