原因5：喜欢修复bug

　　对我来说，找出bug调试bug，想狩猎一样刺激。如果在产品系统中存在这个bug，我更兴奋，因为那使我有一种我是英雄的错觉。但是当我看了这种静态类型函数式编程之后，寻找bug变得困难多了。太不爽了。

　　理由六： 我生活于调试程序之中

　　论及修复bug，我可是花费每天的大部分时间在调试程序、代码单步执行中的。没错，我知道应该使用单元测试，但说起来容易做起来难，对不？

　　不管怎样，通过这些静态类型的函数式语言，如果你的代码编译通过了，一般它能正常运行 。

　　我听说你不得不耗费许多时间在类型匹配上面，但一旦完成它又编译成功，没有什么需要调试的了。这里面哪里有乐趣呢？

　　这使我转向到……

　　理由七：我不想死扣每个细节

　　确保所有的类型匹配合适听起来让我觉得累

　　事实上，我知道你得被迫去考虑各种可能出现的情况，所有可能的错误，所有别的可能出错的事情。而且你得至始至终去做这些——决不能偷懒也不能推脱到到后面。

　　我更喜欢在一个相对愉快的环境下工作，然后再屁颠屁颠的去修复bug

　　理由八：我喜欢检查空值

　　我十分乐意为每个方法检查空值。那会给我很大的安全感，我知道我的代码运行结果是安全的

    void someMethod(SomeClass x)
    {
        if (x == null) { throw new NullArgumentException(); }
    
        x.doSomething();
    }

　　哈哈！开个玩笑！当然我不能总是要在每个地方都要放置检查空值的代码这种事情来打断我。这点我从来没有落到实处。

　　我是仅去处理由NPE造成的灾难，而且即使我是在产品发布之后几个星期后才发现那些问题，对业务也没有影响。所以我不懂为啥这也算是个大问题。

　　原因九：我喜欢用设计模式

　　第一次接触到设计模式是在《Design Pattern book》（由于一些原因，被称为“四人帮”，我实在搞不懂），自从那以后我费劲心机用它来解决各种问题。这确实能使我的代码看起来严谨并且有团队性，给我的boss留下了很深的印象。

　　但是我没有丝毫注意在函数设计中的这种模式。如果没有策略、工厂模式、装饰者模式、代理模式等，你怎么能整理好有用的材料。

　　也许函数式编程没有注意到这些！

　　理由十：它太数学范了

　　这儿有更多关于计算平方和的代码。这个方法太难理解了，因为其中都是怪异的符号。

ss=: +/ @: *:

　　哎呀，抱歉！搞错了。那是 J语言代码。

　　可我确实听说有些函数功能程序使用奇怪的符号，像<*>和>>=以及晦涩的概念“单元”(monads)和“仿函式”(functors)。

　　我不知道为什么写函数的人不能坚持用我已经知道的东西——明白的符号如++和!=以及简单的概念“继承”和“多态”。

　　后记：我不理解

　　你知道么，我理解不了它！我不懂为什么这种函数式编程语言会有用！

　　现在我读到一些帖子如“你需要了解的事情都在一个网页上”。但是对我来说那太简短了。

　　我一直在找更深层次的一些东西—能够让我啃的知识。

　　不，不要说我应该读一些教科书或者去看一些经典的例子，然后写下代码。我想不通过那些方法来体验一下。

　　我不想仅仅是为了学习新的范例而改变我自己我自己的道路