这对我的触动很大。一直以来我都是用一种编程方法来解决所有我遇到的问题的。然后突然有一天，我发现有很多问题用别的方法来解决更好，于是我就开始去研究这方面的内容。一开始我的认识还是比较浅，应用这些方法的时候还处于只能了解表面的状态，譬如说曾经流行过几天的Fluent Interface，还有声明式编程啊，AOP等等。直到我遇到了这本全面改变我对C++模板看法的书——《Real World Haskell》：
是的，你没看错，是《Real World Haskell》！Haskell颠覆了我的世界观，让我第一次知道，原来代码也是可以推导的。说实话我用Haskell用的并不熟，而且我也没写过多少个Haskell的大程序，但是Haskell的很多方面我都去花了很长时间去了解，譬如那个著名的Monad。多亏了当时搞明白了Monad，我借助这方面的知识，理解了《Monadic Parser Combinator》这篇论文，还看懂ajoo那篇著名的面向组合子编程系列。
当我终于明白了Haskell的类型推导之后，我终于体会到了Haskell和C++之间的巨大差异——Haskell的程序的逻辑，都是完全表达在函数签名上的类型里面，而不是代码里的。当你写一个Haskell函数的时候，你首先要知道你的函数是什么类型的，接下来你就把代码当成是方程的解一样，找到一个满足类型要求的实现。Haskell的表达式一环扣一环，几乎每两个部分的类型都互相制约，要求特别严格。导致Haskell的程序只要编译通过，基本上不用运行都有95%的概率是靠谱的，这一点其他语言远远达不到。而且Haskell的类库（Hackage）之多覆盖GUI、GPU程序、分布式、并发支持、图像处理，甚至是网页（Haskell Server Page）都有，用来写实用的程序完全没问题。之所以Haskell不流行，我觉得仅有的原因就是对初学者来说太难了，但是人们一旦熟悉了C的那一套，看Haskell的难度就更大了，比什么都不会的时候更大。
于是回过头来，模板元编程也就变成一个很自然的东西了。你把模板元编程看成是一门语言，把“类型”本身看成是一个巨大的带参数enum的一部分（scala叫case type），于是类型的名字就变成了值，那么模板元编程的技巧，其实就是对类型进行变换、操作和计算的过程。接下来只要会用模板的形式来表达if、while、函数调用和类型匹配，那掌握模板元编程是顺利成章的事情。撇去type traits这些只是模板元编程的具体应用不说，只要熟悉了Haskell，熟悉C++的模板语法，学会模板元编程，只需要一个下午——就是学会用蹩脚的方法来写那些你早就熟悉了的控制流语句罢了。
当模板元编程变成了跟写i++一样自然的东西之后，我看语言的感觉也变了。现在看到一个程序语言，再也不是学习与发这么简单了，而是可以看到作者设计这门语言的时候想灌输给你的价值观。譬如说，为什么C语言的typedef长那个样子的？因为他想告诉你，你int a;定义的是一个变量，那么typedef int a;就把这个变量的名字改成了类型的名字。为什么C语言定义函数的时候，参数是用逗号隔开？因为你调用函数的时候，也是用逗号来隔开参数的。这就是语法里面的一致性问题。一个一致性好的语言，一个有编程经验初学者只要学习到了其中的一部分，就可以推测他所想要的未知特性究竟是如何用于发表达出来的。一个一致性差的语言，你每一次学到一个新的功能或者语法，都是一个全新的形式，到处杂乱无章，让人无可适从（所以我很讨厌go，还不把go的library移植成C++直接用C++写算了）。
从此之后，我就从一个解决问题的程序员，变成一个研究编程本身的程序员了。当然我并不去搞什么学术研究，我也不打算走在理论的前沿——这并不适合我，我还是觉得做一个程序员是更快乐一点的。这些知识在我后续学习开发编译器和设计语言的时候，起了决定性的作用。而且当你知道如何设计一个优美的语法，那么你用现有的语法来设计一个优美的library，也就不会那么难了。当然，设计优美的library是需要深入的了解正在使用的语言本身的，这样的话有可能维护这个library的门槛就会提高。不过这没有关系，这个世界上本来就有很多东西是2000块钱的程序员所无法完成的，譬如维护STL，维护linux内核，甚至是维护Microsoft Office。
网友评论