敲响OO时代的丧钟！——DJ对于数据持久化的支持(3)

<回ajoo>:
好的，那我们就来把细节一点点挖个清楚，真理越辨越明，哪怕我说的都是错的，我也希望我的辩论能给大家有所启发，这就够了。


这个地方是你把两者关联起来，我的意思是（大部分的）模板通过间接的（类型等）检查，也同样保证代码的静态安全。我的本意就是要指出不要过于夸大静态类型检查的作用。

模板程序本身的bug难查，我不知道你说的是什么意思，是自己写的模板程序的错误，还是引用别人的模板内部的错误，前者据我所知，在运行和普通的代码几乎没有区别，而且往往模板代码都比较短小精悍，根本没法给庞大程序本身造成什么负担。当然你如果是做库，为得不到一个通用而且足够鲁棒的结果而恼火，呵呵，这个我也不知道该怪谁，反正喜欢怎么着就怎么着吧。要如果是引用别人代码有问题，呵呵，这个问题就有的讨论了。

我也有在编译错误发生的时候去读代码的时候，尽管很少。但这也没什么，藉我一人之力和寥寥无几的范例，有这样的时候不足为奇。如果在我周围有和用spring一样多的人，我相信这根本不是问题。运行期我还是要说，没有必要。

还有下面的运行期保证，用模板并不代表就不需要或者避免它，这早已是c++程序中的普遍特性。而且这个谁也保证不了，java的运行系统也一样。我的意思是静态检查只会强于它。


我只是介绍我的经验，当然因为某些原因，我不一定影响的了谁，但说一下也无妨吧。没有根据的争辩才是没有意义的。


呵呵，你误解我的意思间接误导大家，这是我一定要反驳的。稍微理解一些的人就会知道我说的绝对不是这个意思。我是说如果出错了，肯定是你的代码有问题，而没必要去追究那些提示信息本身。如果谁觉得使用一个接口报告的错误都看不出代码有什么问题，我只能说他学艺不精。退一步讲，就算是库的问题，在你无法发现的情况下，放弃也不算是什么天大的事吧。在abp好像我也不止一次措词强烈，这一点elm大人应该有所赞同。


呵呵，你这么说我也没有什么意见，只使用库而不关心库本来就是大多数情况。这没什么可以炫耀的，我并没有跟语言挂上钩，我关心的只是这样的库能不能给我带来足够的好处。



我不知道你的结论是怎么得出的，反正我是不知道有这样的事情。在c++里，也一样可以提供很多的库，这跟其他语言都一样，这个方面我们没有必要去划出什么语言界限来。java库的繁荣，根本原因在于它有一个统一的标准。我也希望看到c++有通用库可以使用，好不容易有“天才们”提供象boost这样的东西帮你弥合各种差距，还有方便的功能，怎么就被你说的这么不值？


这不是承认不承认的事情，该承认的我都会承认，比如elm大人说的部分缺点。但如你这么夸张的批判，而且没什么具体根据的，我当然会根据自己的经验反驳。


呵呵，我不知道你根据什么来说有古怪的错误信息，还是那句话，Typelist本身很稳定，引用起来也很简单，可以帮助你把变化集中起来，保证你的设计的正确性。而且代码也一样可以调试的，这一点根本没有任何区别。
好的，这里我就不写代码了，在我想介绍的文章中，第一个就会用到这个。


不是变量怎么了，难道代码里都是变量？不是变量更加确定，稳定，更少可能的发生错误。难道你那个f[i]凭空跳出来的，我还真没想到你会这么说。需要强调设计的时候强调设计，谈到具体代码似乎就把设计抛到一边（上边的Typelist也类似）。就算如你所说，运行期检查也是很容易的，一句话解决：

assert(i < N);;

还有我对于提到java程序员，有意识的划分界限也有意见，我也用java，我想在这里的人是为了解决问题而聚到一起，可能有OO等崇拜，但大部分人应该没有语言情节。

tiger，
我也不想搞语言之争。不过是你在这提出模板来的。魔板只是c++才有，所以似乎语言上的争论不可避免。


其实，我说的就是：模板编程不是解决开发问题的良方。

这包括两个方面：
1。自己写模板库。对这点你似乎也同意它的代价很大？如此，我们就不争论了。

2。调用现成模板库。
对这个，你认为象typelist这种用用很简单，不会出错。我不敢苟同。
一般来说，魔板程序不是完美的黑盒，它没有象函数接口签名检查这种东西，虽然最终的c++代码是静态类型，并且可以调试跟踪。但是meta-code也是程序！它负责声称目标c++代码。这个程序却不能调试跟踪。

实际中，魔板程序的使用并非那么简明，没有一定的语言上的功底上来就用模板库会死的很难看。你所说的看到调用错误能够分析出来自己哪里用错了，这绝对不是普通程序员普遍做得到的。
这在普通c++程序或者java来说就不是这种情况，随便一个一般人都可以用调用一个函数或者类。调用出错，编译器会给出最明确简单的错误信息。


