函数式编程很难,这正是你要学习它的原因

很奇怪不是,很少有人每天都使用函数式编程语言。如果你用Scala,Haskell,Erlang,F#或某个Lisp方言来编程,很可能没有公司会花钱聘你。这个行业里的绝大部分人都是使用像Python,Ruby,Java或C#等面向对象的编程语言——它们用起来很顺手。不错,你也许会偶然用到一两个“函数式语言特征”,例如“block”,但人们不会去做函数式编程。

然而,很多年来,我们一直被教导说函数式编程语言很好很棒。我仍然记得当我第一次阅读ESR的著名的关于学习Lisp语言的论文时的困惑。也许大多数的人对Paul Graham 的《Beating The Averages》这篇文章更加熟悉:

使用Lisp开发使我们的开发周期迭代的如此之快,以至于有时当竞争对手在新闻发布会上推出他们的新功能一两天后,我们就能复制出同样的功能。当报道产品发布的新闻记者打电话给我们时,我们的产品已经拥有了同样的功能特征。

那些皈依函数式编程的人中,一直常见的考虑是:学习这种新的、函数式的语言“对你有好处”;就像是某些人建议说每天30分钟的健身房活动会“让你的身体健康”一样。但这也同时暗示了这样做的难度和需要的付出。Lisp语言跟Haskell、Ocaml和Scala语言不同,被认为是出了名的难学,可以说是臭名昭著。文雅的人说这是Lisp语言的“深度&广度”的体现。不文雅的人说这是“意淫”或“玩弄学术”或简单的“没必要”。我认为,它的难度跟你对它熟不熟悉有关,而且,这种难度是一种重要指标显示:学习这样的一种语言会让你编程更有效率、能力更强。

它给你的初次印象不友善

我7岁时就开始编程,在漫长无聊的郊区夏季里,在我祖父的计算机上瞎搞一气。我学了BASIC,用它在屏幕上画一个蹦跳的球。我学了Pascal,用它写了一个能通过PC喇叭放音乐的程序。大概10岁时我学了C语言,但遇到了一堵越不过去的墙,直到我上了高中。那就是:指针。即使不算这些该死的指针,我写、读、学习、练习中,同样遭遇无数的失败。我把祖父的硬盘给毁掉了两次(一次属意外),最后弄得不少次要自己重装操作系统。我失败,一遍遍的失败。

也许你也有跟我相似的故事,也许是完全不同的一个。但我想,差不多所有学过编程的人都有过遇到困难的经历。我们在学了一些基本知识后,必然会遇到一些公认的概念上的关口,比如“指针”。很多计算机科学教授会把指针描述为他们课程上的过滤网。如果你想成为一名优秀的程序员,你必须要能理解指针。很少人能轻松的掌握它们。大多数人,包括我,则需要不断的练习和参考例子来理解什么是指针、为什么它们很重要。

这种艰难的努力过程不是偶然的,是一种几乎普遍的现象。指针是一种非常强大和基础功能的概念。学会它能让你成为一名更好的程序员,能让你的思考更加形象化。即使你使用的语言并不提供指针这样的特征,但跟指针类似的数据结构和概念却随处可见。

新奇事物

一旦你学会了几种语言后,所有的语言都开始看起来都很相似。知道Python的人学习Ruby可能不会遇到太多的问题,知道Java的人学习C#会感到很熟悉。不错,也有意外的地方。Ruby爱好者在学习Python时会对它的comprehension感到吃惊,Java用户会对C#里的委派摸不着头脑。还是那句话,如果你只瞟一眼,它们都很相似。我可以打保票的说,如果你还不曾有过这样的认识,一旦你学了一种Lisp语言,你会发现所有的Lisp变种都很相似。

有人说,大部分人第一次使用Haskell或Ocaml时都完全的不知所措。见鬼了,在Haskell里,连分号都跟别人不一样。这并不是语法的问题;Haskell和ML语言完全基于一种不同的概念、一种新的语言范式。你需要用不同的方式开发应用,不同的方式组织应用,不同的方式扩展应用。

很多这样的新概念都具有不可思议的强大力量。Haskell里的Monads 是跟指针一样基础且强大的概念(你很可能在不知道它叫什么的情况下就已经使用过它们了)。所以,跟学了Java后再学C#不一样,有志向学习函数式语言的人需要往回走的更远,去学习更加基础的概念后才能接下去学习。就像是完全再学习一次指针。并且,就像是当年我们刚开始学习编程一样,一些很大的概念看起来会让人迷惑茫然,让人沮丧,直到你去攻克(以及失败)它们。

吃下你的药丸,找到你的药剂师

