我们都喜欢 UNIX, 喜欢它丰富的小工具和万能的管道, 通过他们组成非常复杂的功能. 本文从 UNIX 这种软件构建风格出发, 探讨它与函数式编程风格的高度吻合, 并进一步讨论一种实用的编程方法和它的作用.
函数式编程, 第一步
grep, sort 等 UNIX 工具都有一致的行为: 从标准输入接受输入, 输出到标准输出. 一致的行为使他们配合起来非常简单. 我们可以以标准工具的组合实现类似 SQL 的查询
# Same as SELECT ... FROM table WHERE ... ORDER BY ... LIMIT ...
# The table content will be provided via standard input
$ (grep regexp | sort ... | head -n ... | cut ...) < table
我们看 ``grep regexp'' 我们说: 把 regexp 参数作用于 grep, 将 生成 一个有标准输入输出行为的 进程. 这说得有点拗口, 它强调了以下几个方面:
- grep 是一个程序 框架, 用于进行文本检索. 它具有通用性, 它的具体行为 (检索什么), 是通过指定正则表达式参数 --- 其实就是一个小程序来定义的.
- 对用户而言, 用户只关心要检索的正则表达式, 并不关心 grep 是怎么完成的 --- grep 倒着搜还是分布式搜, 只要最后能得到结果就行.
- 对 shell 而言, 它只关心调用 grep 后得到的一个有标准输入输出行为的进程, 这样就可以放在管道或输入输出重定向中工作了, 至于用的什么参数调用 grep, grep 到底干什么, 它不关心.
这种 seperate of concern, 是构建更大规模应用的基础. 我们可以把上面的命令写成脚本, 加入几个可配置的参数, 但最重要的一点是, 脚本的行为依然是标准的输入输出行为, 这样我们就可以再递归地把这个脚本用于更大规模的构建中, 直至构造宏大的应用.
这样的模式与我们常见的编程习惯是不一样的, 例如 python 的 filter 函数是:
filtered_list = filter(filter_func, source_list)
写成 UNIX 命令就类似
$ grep filter_regex source_file > filtered_file
如果要在 python 里做与 UNIX shell 里一样的事情, 我们的描述应该是: 将 filter_func 作用与 filter, 它将 生成 一个接受一个数据输入, 返回一个数据输出的 函数. 也就是说, 我们需要一个生成函数的函数. 在 python 里面可以简单实现为:
def Filter(filter_func):
def do_filter(src):
return filter(filter_func, src)
return do_filter
熟悉 python 的同学当然知道可以使用 lambda 简化程序, 但这里我们需要写得更清楚一些. 在这里, 我们做的事情就跟上面叙述的完全一样, 根据一个 filter_func 生成一个拥有标准接口的函数. 在这里, 函数就跟普通对象一样, 是可以动态 "生成" 的, 使用不同参数调用 Filter 的结果是不同的函数, 有不同的过滤行为, 就跟用不同的参数调用 grep 一样. 这就是我们走向函数式编程的第一步 --- 高阶函数 (First-order function). 用 OO 的方法理解也很简单: 所谓函数, 其实就是一个有 "调用" 这么一个标准接口的对象.
PS. 在 lambda 计算理论中, filter(func, data) 只是一个复合函数的糖衣, filter(func) 生成一个 data 的函数. filter(func, data) 和 filter(func)(data) 是等价的. 这就是所谓 curry, 在 haskell 等天然支持 curry 的语言中, 我们是根本不用写上面的 Filter 定义的.
由此, 我们可以做类似:
foo = Filter(filter_func)
bar = Grep(r'regex')
然后把 foo 和 bar 函数用在任何地方. 而且, 这两个函数有完全一样的接口: 接受一个数据输入 (先忽略数据类型), 输出一个数据. 调用他们的人是不用关心他们是怎么生成的. 基于一致的接口, 函数间的协作, 组合都变得很简单. 例如实现一个 Pipeline:
Pipeline(func1, func2, ...)
或者重载 python 的或操作
Pipeline() | func1 | func2 ....
当然, 就跟 UNIX 一样, 合成的结果依然是一个单入单出的函数.
不仅如此, Filter 也是一个单入单出的函数: 接受一个函数, 生成另一个函数. 而它接受这个函数本身也是标准的, 也可以由其他函数工厂生成, 例如有
CheckRegex(r'regex') # 根据正则表达式生成检查函数, 若输入 match 正则则返回 True, 否则 False
bar = Filter(CheckRegex(r'regex'))
这个 bar 实现替代了原来的 Grep, 它进一步分离了执行策略和执行框架, 我们只需实现一个简单的正则比较功能, 套进 Filter 框架就成了 Grep, 假如我们实现了分布式的 Filter, 我们就马上获得了一个分布式 Grep!
这类的函数复合在我们的编程中非常常见. 单参数的函数复合其实就是 Pipeline, 例如上面的例子, 我们可以写成
Grep = Pipeline() | CheckRegex | Filter
当以一个正则表达式为参数调用 Grep 时, 它首先被 CheckRegex 转换为一个输出 True 或 False 的函数, 这个函数再传给 Filter, 就成为了一个真正的 grep 函数.
这是我们迈向函数式编程的第一步: 高阶函数, 把函数当成普通对象, 再把这个普通对象作为处理中的主要对象类型. 你会发现, 在 OO 中熟悉的各种技巧, 抽象, 多态... 能够全部招呼到这个不那么顺眼的对象上. 这可能得花点时间适应, Lennon 说, Imagine there are all functions, it's easy if you try...
懒惰求值
考虑 UNIX 命令
grep regexp largefile.txt | head -n 10
按照最 naive 的想法, 我们的做法应该是列出文件后, 在文件里找出所有符合正则的行, 再将这些行送给 head, 让它选出前 10 行. 这果然很 naive: 反过来想, 只要 head 能够读到 10 行内容, 就可以完成任务了. 而对 grep 来讲, 只要读到的内容中有 10 个匹配, 就不用再做了. 简单点说, 即使 grep regexp 表示 它要完成对输入的所有处理, 但它不必真的完成. 只有当它的下游 (head) 表示需要这个结果时, 它才去做运算.
基于 grep 的按行处理模型, 这是很好处理的事情: grep 每读一行输入, 就进行一次处理, 并将结果输出, 而不是把整个输入读完才进行. 而当下游 head 执行完 --- 表示不再需要输入的时候, head 的推出会导致 grep 收到一个 SIGPIPE, 导致 grep 自然退出, 对 grep 的上游也是如此.
如果我们有脚本:
#!/bin/sh
#largefile_error
grep error largefile.txt
这是一个无需标准输入, 能够直接输出内容的程序. 假如 largeilfe.txt 是一个只读文件, 那么 "./largefile_query 检索词" 实际上表达的是一个虚拟文件: 虽然未经求值, 它的内容是恒定的, 就是 largefile.txt 里含有 error 的行. 我们可以有:
$ ./largefile_error | head -n ...
只有当我们真正需要对 largefile.txt 进行计算时, 脚本里的 grep 才会被执行, 而且就像上面分析的: 只会被执行真正必要的部分. 这显然能够节省大量资源, 在 largefile.txt 是一个无限长度的文件时, 这也是唯一可行的计算方法.
要在 python 中实现它并不难. 假如设有与 Filter 对应的 Map, 一个类列表数据 list, 很容易知道:
((Pipeline() | Map(func_a) | Map(func_b) ...)(data))[n:m] === Map(Pipeline() | a | b)(data[n:m])
显然, 若 n 和 m 比 data 的实际长度小很多 (data 可能是无限长), 后面的计算方式能节省大量的计算. 这跟上面 UNIX 的例子是一样的.
我们可以由此实现一个懒惰计算的类 list 类 Stream
Stream(data, pipeline)
Stream(data, pipeline) & func = Stream(data, pipeline | func)
Stream(data, pipeline)[n:m] = map(pipeline, data[n:m])
我们实现一个 Stream 上的 Map 则是:
def Map(func):
return lambda stream: stream & func
我们精确实现了上面的定义:
Pipeline() | Map(func_a) | Map(func_b) ...
的结果是把各个 map function 加入到 Stream 内部的 pipeline, 将要作用于 Stream 的每一个元素. 但只有当我们明确要求取出数据时, 才会进行真实的计算, 实现了延迟求值.
但是, 它实际上无法实现 Filter, 因为 Filter 的输入和输出不是一对一的. Filter 是通过 python 的 generator 实现的:
def Filter(check_func):
def do_iter(src):
for item in src:
if check_func(item):
yield item
def make_stream(src):
return Stream(do_iter(Stream(src)))
return make_stream
ret_stream = (Pipeline() | (Filter(CheckRegex(r'...'))) | Map(str.upper))(open('src.txt'))
print ret_stream[:5]
这里面发生的事情与 UNIX 更为相似. make_stream 创造了一个新的 Stream, 数据源是 do_iter 产生的可迭代的 generator (请自行参考 python 相关文档). 因此, 到 "ret_stream =" 一行, 得到的 stream 是在 make_stream 的基础上加了个 str.upper 操作. 实际上, 任何实际计算都没有进行. 当执行 print 一行时, Stream 机制会驱动 do_iter 产生的 generator 进行 5 次迭代, 这可能另 "for item in src" 一行中从源数据 (可以作为 iterator 使用的 src.txt 文件对象) 读入多于 5 行数据. 当执行完成, GC 把 ret_stream 回收时, 这些东西都浮云了 --- 发生了部分求值.
即使是一些看起来没办法这么做的功能, 例如排序, 也可以做成懒惰和部分求值. 当调用 Sort(...)(src_data) 时, 可以生成一个虚拟的数组 S, 当因为任何的原因 (例如被下游驱动) 发生 S[:n] 操作时, 只需进行一个 TopN 计算即可, 并且可以做个 cache, 当下次做 S[:m], m > n 时, 只需求一次 Top(M - N). 当作为 Iterator 使用时, 为了防止每次求 Top 1 退化为冒泡排序, 只需再做一些预读工作即可. 总之, 没有必要那么乖地在用户调用时真的把它求出来, 无论用什么办法, 最终结果是对的就行.
无副作用与不可变对象
我们在这里必须注意懒惰求值的一个重要条件: 我在上文举 largefile_error 的例子时, 很不显眼地提到了一个前提: largefile.txt 必须不发生更改, 否则我们的等式不能成立. 这展现了函数式编程中的非常重要的一面: 对象状态不可改变与函数无副作用. 没有这一点. 对于调用 f(obj), 在任何时候都有相同结果, 因为:
- f 没有副作用, 它的结果只依赖 obj 的值, 并且不能改变 obj 和其他系统状态.
- obj 是一个不可改变内部状态的对象. 作用于 f 显然在任何时候都有相同结果.
没有这些条件, 我们上面的讨论都是错误的.
在命令式编程和 OO 中, 我们的全部工作就是在跟各种状态变化周旋, 因此, 上面的要求看起来很难接受. 其实, 我们应该考虑它为数学上的函数: 我说 X = 1, 那不会说它下一刻就等于 2, Y = f(X), 不可能说做多几次它的结果就不同. 我们应该用数学上的 等式变换 的方法来考虑它. 这里不涉及状态和执行顺序的问题. 后文很大一部分内容都必须建立在上述约束之上, 我们会渐渐发现这是一个多么自然的事情.
基于这样的前提, 实际执行 f(obj) 的时机对处理结果是不会有影响的, 系统可以自由地选择什么时候才真正执行它. 很自然地:
- 只有当用户显式要求得到 f(obj) 的结果时, 才执行它, 节省宝贵的 CPU 资源.
- 对 f(obj) 的结果做个 cache, 若在别的地方再次调用, 直接出结果而不用计算.
Stream 的实际实现中正是这么做的.
Curry, 有名管道与 Makefile
如果我们要让查询的正则可设置, 写成 UNIX 脚本会是:
#/bin/sh
grep $1 | upper
如果它是一个函数的话, 它是一个需要接受两个参数的函数: 正则和来自标准输入的待 grep 文本. 这样它就不是一个标准接口的函数了. 但是还记得我们关于 curry 的讨论吗? 在 lambda 运算中, 多参数函数只是一个糖衣. 当然 python 没有这个功能, 需要我们自己实现, 我们实现 Curry. 若 func 是一个接受 N 个参数的函数
Curry(func) = Curry(func, N, ())
Curry(func, N, args)(arg) when len(args) + 1 < N = Curry(func, N, args + (arg,))
Curry(func, N, args)(arg) when len(args) + 1 == N = func(*(args + arg))
另外, Pipeline 对 curry 做一点支持:
func(arg) | others... 若func(arg) 返回一个 Curry 对象 cur, 则 Pipeline 返回
cur | others...
pipeline(Curry(...)) = Pipeline() | Cury(...) | pipeline
pipeline(x, y, ...) = pipeline(x)(y)(...) # 语法糖衣
因此, 若以一个参数调用 Pipeline, 而它又返回一个 Pipeline, 意思就是... 你要再提供一个参数了. 所以, 我更习惯把这里的 Pipeline 称为 Option, 而 "|" 会写为 ">>". 上面例子的计算, 我们可以表达为:
opt = Option() >> CheckRegex >> Filter >> Curry >> Map(str.upper)
stdfun = opt(r'...')
print stdfun(Stream(open('src.txt')))[:5]
我们看到, opt 的前两个操作接受一个正则字符串, 产生一个标准的过滤函数, 而 Curry 接受了这个函数后, 返回了一个 Curry 对象, 表示要更多的参数, Option 在此时也顺水推舟地返回. 因此, 若 Curry 之前得到的函数是 filter_func, stdfun 其实等价于:
Option() | filter_func | Map(str.upper)
后面的流程大家就非常熟悉了. 这就是利用 Curry 解决多个参数的思路. 在处理流程中的任何一步需要额外参数, 并不需要它的上游为其传递, 实际这个额外参数也无需在处理开始时给出 (由于这个 Option 可能要再与其他的处理组合工作, 你根本无法定义什么叫处理开始). Curry 能非常自然地解决这个问题, 只要默念几次: "多参数是浮云, 单入单出函数是唯一的真函数" 就好了.
对于一些更复杂的情况, 例如带 JOIN 的查询
# Same as SELECT * WHERE ... JOIN other-table ....
$ grep ... | join - other-table | grep ... | limit ...
join 的第一个参数来自标准输入 (grep 的结果), 第二个参数则来自一个文件 other-table. 然则, UNIX 的有强大的虚拟文件系统, 这并不一定是一个实际存储的文件. 例如, 它可能是一个命名管道.
$ mknod other-table p
$ grep ... table-source > other-table &
$ grep ... | join - other-table | grep ... | limit ...
此时, other-table 是一个对通过 table-source (天知道它是不是也是个命名管道) 进行过滤处理的结果, 再传送到 join 中, 上文提到的懒惰求值等特性在这里依然适用. 上面的功能虽然还是可以利用 Curry 特性实现, 但显然这种写法更为清楚特别是两张表都特别复杂, 需要多个参数生成时. 在 python 中, 基于 Stream 的懒惰求值特性, 实现上述操作是很自然的:
other_table = Grep(...)(Stream(open('other-table-source')))
result_table = Option() >> Grep(...) >> Join() >> Grep(...)(
Stream(open('table-source'), other-table))
如果说 pipeline 是一种线状的数据依赖/传递关系, 则若引入多参数/curry, 会构成树状依赖关系. 假设上文中 other_table 参与了 result_table 以外的其他计算, 那我们就得到了一个网状关系. 我们会有这样的断言:
- A = f(B, C) => A 依赖 B 和 C
- B 依赖 C 和 D
- D 依赖 C
那么, 若要在一个单处理机上求 A, 我们需要顺序执行 C D B A. 这种依赖关系和相应的处理与 Makefile 很相似: 当依赖关系非常复杂时, 我们可以仅声明对象间的依赖关系, 由类似 make 的框架自动指出执行顺序, 这是我的一个产品级项目的最核心想法. 另外, 若各个函数传递的都是 Stream, 它的懒惰求值特性使得最终都还没有实际逻辑被执行. 当我们真正从 A 拉出数据时, 其他部分会依据依赖关系被驱动, 类似 C 这样的公共依赖会被求值多次 --- 此时, 上文提到的对函数执行结果的 cache 就其作用了.
表意编程
从本文第一节开始, 我们就在抽象执行框架, 努力让执行框架与具体策略分离. 例如 Filter 是一个执行框架, 而具体的过滤函数则是它的具体策略. 抽象执行框架与抽象对象有对等的意义, 抽象了执行框架, 使我说 Filter(func) 的时候, 我只关心得到的函数能够在数据集中选出符合我指定的条件 func 的部分, 而它是顺序找, 倒着找还是并行分布式找并不影响我所关心的结果. 当我们无需关心程序真实的执行方式/流程的时候, 我们正在走向一个表意编程的风格.
在这样的风格中, 我们不试图控制流程, 而是组合组件以产生更大的组件. 我们能在 UNIX 中看到这种方法的巨大威力, 一个复杂的应用能很方便地使用小组件复合而成, 由于每个组件都是无副作用的, 处理结果只与标准输入相关, 它的测试和调试都非常简单. 得到的程序很难出 bug, 效率很好. 无论是开发效率还是程序质量都大大高于自己山寨的版本.
当我们把具体控制流程从程序中抽离, 留下的程序可能由于应用特点的不同呈现完全不同的风格. 它更像是另一种语言 (比如我上面应用 Pipeline 等框架的程序就很不像 python), 它成为一种领域特定语言 (Domain specific language), 根据不同的领域, 有完全不同的描述风格. 精确地说, 这叫 internal DSL. 有了这个基础, 我们可以设计一层很薄的语法外壳, 使它更容易开发和被领域专家理解, 这就称为了 extranal DSL. 当然, 如果你可以像 M$ 一样霸道, 你可以像 LINQ 一样把领域特定语法直接集成进宿主语言.
高阶函数的能力是实现这样的风格的重要一环. 有了用函数生成函数的能力, 可以使执行框架, 策略和策略作用于框架的结果都是有一致接口的函数, 他们的复合就成了非常自然的事情. 我们在上面已经给出了很多的例子. CheckRegex 作为框架, 结合正则策略生成的函数可以作为 Filter 框架的策略, 而应用 Filter 框架的结果又自然能嵌入 Pipeline 作为它的一个处理节点 (策略). 这是我们能用组合而不是流程控制的方法编程的实际保证.
表意编程和命令式编程没有明显的界限, 这往往是一个执行框架的抽象程度和粒度的问题. 但表意式编程区别于命令式编程的一个重要特征是: 程序中没有状态维护的内容. 一旦引入了状态维护, 引入了有作用的函数, 系统就不得不严格根据程序指定的执行序列来执行以保证正确结果, 相对的, 程序员必须管理状态和控制流程的责任, 而无法享受抽象执行框架的好处.
但需要注意的是, 上文引入 join 时出现的赋值语句并不是在做状态维护, 因为 other_table, result_table 自始至终都是一个值, 与其说它是个赋值, 还不如说它是一个简单的等式替换, 就像我在上面说的, 引入它只是让程序写得更好看而已. 而且假如 python 本身就是一个懒惰求值的语言, 这些等式的顺序调换是完全没有问题的.
状态
读者一定会跟我抬杠, 我要做状态机怎么办? 有的应用天然地需要维护状态. 我们可以看看 python 的 reduce, 作为一个最简单的需求, 如果我要求数组的和.
reduce(lambda curr, x: curr + x, data, 0)
提供一个状态转换函数, 接受两个参数: 当前状态 (curr) 和真正的参数 (x), 返回下一状态, 然后 reduce 框架会顺序把数据源的每一项和上次执行返回的状态调用这个函数, 返回最后状态. 这里发生的事情其实是, reduce 为我们维护了状态, 而我们的函数仍然是一个很纯净的函数.
状态维护是一件困难的事情, 一旦涉及状态维护, 一切都变得复杂起来. 维护状态的程序很难并行, 维护状态的代码更难调试, 更容易有 bug. 还要处理并发冲突, 状态持久化和崩溃恢复等问题. 这些问题不应该在日常的业务开发中涉及, 我们需要把状态维护抽象到执行框架, 让执行框架自己去维护状态, 处理这些复杂的问题. 这样的结果是:
- 策略依然是纯净无副作用的函数.
- 策略作用于执行框架产生的依然是纯净无副作用的函数.
- 执行框架内部在执行过程中维护状态, 做各种各样的肮脏的事情.
很多看起来应该没有状态的操作, 其优化实现的执行框架内部都有状态维护. 例如上面多次提到的 cache, 就是一种典型的状态维护 (当然就有很恶心的线程安全问题....). 然而这都是用户不必关心的, 对外来看一切依然纯净, 我们还是能很舒服地做函数式, 表意式编程.
若以有无状态维护来考量表意编程, 则有一个粒度问题. 我们是否需要把所有操作都做成无状态维护的形式? 如果你使用的是 erlang 或 haskell 这样的纯函数式语言, 你没有选择. 但我们这里的考虑是, 如果一个策略没有复杂到需要一个执行框架来组织而可以直接编写函数实现, 只要这个函数本身是无副作用的, 在函数求值过程中是否维护了状态并不重要, 它并没有破坏我们上面的任何一点原则 --- 况且, 究其实际, 在 CPU 里不还就是在捣鼓一堆寄存器状态么.
所以, 总结一下. 编写基础的原子策略时, 不妨使用你熟悉的命令式编程风格. 但进行更大的组件组合时, 使用纯净的表意风格. 大应用中的状态维护问题和相应的控制策略, 则交给专业的执行框架自己解决.
依赖, 顺序与并行
多年来我们习惯了顺序编程, 习惯了我们在单处理器上工作的假定. 但这样的假定无论是在多 CPU 或多核环境以及分布式环境下都是不成立的. 而正如我们所展现的, 函数式的编程方法在很多时候并不注重执行顺序, 这给并发优化创造了巨大的空间. 无怪乎在多核 CPU 流行的今天, 在必须使用分布式架构进行超大规模数据处理的领域, 函数式语言和编程方法获得越来越多的重视.
许多计算需求是天然不能并行的, 在这里它被表示为依赖. 管道清晰地表达了组件间的依赖关系. 要求得下游的结果, 必须先进行上游的至少是部分的处理. 我们又从管道的单依赖情况扩展到更复杂的树状依赖乃至网状依赖的情况. 毫无疑问, 没有直接或间接依赖关系的组件可以并行执行.
在我上面提到的产品级项目中, 我们使用了这种方法处理相互依赖的 IO 任务的并发问题. 作为一种更通用的情况, 我们可以看看微软的 Dryad 平台, 当它执行下面这种貌似顺序的程序:
other_table = Grep(...)(Stream(open('other-table-source')))
joint_table = Option() >> Grep(...) >> Join()(
Stream(open('table-source'), other-table))
result = Grep(...)(joint_table)
它能够分析处理间的依赖关系, 得到一个优化的执行计划, 使各处理能够并行执行. 这更能说明所谓 "表意" 的意思, 用我们习惯的顺序思维描述需求, 但实际的处理依然可以并行. 一个更实用的例子是 DryadLINQ, 在 Dryad 之上处理 LINQ 程序. LINQ 是另一个函数式编程附体的咚咚, 熟悉的同学可以自行分析 :-)
实用的函数式编程
很多时候函数式语言和函数式编程都是很学术的东西, 但我们可以发现很工程的 UNIX 的设计思想与它高度吻合, 这提示了函数式编程思想在实际工程中的应用前景. 在这里, 我们展现了部分函数式的设计思路:
- 以高阶函数作为系统基本构件和通用接口, 使用抽象的执行框架组合基本组件产生更大规模的应用. 这促进重用, 有效管理大型应用的复杂性. 最终得到一种表意式的编程风格. 并由此推出专门表达领域需求的领域特定语言.
- 无状态, 无副作用组件接口, 使得组件非常容易测试和调错. 非常谨慎地对待状态维护, 使用执行框架对状态维护进行抽象封装, 保证系统绝大部分代码 --- 业务功能不必涉及状态维护. 这将会得到稳定, 高质量, 易测试, 易优化, 可扩展的软件架构.
- 这种设计方式特别有利于将程序扩展到并行环境.
这些设计思路并不需要特定技术或语言来实现. 这也是我在这里利用 python 而不是经典的函数式语言来演示的原因. 基本上, 如果语言能够支持高阶函数和 closure, 这里所述的任何设计都能很方便地实现, 没有 native 支持的语言也可通过一定的封装和限制进行实现. 我们也可以根据实际的项目需求, 以别的, 而不是这种自然的函数方法来实现这类模式.
这样的设计方法也不必运用在所有地方, 我们探讨的内容专注于组件的组合, 专注于基本组件如何构造复杂应用. 而在一个基本组件内部, 可以按照最适合应用特点的方式实现, 而不必使用纯函数式编程的方式. 关键在于我们的基本组件的粒度, 执行框架抽象的程度, 选择这样的粒度和程度是否有利于组件和框架的复用, 是否有利于提高软件开发质量和效率.
我在实际项目中, 实际使用和体会到了这种设计风格的威力. 在一个 C++ 的应用框架设计中, 我们发现, 上述的这些设计点正是保证组件隔离, 处理应用复杂性, 保证复杂性可扩展的关键. 在设计开发中, 虽然我没有使用 "函数式" 这样的说法, 但这种设计思想是很容易理解和贯彻, 并且能与流行的 OO 设计方法有机结合, 在一个传统的静态命令式语言的开发上产生良好的效果.
在 python 上实现上述功能, 如果需要有较好的实际执行效率, 还是有不少的工作. 因此我开发了 python-tao 框架, 实做了上面提到的设计. 本文没提到的 python-tao 部分包括其他函数式语言的基本元素: 对 tail call 的支持, 类似 scala 的对象 pattern matching, 以及 partial 机制. 对于 pattern matching, 需要再开另一篇文章来讨论.
]]>
