大家有没有想过类型推导这回事？发言有分

[fixopen]

我们都知道，程序=数据结构+算法。数据结构是被操作的对象，算法是操作的方式。面向对象是基于数据，加上操作形成的思考模式，但是我看过的函数是语言，都是把注意力集中到算法上，而可操作的数据类型都是推导出来的。并且我觉得它们的类型推导规则用现在流行的面向对象语言表达不出来（例如：流行的OO语言都不支持类型协变）。请高手谈谈

[Schlemiel]

to 楼主：

我和liu_feng的脑子可能已经被OO给灌满了，很难理解别的东西。刚看完你们的讨论，到后面部分有点离题了。在最初的帖子里，你讨论的有两个问题：正交分解，以及类型协变（我的理解有没有错？）。C++ template给出了一个不错的正交分解方案，J2SE 1.5的泛型实现则在类型协变的方向迈出了第一步。我希望你能就这两个东西谈谈看法，让我更清楚地理解你的意思。

Eiffel在继承上的主要特点有二：（1）允许多继承，并用改名机制避免了著名的菱形继承问题；（2）单根单叶继承（这是我自己起的名字），所有类继承同一基类（如果没记错的话，好象是any），所有类被同一子类继承（如果前面那个没记错的话，这个子类就应该是none）。至于它是否更好地描述世界，我看未必。我也已经好久不看Eiffel了，而且基本没有实用过，了解也不深。

C++版（乃至整个CSDN论坛）好久不见这样的好帖了，难得难得。

[Akun22]

关注...

[eqiaotea]

我来提出新的公式(大家快扔):

自己的程序 = 需求 + 能力;

[短歌如风]

我不同意“类型协变是现实的一种特点”的观点，事实上，我认为，类型本身就不具备自然性，它是我们为了分析现实世界而强加于它的。现实对象本身是没有类型的，或者说各自都属于各自独特的类型。而我们在分析世界时不可能去关注它们所有的特性，而是只关心一部分，从而在我们所关心的这部分特性集中拥有同一组共性的对象成为同一类型。在不同的关注特性集合中，同一对象的类型也就不同。正因为类型不属于现实的固有特点，类型协变也就不是现实的固有行为，而是对象在跨越不同关注特性集时发生的概念上的变化，我觉得这种情况并不常见。

　　我对Eiffel完全不了解，不知道“多继承时仍能满足子类就是父类（类型替换）这一严格的要求”是指什么，不过我觉得“部分继承”恰恰应该是与这一原则相矛盾的。在我看来，不管是多继承还是单继承，“子类就是父类”其实就是“接口不变性”。

　　关于“正交分解”，我觉得更常用的是维护类型与操作的正交，而“正交分类”看起来并不自然，我很怀疑它在实际项目中有多大用武之地。

[Schlemiel]

恩，我很同意plainsong(伤心的风★短歌)。本体论者喜欢给万事万物分类，但维特根斯坦并不认为分类是必须、对象是基础。曾经有人说维氏《逻辑哲学论》是OO的理论基础，恰好是弄拧了维氏的思想。

对于分类，维特根斯坦认为事物并不能有一个准确无误的分类。我们之所以把某些事物归为一类（用同样的“程序”去处理它们），只是因为它们有这样或那样的相似性，黑话叫“家族相似性”（见《哲学研究》）。从这个角度来说，GP倒是更符合维氏的思想：对于同一操作，如果被操作的对象满足它所要求的这部分条件（家族相似），就可以被同等对待。

至于对象，维特根斯坦更是从来不把它们作为世界的基本组成单元。他认为的基本组成单元是事态（见《逻辑哲学论》）。其实一些比较严谨的脚本语言（例如Python）在描述世界方面可能更有优势。但我们已经习惯了强类型的OO，而且强类型也的确有很多好处，所以常常把强类型也作为OO的必要条件了。

[fixopen]

我并不知道现实世界是什么样子的，甚至可以说，我并不关心。我只关心我眼中的世界，我理念中的世界，我感觉中的世界。就象现代的物理学一样，基本的对象并不是物质（或能量），而是事件一样。我觉得真理不是世界是什么，而是世界象什么。非让我去认识到事件是现实的和基本的，我觉得很委屈我。

就因为我们没有办法对现实的世界进行准确无误的分类，所以预先定义接口并且保持接口不变是不方便的。关于软件中的“软”，我想必须要改变一种看法，不能通过继承和扩展，而是通过推导和演算来表示。我觉得这样子，软件才能真正成为知识的体现，才能创造出价值。

[孩皮妞野]

有点意思。期待更多高人。楼主还是先不要结贴吧

[liu_feng_fly]

怎么变成讨论哲学了，呵呵。
to fixopen(dup) ：何为推导，如何演算，或者说你心中的推导和演算是什么样子的，我们需要向编译软件/语言提供什么？仅仅是算法的描述？那么类型信息呢，静态的，动态的，还是语言可以聪明到自己推导出来而程序员完全不必关心？

[fixopen]

我想，现在的函数式语言（我是指静态类型的）具有的那种类型推导能力就比我们熟知的OO类型系统优秀吧。比如说LOOM，Haskell等。当然，因为很多现代的函数式语言都限制了自己的领域或范围才达到不必有程序员关心而由编译器自动推导出类型信息的。说句玩笑话，我们使用Excel的公式时肯定不会关心它的类型吧！：）