尽管不好学,但我坚信,学习这些函数式编程语言会在职业上对你有好处。我相信有些人读到这点时会眼睛翻起来向天看,很难想象出这些monoids 或 monad 会对他们在使用Java或C#时有用处。对我而言,我已经不惊奇于由于这样的思维而阻止他们学习函数式语言的现象;他们需要学习一种跟指针和递归一样基础的新概念。他们需要有一种只有专业人员在完成清晰的商业目标时才具有的耐心和斗志。很少人能在过了可塑的年龄后还受得了挫折——一次又一次的挫折——否则我们现在都早成专家了,不是吗?

还有更复杂的东西,有大量的语言和算法研究都是用函数式语言实施的(尤其是Haskell)。你很容易会被这些不熟悉的概念——例如范畴论half-finished abstractions,一些失败的研究——弄的迷失方向。没有一个清晰的指导(比如由一个实用主义的作者写的一本好书),本来已经很困难的学习任务变的更加可怕。

这些叠加起来的复杂因素导致了不出意外的结果:很多人不情愿在函数式编程学习中投入时间。很容易理解这种不情愿,“我干嘛不把花在学习这些东西的时间用在实现什么东西上呢?”但这种思路也表明了你永远不愿意在任何新技术上浪费时间(只用自己熟悉的)。在一个像软件技术这样日新月异的产业里,我不认为这是正确的判断。

眼见为实

学习一种函数式编程语言最显而易见的好处是,你能学会这种类型语言中的函数式概念。它能帮助你的大脑,让它具有能非常清晰的思考和处理一些惊人的重大概念的能力。这并不是函数式编程具有魔法;各种语言和范式的出现都是为了应对某一特定类别的问题。函数式编程的杀手锏正是应对了当今世界上日益增长的并行性编程和元数据编程趋势。

例如,我们研究一个简化的、本地版本化的Google著名的MapReduce范例。用函数式方式描述这种范例是不可思议的清晰简洁:

mapReducer data partitioner mapper reducer =
              let partitions = partitioner data
              in reduce reducer (map mapper partitions)

让这样的代码支持并行计算或分布式并行计算是轻而易举的(对于本地并行计算,很多的功能包都支持“pmap”和“preduce“——只需要利用函数式语言的一些简单特性)。像maps, partitions, generators, streams, reductions, folds, 已以及 function chaining等概念在各种的函数式编程语言中都大同小异,所以,任何对Lisp,Haskell,OCaml,甚至带点函数式语言特征的语言——Python和Ruby熟悉的人,都会很容易的理解这里面的思想精华。

让我们花点时间考虑一下,如何用一种面向对象的语言,以一种常见的面向对象的模式来清楚的描述这种架构。至少你需要做的事情是定义用来描述mapper和reducer的声明。如果你有好奇心,请试着用你喜欢的面向对象语言描述一个最小化的“面向对象”的MapReduce。我发现那是非常罗嗦的。如果使用Java风格的语言,它会像这样:

interface Mapper {
   B map(A input);
 }

 interface Reducer {
   Y reduce(X a, X b);
 }

 abstract class MapReduce {
   private Mapper mapper;
   private Reducer reducer;

   public MapReduce(Mapper map, Reducer reduce) {
     // ...
   }

   public run(SeqenceType data) {
     // ...
   }
 }

即使是没有加入循环逻辑,这种缺乏函数式模式中常见的名词和动词的使用,使得MapReduce这种技术很难被定义。这种定义方式几乎是滑稽可笑的,但它能让你想到函数式概念。另外一个好例子是Scala语言如何利用完备的Java Fork/Join 类库,把它轻松的集成的自己的自有语法中

各有所求

所以,我鼓励任何想进步的程序员:请考虑学习一种函数式语言。Haskell和OCaml都是极好的选择,F#和Erlang也相当的不错。它们都不好学,但也许这是个好事。努力弄清楚你遇到的复杂的概念,看看是否有其他人正在利用这些概念;经常的,你会在寻找这些不熟悉的概念的真正用意的时候实现思想上的突破。

当你开始学的时候,请注意,不要过于在意。就像其他任何需要你花时间和精力的事情一样,过度的在函数式编程上进行精力上的投资是很危险的。掉进了认知能力的陷阱后你的投资会血本无归。你很容易会忘掉世界上还有无数种计算模型,你更容易忘掉有多少种优秀的软件根本没有使用任何的函数式概念。

学习的道路会越来越难走,但从另一方面说,在你日常的编程中,你会发现有越来越多的可以使用的重要概念和模型。对于这样紧凑的编程风格你会越来越适应,必然,你也会对如何成为一名更好的软件工程师有了新的认识。

补充

