不用静态类型函数式编程语言的十大理由-技术开发专区

不用静态类型函数式编程语言的十大理由

作者：oschina译者编辑：王晓东 2013-08-21 13:19 来源：开源中国社区

【IT168 评论】你厌烦函数式编程么?我也烦，我真想呼吁那些想我一样明智的人远离这种语言。这里要澄清一点，我指的这种静态类型函数式编程语言，包括那种类型推断或者静态缺省等等。实际上，就是Haskell和ML—family。

　　不想跟潮流

　　像大多数程序员一样，我怀旧且讨厌学习新东西。这是我选择混IT这行的原因。我不跟风的原因跟其它“程序猿“一样，静观其变，等该产品差不多了且能看到其前景，对我来说，函数式编程这东西太新了，我讨厌新东西。

　　是的，有些家伙已经把ML和Haskell跟他们之前最喜欢的Java&PHP作比较了。但最近我只听说过Haskell，他们所说的对我都是废话。看看新宠F#语言。已经有七年了，彼得的大作。当然，这在业界来说已经生存不少时间了，但相对于互联网的历史，七年只是一眨眼。所以，像我所说的那样，我会谨慎的小心的观察每个internet潮流，函数式式编程或许只是浮云。

　　按代码行数算工资

　　你怎么想的我不知道，但是随着我写的代码越多，我就越有成就感，效率很高。如果一天能快速完成500行代码，那就可以说你干的漂亮。每天的任务很繁重，而且boss眼里你也总是忙忙碌碌的。但是当我拿函数式编程语言和那些老牌语言例如C去比较时，代码少的让我吃惊。就拿下面这段代码为例：

public static class SumOfSquaresHelper
{
   public static int Square(int i)
   {
      return i * i;
   }

   public static int SumOfSquares(int n)
   {
      int sum = 0;
      for (int i = 1; i <= n; i++)
      {
         sum += Square(i);
      }
      return sum;
   }
}

　　比比下面的：

let square x = x * x
let sumOfSquares n = [1..n] |> List.map square |> List.sum

　　十七行的代码只剩下2行了，想想如果这种变化发生在整个工程里面会有什么后果。如果我们使用这种方法，估计我的代码产量会直线下降--这不是我能忍受的。

　　喜欢大括号

　　还有一点使我不想喜欢这种语言的原因是，我不明白这些与语言要把大括号去掉。去掉大括号还能叫编程语言么?看下我的意思。这是带大括号的代码：

public class Squarer
{
    public int Square(int input)
    {
        var result = input * input;
        return result;
    }

    public void PrintSquare(int input)
    {
        var result = this.Square(input);
        Console.WriteLine("Input={0}. Result={1}", input, result);
    }
}

　　这个则是去掉大括号的相同的代码：

type Squarer() =

    let Square input =
        let result = input * input
        result

    let PrintSquare input =
        let result = Square input
        printf "Input=%i. Result=%i" input result

　　看看差别吧，你怎么想我不知道，但是我真心觉得第二种语言有点像垃圾，就像漏掉了什么东西似得。实话说，如果没有大括号给我指引，我总觉得少了些东西。

　　喜欢看到明确的类型

　　函数式语言的支持者声称，类型推断使代码更清洁，因为任何时候你都无须用类型声明干扰您的代码。好吧，碰巧，我喜欢看类型声明。如果我不知道每个参数的精确类型，我会觉得不舒服。这就是为什么Java 是我最喜欢的语言。这是一个某些ML-ish代码的函数签名。不需要类型声明，所有类型自动推断。

let GroupBy source keySelector =
...

　　这是C#的类似功能代码的函数签名，带有明确的类型声明。

public IEnumerable<IGrouping<TKey, TSource>> GroupBy<TSource, TKey>(
    IEnumerable<TSource> source,
    Func<TSource, TKey> keySelector
    )
    ...

　　在这方面我或许是属于少数派，但我更喜欢第二个版本的说法。知道返回值的类型是IEnumerable>对我而言极为重要。确实，编译器会为你检查它的类型，并在类型不匹配的时候提醒你。但为什么要让编译器代替你做你能做的工作呢?好吧，我承认如果你使用了泛型，匿名，返回值为函数的函数，以及其它一切新奇的东西，那么你的类型声明将变得复杂又难以理解。而这使得正确判断类型变得非常困难。但对此我有个简单的弥补办法——不使用泛型而且不要传递函数，你的签名将变得简单许多。

　　喜欢修复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=: +/ @: *:

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

关注我们