[Schlemiel]

恩，当你说“类型推导”时，你心里装的还是强类型的价值体系。Excel的公式肯定不用约关心类型，同样，Python也不用。OO并不要求强类型，我们只是习惯了强类型而已。不知道你对脚本语言（尤其是Python）有多少了解？当我最初接触Python时，感觉那是一种价值观的颠覆，很多难上加难的东西到了它那里变得顺理成章了。

比如泛型。记得那个时候，myan和babysloth很喜欢谈论泛型，谈论泛型给C++带来的正交分解。但是Python社群从来没有“泛型”这样一个词，以后也不会有，那是他们觉得再正常不过的一种东西。只要你愿意，你就可以在Python中使用那些花里胡哨的技巧，而C++社群还在抱怨VC对标准的支持不足呢。

[fixopen]

Schlemiel(维特根斯坦的扇子) :
谢谢你的回帖。我觉得Eiffel最强大的好像不是什么多继承的改名机制，而是采用多继承时仍能满足子类就是父类（类型替换）这一严格的要求，我觉得这里面有部分继承或者更有趣的技术。据我所知：是有一个any类，但是我不知道有没有none类，能详细说说它以及相关的好处么。

我承认C++ STL提出了一个不错的正交分类的方案，但是，那也是在现在的知识基础上的正交分类，我们对现实世界的理解的改变，会影响到我们的正交概念的。对于类型协变，我认为这是现实的一种特点，所以语言如果支持的话，会提高对现实世界的建模能力的。

[renren6250]

up

[wingfiring]

好文，学习中......

[短歌如风]

　　记得我曾和一个朋友讨论有关“动态类型”的问题，我说动态类型目前不适于用来开发大型复杂的项目，他用“随着硬件的飞速发展，时间效率不再是编程时首先需要考虑的问题”来反驳我，我说是的，但动态类型的问题不只是在时间效率上，而是增加了排错难度。由于对象类型可变，编译器将无法在编译时确认对象的类型，从而无法做类型检查，结果会导致类型错误从编译错误变为运行时错误，当错误发生时，你必须了解错误发生时的程序运行状态而不是编译前的静态状态，才能发现错误产生的原因（可能距报告错误的地方很远），而我们知道这是一件难度很大的工作。动态类型在作为脚本语言在开发微型应用时可以给编程带来很多方便，但在拥有很复杂的逻辑和规则的工程中会给你带来很多麻烦——除非你可以保证你的小组不会产生错误代码（我保证不了）。

　　正交分类听上去很吸引人，但应用起来就未必很甜美了。我同意fixopen说的“就算有了正交分类的标准，它也未必能满足无限丰富的世界的现实要求”，事实上对现实进行分类很难，但比起对现实进行正交分类的抽象，恐怕要容易多了。进行正交抽象需要一个非常规则的领域，而现实很少是规则的。

　　此外，还有一个开发思想（更重要的是对现实抽象的理念基础思想）和在这个思想下的方法的问题。在很久以前，OO思想还没有发展成熟，缺乏有效的方法时，曾试过把它和传统的面向功能、数据的方法结合起来，就是在分析、设计时使用传统方法，而是实现时使用OO方法，结果并不理想，结果得出“面向对象方法只适用于自底向上的开发，可以用于可重用库的开发，不能用于实际项目”的结论，而现在我们知道这种说法是错误的。其根本原因就是OO方法和传统方法对现实的抽象思想不同，把它们结合在一起是很难的。两种不同思想的方法可以相互补充，但一般都是处于同一阶段的，要想让一种思想下的方法的结果直接供另一种不同思想的方法（在新的阶段）使用，由于它们对现实的理解都不同，经常都是格格不入的。所以，一种开发思想是否有一套完整成熟的方法是这种思想是否实用的关键。GP其实是不同于OO的另一种思想，但由于缺乏方法，才使它仅被看做在编码阶段对OO方法的补充。楼主所说的“类型推导”我现在还不很了解是怎样一种思想，我想也会遇到“缺乏方法”这个问题。

[何哀何欢]

来，捞点份

[fixopen]

是的，我确实有一个强类型的世界观：）。我觉得我们如果泛泛的理解世界，并不需要强类型，但是，如果我们通过图灵机来理解世界的时候，它们是强加上的限制。我对Python有一点了解，它最大的特点是动态类型，或者说类型作为一种对象存在于它的观念中。但是，我们表面上需不需要关心类型，跟实际上它内部实没有实现类型是两码事。

[taozhangzhi9]

程序= 数据结构 + 算法

[bm1408]

to:njuhuangmy(茶)
i don't agree with you!

this is a wrong thing!
forever you will understand!

[gywh]

up

[fixopen]

to plainsong(伤心的风★短歌) ：
其实，我倒没有想到动态类型的查错问题，嗯，这真是一个问题。我所谓的类型推导其实也是一种类型系统，但是它不是程序员给定的，它是编译器推导出来的，它可以是静态的（如：Haskell），也可以是动态的（如：scheme）。动态的确实会极大的增加程序的隐患，并且妨碍了优化的进行。

对我来说，既然软件系统是对现实的一种抽象，那么，软件系统表现出我想让它表现的特征就行了，所以，静态类型系统可能也不会是一个很大的限制吧：）