有不少校对这篇文章的人在看完文章后都问了我一个同样的问题:“听起来不错,大卫,可是我应该学习那种语言呢?”当然,这是他们给我出的难题。

我想,如果你是一个很有经验的程序员,这最能“应付”这个问题的答案是:“选一种符合你的需求的”。如果你需要在JVM上工作,选择Scala或Clojure。如果你想能快速的开发大型分布式软件系统,选择Erlang。如果你想要一种具有超强编译器的超能干活的语言,请选择Haskell或RCaml。如果你想要一种比Ruby或Python更有能力的原型工具,选择Scheme。

请记住,我们在这里要做的这些目的是为了实际的技能和自我进步。如果你能腾出时间学这些,就走出你的安逸环境,挑战自己。

因为我已经学习了Lisp和Erlang,而且使用OCaml做专业工作,我决定研究一下Haskell,这完全是另外一个世界。我发现唯一能帮助我参透这种语言的途径是依赖Learn You A HaskellReal World Haskell 这两本有用的指导材料。这些书写的非常好,很有价值,而且可以免费在网上找到。如果你想试一下Haskell,这些书可以当作你的寻宝图。

[英文原文:Functional Programming Is Hard,That's Why It's Good ]

分享这篇文章:

12 Responses to 函数式编程很难,这正是你要学习它的原因

  1. momo5269 says:

    记得之前看过一篇文章 说华尔街的程序员们用得到函数式编程语言~ 而且精通函编很有可能会有公司高薪聘用你 当然 这种人才需求量很少就是了 (比如Erlang、Lisp 国内都有高薪聘请的)

  2. June says:

    真希望看看php函数式编程是什么样子

  3. bao says:

    分类学理论应翻译为范畴学理论

  4. Sweet says:

    简单是简单,但是编程,或者上升到架构的高度,简单不是最重要的,可读性呢?可维护性呢?
    就那个MapReduce的例子,Lisp的那个,基本上很难明白在干嘛,Java的就很清楚。而且匿名函数一样可以把它变得很简单。感觉函数式编程作为一种运算辅助还比较好。

  5. paratroopt says:

    我更喜欢函数式编程,似乎更加简洁和明了,但是维护就有点难了,而且这种程序似乎比较好做炸弹代码。

  6. czg says:

    原子弹难以维护,TNT就简单的多,追求容易维护只会让别人把你踩在脚下

  7. Thanks for the article, it was interesting and compelling. I found my way here through Google, I will come back another time 🙂

  8. Ivanjoy says:

    觉得难维护或者难读,是你或者你的伙伴还不够熟悉。代码不是一个人的事。

  9. aaa says:

    这文章真扯,一看就是菜鸟写的。希望中国的程序员不要看个老外的文章就觉得很有价值,值得一转。真正有经验的程序员懒得出来说些什么,误导的竟是下一代。新的程序员进来,如果都和这个作者似的,满脑子Linus说的那种各种各样的(面向对象的、函数式的)精神包袱,根本不可能再学会真正的技术,出的活儿也会千奇百怪、离题甚远。

    说到函数式编程,其实并不难。有些人觉得“难”,是因为天生就对这类语言没好感,懒得学;这种人在他们的工作中往往没有遇到相似的场景,或者遇到相似的场景,用他自己的方式、熟悉的语言就能很自然的解决(往往这种解决方式落在熟悉FP的人眼里,带有强烈的FP风格,但是作者本人却未必意识的到,因为他完全不知道什么是函数式)。另一些人则是完全没有天赋,偏偏还喜欢挑战自我、乐此不疲,以为学到了什么真谛,这个作者就是此类。

    每种技术(语言)也好,都有其具体的需求和由此导致的使用场景。没有相关需要,不了解是正常的甚至是正确的,毕竟人活在世界上是要做出有用的事情,如果有更重要的事情做、不了解某种编程范式也不会造成什么影响,那他何必去折腾?

    对于需要用到FP的程序员,人家自己不会去学?说实话,即便用C,都可以写出纯函数式的程序,包括高阶函数、闭包;完全不懂FP的人在解决具体问题的时候都有可能做出这样的解决方案,且在兼顾执行效率的同时,照样可以拥有相当的简洁性。如果看过或写过的代码量、完成的工作种类足够多,肯定明白我在说什么、如何实现。

    这种所谓的IT评论,少点比多点好。因为干货少,价值观(还是畸形的、甚至错误的)输出多。表面上是让别人开阔思路,其实却做着禁锢思想、获取认同的事情。不但无聊、而且有害。如今的网络时代,真让小白退散、别出来献丑,确实不容易。初学者只能自己留点心,别人家说什么就是什么,臭大粪还当香饽饽翻译了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注