2008年（29）
分类：
2008-06-10 12:00:36
（越写越感慨数学学的太烂，下边有些内容问题用数学的语言来说会更清晰，不过……）
从本质上模拟“人”的基本运算过程（不包含推理）的冯氏机（话说大学的陆桑称冯氏体系已被推翻，我认为他在口胡）开始，人类的数学发展开始在另一种体系上重新构建。
先是冯氏机所确立的“扁平”的、“逐步”的运算模式（导致某些方程无（精确）解）。然后是多种基于编译预处理、虚拟机的运算模式（可能这时候再叫“运算”已经不太恰当了）。考虑到软件理论的发展，这其中的一个主要变化就是分割的单位。从机器语言的语句，到所谓“过程”语言的过程，再到面向对象的对象、函数式编程的函数。
随着这些发展，软件专有的理论概念也在补充。
无视“重用”、“继承”、“多态”等等等等对面向对象的不完全理解所产生的纷繁复杂的附庸，我所理解的面向对象，就是将数字逻辑世界与现实世界类比起来。（但是，这种概念的现实是浅尝辄止了，数学性的艺术仍回到了蓝领们的胡乱堆砌上。）
将数字逻辑世界与现实世界类比，软件是什么？
对管理角度而言，它应该是一种生物类型的一个具体个体重生到死的过程，好比一个细胞。而对应用角度而言，它是一个小生态圈，若干“对象”在里边“鲜活”的生存，互相交互着，同这个世界外部的力量（用户等）交互着。
所以，我理解T桑的感叹，因为目前的面向对象理论方法技术，都是狭义的面向对象。
目前常见语言都是为单执行顺序设计的，所以当对象甲与对象乙交互的时候，交互的发起者是僵死的，等待另一个对象的交互结果，这段时间发起对象不会再做其它任何事情。也就是所有的灵魂在一个肉体上互斥的活着，只是共存，完全没有实现“共荣”。同时因为这种结构（正如T桑所言，有些东西是需要语法语义的支持的），使得系统主动的并行不可能实现，因为单位之间没有完全隔离。
于是有了被动的并发，多线程、多进程什么的，人为的分割整个运算流程。而在这些情况下，面向对象就更伪了。因为存活在另一个线程或进程甚至是运算单元上的是一段过程，根本不是对象，更没有本意上的对象交互。
于是，并发被认为是对面向对象的“离经叛道”。因为目前的面向对象，只是用来实现面向对象规范下的分类学而已。更多的片面理解将“对象”搞得冗杂而丑陋。
那么是大家看了这篇文章，顿悟了之后，广义面向对象就欣欣向荣了吗？非也。再次引用这句话“有些东西是需要语法语义的支持的”。
目前常见的语言，在“分割的单位”的彼此隔离上，支持很差。导致要么是程序员自己绞尽脑汁的写出好结构程序，要么就是一团比goto面条好不到哪去的东西。
说到这，该说“函数式编程”及相应语言了。
如果说程序结构从过程发展出对象（理论意识也随之发展），那么我们回过头看，过程的高级形式：函数。
函数式语言中对“函数”的定义是很严格的，我认为其中最重要的一点是“无边界效应”。这一条约束，使得“‘分割的单位’的彼此隔离”在语法语义上就得到了（这甚至都无法叫“实现”，它就在那）。进而在erlang对并发功能的一些支持上，写出一个能并发的程序变得很简单。
不过这仍是机器被动的。编程的发展，基本表明，性能和易用性是翘翘板的两头。（不过话说开发出接近c性能的ruby虚拟机了。）在这个前提下，我认为能够实现“机器主动”的并发是必要的。这种情况下，我们只需要按单线方法写程序，编译器、虚拟机会自动按逻辑结构推导，进而将能并发的函数并发执行，尽管它未必是最佳的并发分割方式。而到这时候，并发才算真正普及人心，实现产品的泛滥。至于它的可实现性，考虑现在cpu硬件的多射，以及haskell编译器“奇妙”的类型推导等，我觉得不必疑虑。
说到函数式编程，我想说一下sql，虽然有无数人骂ibm发明的sql，“难懂”、“结构复杂”、“解释器难以实现”，我却认为sql这种唯一常见的“结果定义语言”是有着数学美的。
就好象很多领导说的“我只要结果，我不要看过程”。数据库查询这种特定环境，使得在人力条件下根据局部情况确定的查询策略（是否使用索引啦，是否用循环遍历啦……）不会比数据库自己使用的更好，并且要浪费很多资源。而我们使用计算机，不也就是想看看“结果”吗。在其它领域，比如企业应用（现在都有标准模型了）等，也许会有更多发展。
跑远了。如果将函数比于过程，可见对象也会有个“高级”的形式，而这个高级的形式也将实现对象的隔离性。那个时候，面向对象和并发会否如几十年前所畅想的那样结合，真正实现对“现实世界”的建模？很值得期待！
最后说一下微软。虽然微软的产品我十分厌恶，但不可否认.net是个神奇的东西。T桑称微软是目前几大语言并发化唯一找对方向的。而如果.net找对了方向，那其上的多种语言及其程序员都将受惠。（所以我很鄙视绑定语言的东西，air、svg等，只提供ecma脚本支持，人为的设定隔离，想保住ecma这种糟糕的语言的工作者的饭碗吗？历史证明，封闭的东西必死。）
