问题描述
我刚刚读完了一本关于 Scala 的书.让我印象深刻的是，整本书中的每一个例子都是以某种形式出现的数字.
I just finished reading a book on scala. What strikes me is that every single example in the whole book was numerical in some form or another.
像许多程序员一样，我使用的唯一数学来自离散和组合数学，通常这不是我以明确方式编程的数学.我真的错过了一些令人信服的示例，它们是常规 oo 算法的功能替代/补充.
Like a lot of programmers, the only math I use is from discrete and combinatorial mathematics, and usually that's not math I program in an explicit way. I'm really missing some compelling examples of functional alternatives/supplements to regular oo algorithms.
函数式编程有哪些非数值用例?
What are some non-numerical use-cases for functional programming ?
推荐答案
我的公司要求我编写一个自定义应用程序，允许用户对平面文件数据库执行即席查询.这个应用程序的用户是典型的乔商人类型.他们不是程序员，他们在生活中不太可能见过 SQL 语句.
My company asked me to write a custom application that allowed users to perform ad hoc queries against a flat-file database. The users of this app were your typical Joe Businessman types. They are not programmers, and its unlikely they have ever seen an SQL statement in their lives.
因此，我的任务是开发一个友好的用户界面，允许用户选择列、表、条件等来构建查询.这很有挑战性，因为我可以在 UI 中表示 SQL 语句，而无需先在内存中创建它的抽象表示.
As a result, I was tasked to develop a friendly userinterface that would allow users to select columns, tables, conditions, etc to build up a query. This is challenging because I can represent the SQL statement in the UI without first creating an abstract representation of it in memory.
第一次迭代是用 C# 编写的.我创建了一个船载类来表示 SQL 语句的抽象语法，这导致了一个非常麻烦的对象模型:
The first iteration was written in C#. I created a boatload classes to represent the abstract syntax of an SQL statement, which resulted in a really cumbersome object model:
- 一个Join类，一个Joins集合类
- WhereClause 类，WhereClause 集合类
- 一个 SelectedColumn 类，SelectedColumns 集合类
- OrderBy 类，OrderBy 集合集合类
- 将所有上述类组合在一起的 SqlStatement 类
将 SqlStatement 实例转换为字符串是极其痛苦、丑陋和错误的.将相反的方向从字符串移动到 SqlStatement 甚至更糟，因为它使用大量正则表达式和字符串操作分解了 SQL 字符串的各个部分.
Converting an SqlStatement instance to a string was gloriously painful, ugly, and buggy. Moving the oppositive direction, from string to SqlStatement, was even worse, as it broke apart the pieces of an SQL string using lots of regex and string manipulation.
我对系统进行了黑客攻击，生成了一个可以运行的应用程序，但我对此并不满意.当应用程序的业务需求对我发生变化时，我尤其不会发生这种情况，这迫使我重新访问我的 C# 代码.
I hacked together the system, produced an application that worked, but I wasn't very happy with it. I especially wasn't happen when the business requirements of the app changed on me, which forced me to revisit my C# code.
作为一个实验，我在 F# 中重写了我的 SqlStatement 并将其表示为联合:
Just as an experiment, I rewrote my SqlStatement in F# and represented it as a union:
type dir = Asc | Desc
type op = Eq | Gt | Gte | Lt | Lte
type join = Inner | Left | Right
type sqlStatement =
| SelectedColumns of string list
| Joins of (string * join) list
| Wheres of (string * op * string) list
| OrderBys of (string * dir) list
type query = SelectedColumns * Joins * Wheres * OrderBys
那少量代码取代了几百行 C# 和十几个类.更重要的是，模式匹配简化了将抽象表示转换为 SQL 字符串所需的过程.
That small amount of code replaced a few hundred lines of C# and a dozen or so classes. More importantly, pattern matching simplified the process required to convert abstract representation into an SQL string.
有趣的部分是使用 fslex/fsyacc 将 SQL 字符串转换回查询对象.
The fun part was converting an SQL string back into a query object using fslex/fsyacc.
如果我没记错的话，原来的 C# 代码总共有 600 行和大约十几个类，还有很多乱七八糟的正则表达式，并且需要两天时间来编写和测试.相比之下，F# 代码由一个大约 40 行的 .fs 文件组成，其中 100 行左右用于实现词法分析器/解析器，并且我每天要花几个小时来测试.
If I remember correctly, the original C# code totalled 600 lines and around a dozen classes, lots of messy regex, and requied two days to write and test. By comparison, the F# code consisted of one .fs file of around 40 lines, 100 lines or so to implement the lexer/parser, and consumed a few hours out of my day to test.
说真的，用 F# 编写应用程序的这一部分感觉就像在作弊，那是多么容易.
Seriously, writing this part of the app in F# felt like cheating, that's how trivially easy it was.
这篇关于函数式编程的非数值用例?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！