综上所述，模板写起来很难，源代码读起来很难。一旦除了bug，想要确定不是库德问题也很难。毕竟，一个语言如果难写，那么写出来的库的出bug的概率也会大得多。这大概也是为什么c++的模板库不象其他语言的库那样雨后春笋，到处都是的原因。

用起来也没有普通函数那么简单，再加上维护，编译器兼容等等问题，可以说一定要谨慎使用。


关于那个常量参数，我一直强调的一点：模板库在常量和变量之间划了一条不可逾越的鸿沟。
如果你用模板写了一段逻辑，它使用编译期常量，那么，如果什么时候你发现这个逻辑可以用在运行时的变量的时候，没办法，只能把同样的逻辑用普通的c++重写。（就拿那个meta-program里面著名的factorial的例子来说）
所以，编译时整数不是什么值得炫耀的东西，即使不能算垃圾的话。
我还真没想到你把它还当个宝。

ajoo:
虽然你说的肯定有值得重视的地方，比如我也不觉得过分在模板上炫耀技巧以及强调细节的技巧是多么有价值的，所以我很少拿代码去说话，除非这样的代码非常有代表性（不好意思，这和这里很多人有些背道而驰，也许是我自身比较懒），再比如Andrei的很多注重细节的讲解我也很不以为然。但是我也要强调，争论问题不是模棱两可，也不能仅仅片面的看待问题。

模板本身如何，这本来就是值得研究的问题，我讨论的伊始就说过了。其也是经历了发展了，我想模板提出者肯定没想到模板在本身没有什么大的变化发展到了今天是这样的。基本上模板提出的伊始也不过是在之前某些语言特性上的一个扩充和通用的实现机制，也就是泛型。

模板写起来很难，这也要相对的来看，比如做个容器什么的，或者偶尔适应一下局部变化，而显然没必要重写代码的情况下，我觉得没什么难的，调试起来也没有负担，反而更加一致，减少人为错误发生的可能。

我说的分析错误你还是误解的，我的意思是一些语法逻辑上的问题，一般在有明确接口情况下，如果你有着基本语言的基础，分析它应该不是负担。当然现实中不合格的人比比皆是，但这样的人你让他去用什么spring或者这个库那个库，问题同样是一大堆。

我也没拿什么当作宝，我也从不认为自己有什么宝贝可以视人。我所说的都是一些基本的东西，至于你认为它有多大的用要视具体情况来看。比如关于编译期整数Andrei的Int2Type就比你说的factorial有价值，在实际中，boost::bind就可能定比traits更“有用”。

还是那句话，能解决问题的就是宝，不能的话，再炫目的技巧也是白搭。

我想说的意思是，消除重复代码，不一定就是OO设计的最高目标，根据“可复用的设计”这一目标，实现同样的需求，代码更多也是可能的。

过度设计，也就是“过度可复用”罢了。既然追求的就是可复用，追求得过了一点，为什么就是错的，这一点，“GoF”可没有告诉我们。

最初我知道的OO是这样产生的：随着计算机的发展，程序越来越庞大，庞大到了难以理解的地步，作为计算机语言天生和人类语言有着巨大的鸿沟，为了更好的描述程序逻辑于是产生了OO，使得计算机语言可以以OO的方式更逼近自然语言，使得程序更容易理解。其他代码减少等只是这一目的的附带效果。如果说到要敲响这个OO时代的钟声，那么第5代语言的前奏在哪里呢？

为什么“更好的描述程序逻辑”就一定需要OO？

(map square sequence)

这不也很能描述程序逻辑吗？

你在人家 java 的地头宣传 C++ 的好处 …… 是不是存心来砸场子的呀？ 

很抱歉，我没能看明白你代码的意思

那为什么C，C＋＋之类的高级语言替代了汇编或者机器码编程？

map是这样的一个操作：(map proc list)，将一个操作（即proc）作用于一个列表（即list）的每个元素，得到的结果是另一个列表，其元素个数与被处理列表相等。例如有这么一个列表：

(define seq '(1 2 3 4 5))

我希望对列表中的每个元素做平方运算，就这样写：

(map square seq)

得到结果就是(1 4 9 16 25)。其中的square定义是：

(define (square x) (* x x))

这不是很好的抽象么，把“列表之间的映射”这件事情描述得很清楚，而且没有对象。不管square还是seq，这两个元素都没有为对方做任何预先的准备，就可以把它们拉到一起来用。

OO的产生应该不是为了更好的描述程序逻辑，其他专门语言会更出色，OO应该是为了更好的描述程序结构而生，试图以人类容易理解的一般习惯性方式来表述复杂系统。