没有系统学过函数式编程和范畴论,不过万一以后要学了...正好今天看到了一系列ms员工的blog,就顺便翻译一下

  1. 本文章译自Fabulous adventures in coding,作者是微软的前员工,曾经参与过C#语言的设计与C#编译器的开发,并且加入过EMCA委员会并为规范化JavaScript做出了贡献

  2. 如无特殊声明,本文中所有的术语将使用英文原文表述以避免歧义

  3. 由于我本人学识浅薄,尽管已经用我最大的努力去翻译,但是还是不可避免的会出现错误之处,如果你在阅读过程中发现有错误的地方,欢迎在评论区勘误

Monads (一)

假如我是一个没有任何所谓"函数式编程"基础的C#程序员,该如何理解经常被提到的"Monads",又该如何应用?

很多人喜欢直接使用术语来讨论这个问题,大谈特谈诸如"bind" "unit"或者"高阶类型"等等,而最终又讨论回范畴论的基础,也就是"Monads"以及那句名言"A monad is a monoid in the category of endofunctors(单子不过就是自函子范畴上的一个幺半群,此话出自范畴学奠基人Saunders MacLane)"等等。本文会从一个基于实践,OOP以及C#语言的部分开始,逐渐迈向函数式编程

OOP程序员们喜欢讨论"设计模式"云云,所以我们用设计模式类比,设计模式的思想来源自真实世界中的建筑。数千年以来,可以在建筑中发现很多重复的部分,比如墙,门,窗户,天花板,门廊,后院,吊桥,护城河,衣柜,厨房等等等等。并且相互之间关系密切,藕断丝连,相当经受得住时间的考验:你可以在五角大楼和1900年前的别墅这两个相隔了数千年的建筑商发现诸多共同之处。软件也是这样,诸如函数,变量,类型等等设计已经扎根于各种编程语言中,以至于平时几乎无法领会到它们其实也是设计模式的一部分,就如同我们很少注意到自己在呼吸一样。所以,多数时间所谓"设计模式"都要求语言无关,并且必须由程序员亲自动手实现。以C#为例,它并没有把单例模式集成到语言中,也许我们本可以像抽象类和静态类那样使用类似singleton class C { ... }这样的语法。但是C#的设计者显然认为并没有这个必要,所以我们在需要的时候不得不手动的去实现一个单例的类。同样的,"Monad Pattern"不过是另一种为类型而准备的设计模式而已,它描述了问题的解的"shape";Monad Pattern与单例模式不同之处在于,它会在你不经意的时候悄悄的融入你的代码中,事实上很多程序员都会机缘巧合的使用到Monad Pattern,尽管他们甚至不知道这个名字

本文会尽可能的避免过分的理论化和术语化,因此在下一节中,我们会找一些有关Monad Pattern的例子来看看他们的共同之处


乱我心者,今日之日多烦忧