面向集合的框架设计

    判断和循环是程序中最基本的语句结构。而在vonNeumann体系架构下，循环是对集合进行操作所需的基本步骤。一个有趣的事实是，函数式语言所宣称的 生产力的来源很大程度上在于集合操作的便捷性。在数学中我们通过张量分析，泛函分析等可以清楚地意识到集合之间的相互作用是可抽象的，是可以独立理解的， 即我们可以在不涉及具体基元结构的层面上独立的定义并执行集合运算。如何将这种概念独立性在框架层面展开是一个非常深刻的命题。
    在基元结构上应用基础操作p(d)这一微观场景一般情况下是容易理解并实现的, 但通常程序中所定义的大量边界是基于集合变量的, 因此很多代码都是封包和解包操作, 在层层嵌套的循环结构深处我们才能发现真正具有业务价值的基元结构. 将集合操作提升到系统层，减少或简化在应用层需要显式编制的循环结构是框架设计层面需要考虑的问题.
    一个最基本的方法是尽量定义通用的同构操作, 避免构造中间集合. 例如前后台之间通过json等通用协议交换复杂结构的对象, 避免定义特殊的中间处理过程. 一个与之相配合的重要技术手段是通过类查询语句(描述方式)直接构造特定的集合. 例如prototype.js中提供的$$('div div.myclass').each(op)这样的处理方式显然要比在循环过程中基于特定条件过滤要方便的多. 而在AOP操作中切点的集合定义方式也是其提供的核心价值之一. 与集合操作相适应的一种代码风格是流式设计(stream), 这正是jQuery试图鼓吹的主要价值(虽然我个人认为它有些走极端). 流式设计的核心结构实际上是 x += dx, 它不需要集合是一次性构造的, 便于支持一种逐步部分修正的概念模型.
    为了支持集合的隐式构造, 我们需要以通用的方式定义元素到集合的组装规则. 在Witrix平台的前台js框架中我们定义了由独立的html组件到复合查询条件的拼接规则, 定义了由每个html组件的数据校验函数到整个form的数据校验函数之间的组装规则, 定义了由单个html组件提交参数到整个form提交参数之间的组装规则. 在Witrix平台的标准界面上, 框架本身的编制基于js.query.buildCondition(frmQuery), js.validate.validateForm(frmUpdate), ajax.addForm(frmUpdate)等少量集合操作进行, 在不同的应用场景下, 我们只需要关心每一个字段如何显示, 提交哪些属性, 而由系统负责将它们自动组装并在后台进行分派. 面向不同的应用, 框架代码不需要做出任何修改, 确保了系统结构的可重用性.
   Witrix平台的后台处理模型中定义了实体化过程, DaoWebAction基于CRUD等原子操作定义了批量提交, 数据导入导出等复合的甚至是嵌套的集合操作. 在不同的应用中, 我们通过修改bizflow文件中<action id="ViewDetail-default">, <action id="Update-default">等针对单实体的业务规则即可适应不同的业务场景, 而不需要为特定的应用重复编制集合处理过程.
    面向集合+通用组装规则是Witrix平台设计中采用的基本设计手法之一, 它使得我们在一般应用中只需要考虑单实体,单字段等基元结构上发生的特定业务, 大大简化了系统构造过程. 但是也需要认识到从个体到集合的扩张(p(d) -> P(D) )是非平凡的, 集合比个体的简单加和要更多, 为此架构中需要保留对集合边界的识别能力, 例如需要允许在数据导入完成之后执行特定的业务规则而不是仅仅针对每一数据行执行业务规则.

评论

29 楼 canonical 2007-12-09  

引用

创新往往要不师古，但不师古未必就是创新，而是比拼合适的选择并加以利用。

你这话我很同意啊, 关键是和我们的讨论有什么关系. 你不要总是试图在本质上证明我所说的所有的东西本质上都是无意义的.

引用

世界上有3000~5000种编程语言，支持函数式编程的约有1/4。事实上，不可避免使用函数式编程的领域几乎是没有的，即便是对程序效率要求极高的地方，使用编译后的 ML、OCaml、Haskell 一般都可以获得比命令式语言更高的执行效率，开发效率就更不用谈了。

这件事实与我们讨论的问题有关吗?  我说过函数式语言执行效率低吗, 我说过函数式语言的开发效率必然低吗. 可是在所有领域, 函数式语言开发效率都比其他语言高吗? 再说不同的函数式语言之间的开发效率难道就没有高低之分吗? 比如在其他函数式语言你开发类似ErLang解决的那些程序问题试试?

引用

行了，差不多了，不跟你吵了。最后祝愿你的系统在消亡之前得到证明或者是验证

我没和你吵,只是耐心的和你讲道理. 此外我们所讨论的一切和我的系统有什么关系? 所有的系统都会消亡的, 但我只是要解决现在的问题. 你不觉得你的思维方式中只有永远,没有现在吗.

引用

不要因为 Erlang 名气响就把它拖来说事，它还算不上FP中的第一

你这话不还是说函数式语言之间还是有区别的吗.

我的系统的意义需要什么抽象的证明吗? 用户在用我还要证明什么存在的意义? 用户在用不是一种实践吗? 你到底对实践是怎么定义的.

首先我的原帖中并没有宣扬什么解决问题的灵丹妙药。我只是说结构问题是语言中立的， 是需要独立于语言来看待和认识的。 这一观点有什么创新吗，我看不出来。在物理领域， 我们早已接受了如下事实： 物理问题是独立于数学问题存在的， 我们需要建立单独的价值观和思维方式。

为了避免我有人身攻击之嫌,此处我删除一些话语. Licy_Ray现在要求和我改为站内短信交流. 他不回帖不意味着他改变观点

28 楼 Lich_Ray 2007-12-09  

不需要说你什么时候说过，更不需要掩饰什么，你的系统无非是这一类东西，或者更差。不服气吗？我本来不想说你忽悠客户的，但你自己既然这样说了，那我就不客气了：我可以用 JavaScript 轻松地构造出同样有力的程序而不需要任何所谓“框架”，因为函数式编程对于语言的依赖要求更少。你的框架，作为一个产品，当然是有价值的，但不是所有有价值的东西都有继续存在的价值，这一点我希望你能明白。
再说抽象。真的难以置信一个懂得理论和抽象的价值的人会说出这样一番话。你当然是知道我所说的东西的，但很明显，你仍然站在拜火教的一方为自己并不高明的系统在不停的辩解。我没有对你进行任何人身攻击，第一个脏字是你说出来的，请不要忽视这一点。
我曾经一度怀有非此即彼端幻想，但是，我在学习了近40种编程语言和几十篇经典论文之后放弃了这种幻想，代之以新的幻想：世界上将在一两个强大的数学模型支持下出现无数的领域特定技术来供我们选择，仅因一时之需而产生的东西将被理性地融合。这是我得出的结论。
就拿函数式编程来说，你说“难道所有的函数式语言都是一样的吗？”，正说明了你对函数式编程的不了解。事实上，函数式语言，几乎都是一样的，不同在于这个纯一点那个不够纯，这个用的是应用序求值那个是正则序，这个IO是简易的那个是基于延续的，这都只是“人民内部矛盾”，不是本质性问题。Lambda 演算告诉我们，只要一个语言能够支持闭包就可以进行函数式编程，差异不过是一点语法和程序长短。我写过一篇小文就举了这样一个例子：http://lichray.iteye.com/blog/101055。众多的函数式语言正在验证我前文提到的猜想。

*** 我在贬低你吗？我当然知道你理解理论和抽象，但你表现得完全像一个不理解的人。你在掩饰些什么呢？是你框架中使用的 Java 又成了哪门子“独门暗器”了？我只不过是提醒你而已。相比之下，倒是你总说别人不懂物理不通数学，而且没有拿出任何东西来证明，现在还不觉得有愧，还在追问别人自己哪儿说了脏字。没关系，那不是脏字，不会被搜索引擎过滤掉的，满意了吧？
*** 我所理解的框架是什么？核心的编程技术罢了。如果你能学习了一种思想之后，做到对很多问题拿到手就能迎刃而解，你心中就有了框架。
*** 我当然不认为计算机的问题都解决完了，计算机发明了不过60年而已。但要解决这些问题，需要的是冷静的头脑和潜心地研究，而不是在那之前动辄就发布新系统！弱水三千，我只取一瓢饮；解决的路有很多，我只选择一两条。
*** 你以为我提及你的 Java 是惧怕吗？未免有些自恋了吧？我当然不会推荐只用xx语言甚至是只用xx思想，但我肯定不会推荐一个不使用xx思想的产品。创新往往要不师古，但不师古未必就是创新，而是比拼合适的选择并加以利用。
*** 编码当然必要的，但我们来看这样一个例子：如果某个项目原本要1000行代码，因为使用了某个框架，只需要500行，但再在不同的领域碰到同样的问题，你又得换框架；但使用某个思想也只需要500行。你选择哪个？心中有正气，不怕鬼敲门。这是我所追寻的。
*** 世界上有3000~5000种编程语言，支持函数式编程的约有1/4。事实上，不可避免使用函数式编程的领域几乎是没有的，即便是对程序效率要求极高的地方，使用编译后的 ML、OCaml、Haskell 一般都可以获得比命令式语言更高的执行效率，开发效率就更不用谈了。

引用

可是在所有领域, 函数式语言开发效率都比其他语言高吗? 再说不同的函数式语言之间的开发效率难道就没有高低之分吗? 比如在其他函数式语言你开发类似ErLang解决的那些程序问题试试?

就我个人及遇到的问题而言，的确如此。还有，不要因为 Erlang 名气响就把它拖来说事，它还算不上FP中的第一。
*** 行了，差不多了，不跟你吵了。最后祝愿你的系统不要在被证明没有意义之前就已经消亡了。

27 楼 canonical 2007-12-09  

我什么时候说过“把对象打包成collections，封装循环细节，循环组件化，自动选择相应类型的迭代器，连结处理过程，不就是你的系统的思路和技术吗”。

如果你不清楚就不要随便议论。此外即使我的论点是重复的，我又不是要解决icon的问题，不是要把这件事情推到语言层面。我可以用现在其他方式都不可能的方式解决我的问题，这不就是价值吗？ 你说我挣客户的钱是忽悠客户吗。我在有限资源的情况下挣到了钱，我怎么就失败了呢

退一万步说，ok, 我的实现没有某个伟大的函数式语言优美。但是我的论题是某种结构问题是具有独立价值的，它和语言是无关的，只要解决了这一结构问题就能带给我们价值，而不需要依赖特定的语言的。你回帖从来不看帖吗。

即使是函数式语言，你认为所有的函数式语言都是完全一样的吗。难道你认为它们之间不存在某种结构性差异吗。你觉得那些不停发明新的函数式语言的人大脑都进水了吗。

说我不懂抽象，你的论据从哪来的。我真的无法想象。我基本学过数学系，物理系，计算机系的所有课程，怎么会不知道理论和抽象是什么呢。你除了毫无意义的人身攻击和无哩头的预言之外，还能再说点什么？

非此即彼，天下唯我,难道不是我们思维中经常陷入的一个误区吗

26 楼 canonical 2007-12-09  

首先不要先质疑我的正常思维能力。做人身攻击只会暴露自己的虚弱。如果你想从辩论中获得一些什么，应该仔细看一看别人论述的整体，而不是抓住只言片语，用自己的理解歪曲后喷发一种不屑。

没有人否认抽象的意义，但是抽象是否就是抽象到无穷大，这是个可以明确定义的问题，也是数学领域正在解决的问题。如果你懂得更多的物理便会明白我的话语，例如学一点摄动分析。

我所说的正是说：你明白了终极的意义，明白了一种推向无穷的抽象并不是理解了世界的全部，我们仍然要明白如何解决一些更加小范围，但是却又普遍发生的事情。

在我们的思考中没有明确定义何处是边界，没有明确的限制，这便是导向无穷的一种思维方式。和现实中是否真的允许创建无穷多的线程无关。 这是理论上的问题，其实是一个抽象的问题。

说到10这个确定的数字，不过是一种极端化的比喻。我常说概念是连续的，并不是非此即彼的，因此并不是从一种普遍情况到一种最特殊的情况之间不再有其他情况了。 在这中间环节，存在着非常深刻的复杂的物理事实。但是这些事实却又是某种有限性向我们揭示出来的。（请不要把这里的有限性理解为算术中的10以内）

没有人说要放弃探索，实际上我一直强调要探索。只是需要调整一下观察的视角，我们便可以发现一些新的东西。其实作为一名探索者，如果我说的话语是反对探索的，反对证明的，那我如何解释自己的行为呢。

你并不了解我的系统，评论什么呢？

引用

你的系统，在你用理论证明它的强大之前，是不可能被足够的现实应用证明它的有效的

这句话的逻辑非常奇怪，在理论证明之前，实践无法证明。。。。 如果你说的是我的系统，我的系统只要为我解决问题，我需要证明什么呢。证明我会节约开发成本，还是客户会多付给我费用。我现在做事情比所有想见的其他方式都要更加迅捷，我还需要证明什么？ 如果你说的不是我的系统，那么别人的系统在用理论证明它的强大之前，就能够被足够的现实应用证明它是有效的？

现在来一个理论推演吧：
1. 任何系统都在一定约束下运行，即它们需要符合某些约束条件
2. 通用语言描述了某些结构，但是这些结构是充分通用的，能够应用到尽可能广泛的领域的
3. 线程数=10这个约束过份特殊，显然通用语言是不会考虑这个约束。实际上目前在通用语言设计中，无限资源假定基本都是默认的。
4. 我们承认某些现实的约束通用语言是不会考虑的
5. 在最特殊的，明显不会考虑的约束以及非常通用，一般通用语言必然考虑的约束之间，是否存在着更多的，非平凡的结构呢
6. 假如10年以内我们所有的硬件都只能支持10个内核，在我的产品研发中假定10个线程有问题吗。难道我在开发的时候就不再需要抽象了吗。我在其他方面仍然是需要建立抽象的。
7. n个抽象约束+1个具体约束，以及 n个无限约束+1个有限约束 仍然是有效的抽象形式。原谅我在这里又使用了有效一词，它真的很难理解吗。

我说到函数式语言的时候，基本的态度就是说不要太沉迷于一种特殊的抽象方式，应该多看看别的视角。在不同的情况下存在着做事情的不同的最优方式。 我这句话你有异议吗。

现在计算机领域所谓的理论主要是基于数学视角的，没有考虑物理世界因为我们观察的有限性，因为资源的有限性所造成的种种约束，此外数学中目前也没有考虑到物理世界真实的各种复杂性的存在。在我们想到一种计算机理论的时候，图像过于简单化，这种简单化被认为是优美的全部。其实我们应该思维更加开放一些。

做研究是靠真正的工作，而不是靠一种宗教信仰。

引用

但你才写了几年程序，就自认为比100年来的数学家和计算机科学家眼界更广

我为什么不能比他们眼界更广，他们所在的时代物理学的发展状况是怎样的。而且这是一种人身判断，有意义吗。

引用

你的系统是40~50年前已经被抛弃了的东西，体现的最出色的两个语言是 Apl 和 Icon

你这话从何说起？你了解我的系统吗？ 再说我的系统怎么样和我现在讨论的问题又有什么关系呢退一步说我的系统不

好，我的论题就不存在了吗？这是什么逻辑。

我并没有说我要创造一种新的语言，我只是要解决自己工作中的问题。现在你说神已经确定了两种通用语言：函数式和逻辑式，这和我的论点冲突吗。除了语言，计算机世界便是荒芜的沙漠吗？如果你认为所有的问题都已经研究完了，那么世界上每年那么多研究经费拿来干什么了？ 为先贤的理论擦屁股吗？

25 楼 Lich_Ray 2007-12-09  

canonical 前辈真的很能扯。其实吧，我觉得他生下来就可以去死了，反正他的“终极意义”也就是去死；他其实也不需要学习什么编程语言，只要发明一种能快速重组几亿个晶体管的技术就可以了；他也不需要学习物理学，因为他看不见物理学的模糊本质在数学中的体现只看见了其在自然中的体现。既然你已经生在自然中了，那还要学什么物理呢？他也不需要学习数学，因为他只是看到了数学对于存在性的弱化表达而不去思考弱化的意义和力量，因此成为了某种形式的拜火教徒，现在正在举大旗反对我们基督教徒。
我沉默了很久，今天被 canonical 前辈唤醒了。愿拜火教的主保佑 canonical 同学在找到他的终极意义之前明白抽象的意义。

*** 你可以不信任任何抽象，但你仍然不能否认现实存在的抽象本质 ***
*** 从开普勒发现行星轨道是椭圆而不是圆的时候起，到现在杨振宁李政道发现宇称不守恒，人类明白过来，宇宙的美与人心的美有交集，但不相同；我们爱哲学、爱自己，但我们更爱宇宙。请别阻止我们的探索，我们不是圈中的羊羔 ***
*** 我们还远远没有抽象到无穷大的能量。人们研究了一千年物理，才写了几十年程序？请别打肿脸充胖子，小孩说大人话 ***

*** 没有人说过函数式语言能在所有的方面超过命令式语言，但我能用现有知识证明一个程序的完备性，难道这不是一种进步吗？ ***
*** 没有什么东西能够以其一贯的思路搞定一切，但你不能仅仅因为知道这一点就简单地放弃了探索，退回那个一切搞定你的时代 ***

*** 我认为丘奇等人已经给我们指明了一条道路，如果你也能用那样美好的方式把你自己的道路指给我们，我们也愿意尝试。但问题是你的系统没有让我们看到一点数学的或者物理的坚固和美，有的只是来自50年代计算机科学界的狂飙突进式的想法。也许在现在的几个角落有超过其他系统的价值，但这显然不是一个探索者、研究者所应有的态度。你的系统，在你用理论证明它的强大之前，是不可能被足够的现实应用证明它的有效的。

引用

你的系统，在你用理论证明它的强大之前，是不可能被足够的现实应用证明它的有效的。

没有任何逻辑问题，请注意前面“你的系统”四个字。既然你自认为自己的思维没有问题，应该能理解我在说什么。:)
眼界自然应该更广一点。但你才写了几年程序，就自认为比100年来的数学家和计算机科学家眼界更广？他们已经广了50年了，广了50年才选定的函数式编程，逻辑式编程这么两条路，你不认为你现在多少有些不自量力吗？也许我的思想有些在阻碍你创新的意思，也许你比我年长很多，但我还是不得不不客气地指出：真的，你的系统是40~50年前已经被抛弃了的东西，体现的最出色的两个语言是 Apl 和 Icon。节哀顺变吧。
如何说起？把对象打包成collections，封装循环细节，循环组件化，自动选择相应类型的迭代器，连结处理过程，不就是你的系统的思路和技术吗？去看看 Icon 就知道自己想法的落后和幼稚了，如果你仔细研究了函数式编程的思想，估计就会更惭愧了。
为什么要提到你的系统？你的系统就会成为无数个因为缺乏理论支持而失败的系统之一，难道你还没有这个觉悟吗？
无须多言，用不了多久，你就无言有须了，那时候也许你会重新审视一下理论和抽象的意义。

24 楼 canonical 2007-12-09  

T1你和我争执的问题已经远远偏离了我所要表达的意图。不过如果你愿意辩论具体的细节问题，我也奉陪到底。

引用

比如说懂得密码学的人回答这个问题,它会告诉你通过理论计算用穷举法破解多少长位的RSA密码需要多少多少计算资源，在这些计算资源上需要多少多少时间. 然后它会告诉你,即使你能够找到那么多的计算资源,等你破解完这些密码的时候，经由这些密码加密的数据早就过了有效期限.所以穷举法不是一种有效的方法.

这里其实定义了一个数学意义上的有效性。但是物理层面上我们说只要一种方法比另一种方法能够更快的解决问题，我们就说第一种方法比第二种方法有效，而无论密码被破解的时候该密码是否已经过了有效期限。

对于你的问题

引用

现在通用语言，去承载Erlang的Domain Specific Structure,，是一种什么样的方法

我已经做了说明

引用

关于ErLang的例子, 我的原意是用来说明结构问题是独立的,它是和具体语言无关的.即基于消息传递发生数据关联的超轻量级进程模型这一结构不是和ErLang语言绑定的. 为此我特意加了一段说明:"这里不是要证明某种语言中无法描述这些结构，而是说结构是客观存在的，它并不是要在基础语言层面得到充分解决的". 即使在语言层面我们并不解决这个结构问题, 它仍然客观存在着,我们仍然可以用其他的技术手段去定义,去解决. 解决了这个结构问题就必然会带给我们价值,而无论我们使用何种实现语言.

ErLang实现了一个结构，这个结构成功了，并不意味着这一结构是ErLang语言排他性的独有的。

我并不是说特定的领域结构无法在某个特定的通用语言中有效实现。我想这里你对我的话语有些误解。

引用

如果我们认为一种通用语言是比较稳定的,则它一般选择只内置一些通用的不带有领域特定含义的概念. 而缺乏领域知识,或者说因为通用语言故意的摒弃领域依赖, 它在处理领域相关的问题的时候并不是有效的.这种有效性不是数学含义上的,而是可以进行物理度量的.

现在ErLang对通信领域具有良好的支持，你可以说它对于通信领域的结构是有效的。但是显然在ErLang中编写界面就不如面向对象语言得心应手。在ErLang中实现界面结构的时候，它对于界面结构的表述就不是那么符合我们直观的，对我们的实现过程来说就不是那么经济的。因此在界面结构的实现上，目前我们可以说ErLang相对于面向对象语言而言就是不那么有效的。也许你会说ErLang做XX发展之后怎见得就更差。但是如果允许引入未来这一具有无限可能性的因子，我们基本上无法针对现实的情况作出判断。例如我们目前并无法证明广义相对论相对于牛顿力学是更加精确的，如果允许在太阳星系中增加越来越多的隐蔽的摄动星体的话。按照库恩的科学革命论，每一个科学时代都具有着自己的科学范式，它总是具有着充分的自我辩护能力。范式的更新意味着格式塔的崩溃。回顾历史，哥白尼刚提出日心说的时候，并不是在计算精度，计算简洁性上真的远胜托勒密的地心说，只是日心说的哲学隐喻撼动了人心。

  我说

引用

实际上现在的通用语言也是无法有效承载Domain Specific Structure的

这并不是意指在通用语言中无法针对特定应用作出特定扩展来支持特定的结构，而是说Domain Specific Structure是任意多的，作为通用语言它不应该把越来越多的结构内置在语言中(这不是很多人对ruby的希冀吗)，这么做对它来说首先是不经济的。同时某些特殊的结构在一定的场景下是有用的，但是把它抽象出来扩展到通用领域的时候，会出现有效性的丧失。例如现在我的系统中只需要10个相互依赖的线程，如果我们定死了10这个数字，显然我们可以发展一种这个领域特有的高效的一些算法结构。而抽象到通用语言中的时候，显然我们只能假设线程数是任意大，或者是充分大的，而无法充分利用10这一领域信息，因此在这个意义上我说通用语言不是有效的。关键是在数学的抽象推导下，一般人已经看不到了还有10这个真实物理数据的存在性。

   传统上数学使用的一种逼近范式是：当n趋于无穷大的时候，偏差趋于无穷小。现在物理学对数学的一种常见要求却是：当n限定在有限数量范围的时候（例如10以内），我们如何才能尽量减少偏差。这要求对小样本数学进行深入的研究，它所具有的物理内涵也是不同的。

   在物理的视角下，我们所关心的不是世界在终极的意义上能否分解为函数的复合，不是要导向一种宗教式的顶礼膜拜，而是强调要尊重自己所直接感受到的，充分利用我们因为在这个世界上存在而获得的直观意象，发掘自己的直觉，这样我们才能在无限复杂的世界上借助有限的信息做出选择。

23 楼 Trustno1 2007-12-09  

引用

"什么原因，什么样的约束条件,导致了现在的通用语言是无法有效承载消息传递发生数据关联的超轻量级进程模型". 这一命题并不是我原文中论点的合理推论.我并不是要说某一种特定的领域结构无法在一种特定的通用语言中得到支持.而是说如果我们认为一种通用语言是比较稳定的,则它一般选择只内置一些通用的不带有领域特定含义的概念. 而缺乏领域知识,或者说因为通用语言故意的摒弃领域依赖, 它在处理领域相关的问题的时候并不是有效的.这种有效性不是数学含义上的,而是可以进行物理度量的. 现在也有很多人认为ErLang并不是真正的通用语言,它是针对通信领域进行了特定结构调整的, 是内置了领域特定结构的. 而目前在ErLang上建立GUI的努力也并不算是成功.

既然你说这不是你的原话,那么我们就来看你的原话.

引用

关于现实中的结构问题，我无意去定义什么万能的描述能力。你可以用微分几何，积分几何，广义变分等等手段去证明圆盘是某种意义下的周长最短的东西，但是这一切对你发明轮子并无本质上的助益。不过可以说说现实中的结构。这里不是要证明某种语言中无法描述这些结构，而是说结构是客观存在的，它并不是要在基础语言层面得到充分解决的。实际上现在的通用语言也是无法有效承载Domain Specific Structure的。

请注意，我这里并没有要你讨论,某一种特定的领域结构无法在一种特定的通用语言中得到支持.

而是在问你，你的原话中,所谓的有效,指什么?什么样算是有效的?什么样又算不是有效的?


比如说,破解RSA密码采用穷举法从理论上是可行的,但是采用穷举法是无效的.我现在没有要问,穷举法能不能破解RSA密码,而是要问为何说穷举法是没有效率的.比如说懂得密码学的人回答这个问题,它会告诉你通过理论计算用穷举法破解多少长位的RSA密码需要多少多少计算资源，在这些计算资源上需要多少多少时间.然后它会告诉你,即使你能够找到那么多的计算资源,等你破解完这些密码的时候，经由这些密码加密的数据早就过了有效期限.所以穷举法不是一种有效的方法.

好,那么回过头来看你的问题,你说现在的通用语言无法有效承载Domain Specific Structure,并且举了三个例子,Erlang，AOP，面向对象.
那么首先请问,使用现在通用语言，去承载Erlang的Domain Specific Structure,，是一种什么样的方法?
如果你认为这种方法,不是有效的.那么请问，你认为实现Erlang的Domain Specific Structure的有效方法是什么，不一定是在语言层面上,用你的原话来说,

引用

也可以通过框架等实现, 或者表现为某种设计模式,某种编程技巧.

.任何方法都可以,唯一的要求就是希望你能去掉某种这个形容词,然后给我们一个切切实实,看的见摸得着可以分析的实例.


最后请问,这两种方法,相比较起来,为什么说前一种方法，要比后一种方法有效?

22 楼 canonical 2007-12-09  

    我在前面的文章中列举了大量物理学相关的例子来试图说明采用物理视角的必要性,但是可能因为物理事实大家不熟悉,结果直接被无视了. 在本文中我想有必要举一个软件领域的例子。只是在实际思考的过程中,我主要还是基于物理概念进行推理.
   
    首先我所谓“现在的通用语言”，它并不意指“现在至未来所有通用语言之合集”，而是指“目前正在被使用的某一种通用语言”，这种差别便体现了我所强调的不同的价值观和不同的视角。不是一种覆盖一切的全称判断，而是在特定物理约束下的物理实体。
   
    现在无论我们设计什么大型系统，一般总是要优先考虑微内核设计。但是很显然，如果我们的编程控制能力极强（强大到不现实的地步），我们可以把所有的代码实现为一个大的整体。一个整体的好处是勿用质疑的，否则Linux Torvalds就不会有信心和Tanenbaum PK。但即使是Linux, 随着系统越来越庞大，在内核中也补充了很多模块管理策略。我并不把这种情况看作是一种现在技术能力不到位所造成的结果，而是把它看作是在现实的物理约束下所促成的一种必然的选择。
   
    按照类似的逻辑，我认为在通用语言层面不应该导入越来越多的特征，实际上也不可能把所有可能的结构方式都内置在语言中（这种不可能不是数学意义上的不可能）。这会破坏一种语言的纯洁性，使得它极难维护和发展。为了扩大通用语言的有效应用范围，一种显然的方式是在语言中定义一些支持结构再次抽象的机制，通过可插拔的方式实现与domain相关的知识的融合。ruby这样的语言提供了大量的元编程机制, Witrix平台中tpl模板语言也发展了一系列编译期结构构造技术, 但是显然它们都不能说是结构抽象技术的终极形态. 目前我对所有通用语言所提供的结构抽象和结构组装能力都是不满意的,因此在Witrix中发展了一些领域特定的结构融合手段.例如根据"继承"关系的结构诠释(继承可以看作是两个一维集合之间的覆盖关系), 我们扩展了extends的结构操作方式, 定义了广义的extends算子. 这些特定的结构关系目前在领域特定的BizFlow语言中体现, 它们在通用语言中是难以想象的, 而把它们放置在通用的语言中也是不合适的(这种复杂的结构融合操作如果不能结合领域知识进行直观的理解, 必将导向一种思维的混乱). 这就是我所谓"现在的通用语言无法有效承载Domain Specific Structure"的含义. 这种说法其实类似于"集合论是无法包容所有数学结构的". 我们在集合论中只研究最普遍的关系,而特定的结构在特定的学科中研究.
   
    关于ErLang的例子, 我的原意是用来说明结构问题是独立的,它是和具体语言无关的.即基于消息传递发生数据关联的超轻量级进程模型这一结构不是和ErLang语言绑定的. 为此我特意加了一段说明:"这里不是要证明某种语言中无法描述这些结构，而是说结构是客观存在的，它并不是要在基础语言层面得到充分解决的". 即使在语言层面我们并不解决这个结构问题, 它仍然客观存在着,我们仍然可以用其他的技术手段去定义,去解决. 解决了这个结构问题就必然会带给我们价值,而无论我们使用何种实现语言.

    "什么原因，什么样的约束条件,导致了现在的通用语言是无法有效承载消息传递发生数据关联的超轻量级进程模型". 这一命题并不是我原文中论点的合理推论.我并不是要说某一种特定的领域结构无法在一种特定的通用语言中得到支持.而是说如果我们认为一种通用语言是比较稳定的,则它一般选择只内置一些通用的不带有领域特定含义的概念. 而缺乏领域知识,或者说因为通用语言故意的摒弃领域依赖, 它在处理领域相关的问题的时候并不是有效的.这种有效性不是数学含义上的,而是可以进行物理度量的. 现在也有很多人认为ErLang并不是真正的通用语言,它是针对通信领域进行了特定结构调整的, 是内置了领域特定结构的. 而目前在ErLang上建立GUI的努力也并不算是成功.
   
    在前文中我举了一个例子试图说明:"在限定的物理约束下，我们的选择范围会大大缩小". "比如说我现在有无穷多种方式从北京跑到上海，但是如果限定只允许用1升汽油，那么我们的选择就近乎于0". 这里并不是要说明加上物理约束之后,我们便没有任何选择了.而是说物理约束对无穷多的可能方式起了限定选择的作用, 它最终造成我们在具体的物理场景下可能只有非常有限的选择. 例如现在允许用100升汽油, 有多少种运输方式可以满足我们的要求? 如果允许1000升呢? 但是如果不考虑所有物理约束, 我们是否能够证明说: 飞机和拖拉机的运输能力是完全一致的, 因为它们都能从北京开到上海.

    我的观点是结构问题是独立存在的,它具有自身的价值, 研究它也需要建立特定的价值观. 一个结构可以体现为语言上的某种语法特征, 也可以通过框架等实现, 或者表现为某种设计模式,某种编程技巧. 我们在思考结构问题的时候并不是从特定语言的机制出发的, 当语言不直接支持的时候我们可以发展特定的实现技术支持它. 在未来的日子里某个结构可能被证明具有普适的价值,它会被吸收到某个通用语言中成为所有程序的支撑结构, 但是更多的结构永远都不会进入通用语言, 而是居留在某个特定的领域. 通用语言的发展并不是完全基于抽象的数学分析而进行的, 它可以从更加丰富的物理世界中吸取营养. 当一种结构进入通用语言的时候, 它所带来的绝对不只是一组数量关系,而是同时带来一系列经过实践检验的物理诠释.
    我所谓的领域并不是指业务领域, 而是结构领域, 一个可以定义特定结构的物理场景. 一个特定的结构仍然可以支撑着任意多的具体应用. 例如CRUD操作可以作为数据管理模型. BizFlow作为界面和单实体的交互模型.

    函数式语言为我们提供了一种具体的技术工具, 但是在现实的开发中, 为了有效的处理结构问题, 显然我们需要多种视角的组合, 而不是把所有可想见的图景都纯化为函数. 我们对世界的体验是多样化的. 这就是我所谓"世界比函数的集合要复杂"的含义.

21 楼 Trustno1 2007-12-08  

恕我这个死脑筋，再跟你较真一下.

引用

javasnet 写道

么问题（一个很具体的问题）是现有的通用语言无法描述的

一个人总是受限于他的知识范围，因此他也经常在自己的知识范围内篡改曲解别人的意见。首先我从未说过上面的话，我没有说过一个问题是现有的通用语言无法描述的。 我说的是

请等一下,请你这里思维不要跳跃，不要答非所问哦.这一句是javasnet说的.他把能不能描述和能不能有效描述混在一起,那是他的事情.请你直接回答我下面的问题.

引用

我不需要你去解决任意问题，我的关注点也没有世界那么大，我现在要的只是你对下面这个断言的证据.这个要求不算很过分吧。
引用
为什么消息传递发生数据关联"的超轻量级进程模型"，是通用语言是无法有效承载Domain Specific Structure?原因在哪里?

我可是在直接应用你的原话哦.

引用

现在的通用语言也是无法有效承载Domain Specific Structure的。

引用

比如说我现在有无穷多种方式从北京跑到上海，但是如果限定只允许用1升汽油，那么我们的选择就近乎于0。飞机和汽车的运输能力是相同的吗。物理学的一个基本精神在于一种物理性的约束是始终存在的。而事实上，我们在实际工作中也总是在各种有限的物理条件下工作。
也许有些人认为这种区分是无关紧要的，我们只关心某种终极的东西。但是物理学中有着太多的例证，说明在有限约束下，整个系统呈现出完全不同的性质。

既然有一公升汽油,那么为什么不先拿这一公升坐辆车往前开个几十公里,再往下走呢?是不是因为反正到不了终点所以干脆把汽油扔了?这就好比一个笑话，有人生了一个儿子,说反正他七老八十岁以后都要死的，那么不如现在把它掐死，一样是死.

既然你谈到了所谓的有限的约束条件，只要你能清晰化的表达你的思想,那我也不反对讨论约束条件.
那么我就把上面的问题变化一下，把原因和约束条件放到句子的前面强调一下,然后请你继续回答一下.

引用

是什么原因，什么样的约束条件,导致了现在的通用语言是无法有效承消息传递发生数据关联"的超轻量级进程模型"

我这个人很笨的,也没有念过什么物理学,看不懂那么多的物理学,哲学性的话题.只需要你罗列出个可以验证的1，2，3.然后我照你的1，2，3去验证一下.这恐怕是唯一能让我这样很轻佻的人再也不轻佻的办法.

20 楼 canonical 2007-12-08  

我说的事情很简单，但是你们一直不理解。这就是因为视角差异非常大。我想这直接妨碍了你们在某些方向的探索。

引用

canonical同学回答的逻辑性让我这个非数学/物理专业的门外汉觉得你的逻辑性不足以搞数学/物理

不要轻易怀疑别人的知识水平。当然如果你无法聚集起足够的注意力来理解别人话语中的细节，我也无话可说。

引用

什么问题（一个很具体的问题）是现有的通用语言无法描述的

   一个人总是受限于他的知识范围，因此他也经常在自己的知识范围内篡改曲解别人的意见。首先我从未说过上面的话，我没有说过一个问题是现有的通用语言无法描述的。 我说的是

引用

现实开发中所需要处理的结构问题并不是在语言层面得到充分解决的

引用

现在的通用语言也是无法有效承载Domain Specific Structure的。

请注意我的定语和动词的选择。其实我已经举了大量的例子，可能因为你们对相关的内容不熟悉，所以直接无视了。这也很对，符合物理学的精神。

   可能大多数人都知道函数式语言和命令式语言都是和图灵机等价的，因此它具有某种终极能力，怀疑它无异于怀疑我们世界存在的基础。但是请注意，这种等价性是数学性的。它潜在的要求是无限的能量和时间消耗。如果在限定的物理约束下，我们会发现我们的选择范围会大大缩小。所以我说

引用

函数式语言和命令式语言的计算能力相同，但是在具体的情形下它们的描述能力是不同的

比如说我现在有无穷多种方式从北京跑到上海，但是如果限定只允许用1升汽油，那么我们的选择就近乎于0。飞机和汽车的运输能力是相同的吗。物理学的一个基本精神在于一种物理性的约束是始终存在的。而事实上，我们在实际工作中也总是在各种有限的物理条件下工作。

   也许有些人认为这种区分是无关紧要的，我们只关心某种终极的东西。但是物理学中有着太多的例证，说明在有限约束下，整个系统呈现出完全不同的性质。在通信领域我们都知道Shannon定理，它的物理诠释是在有噪声的信道上可以有效的进行准确的信息传递。但是这一诠释只能在有限的数学精度（远大于我们实际需求的精度）上成立, 在绝对准确的数学意义上，这是不可能的事情。

   你觉得现在的通用语言做起领域相关的东西来很方便吗，这就是我所谓无法有效承载的含义。在这里我也没有否认"未来的牛语言可以轻松搞定目前难题"的可能性。

   因为所有的软件设计最终都要落实到某种代码实现上，所以怎么会有什么神秘的软件结构是现有的语言无法描述的呢。但是ErLang中那种高并发，支持错误恢复的程序结构是在其他语言中能够轻松实现的吗。很多人不是在潜意识中认为ErLang的成功是函数式语言排他性的成功吗，不是认为命令式语言无论如何实现不了ErLang的程序结构的吗。很显然，在命令式语言中是无法直接实现ErLang中的程序结构的，否则它就变成了函数式语言，但是所有发生在ErLang世界中的事实都一样可以发生在命令式语言的世界中。ErLang语言的编译器可以是使用命令式语言实现的，在终极的意义上，语言之间能有什么区别呢？

我说

引用

实际上现在的通用语言也是无法有效承载Domain Specific Structure的

还有另一层含义。通用语言设计总是要考虑到内置结构的某种通用性，设计时能够凭依的信息较少，因此不可能直接制造某种复杂的领域相关的结构。而目前已知的通用语言中提供的结构抽象的手段也不够强大（实际上我认为任何语言都不会强大到内置所有结构，也无法提供所有的结构抽象手段）， 相当于是把领域结构问题推给程序员解决。这就如同C语言把内存管理推给程序员解决一样。现在ruby比较流行不就是因为它能够动态处理很多结构问题吗，但是它现在所作的一切就是足够的了吗。难道二十年之后再来看这个语言，不能够发现它存在着巨大的改进空间吗。我们目前在Witrix中通过tpl模板语言，bizflow extends等机制，结合整体框架设计实现了一些与ruby不同的结构构造方法。这些手段都极大的增强了我们面对领域问题时的信心，也确保了我们的领域知识是技术层面上可积累的。但是即使这样，我对程序发展的现状就是满意的吗？难道不存在更加丰富的结构知识等待我们去发现吗？一般人总是习惯接受已经存在的现实，在有限的职业生涯中把它们当作不变的真理，却没有耐心的去思考如何去改变。

  我认为很多结构问题不是需要在语言层面得到解决的，而是应该在独立的结构层（平台，框架）进行解决。这意味着没有必要在语言层面直接内置某种特定的结构，内置某种特定的结构抽象手段。这基本类似于说不要把集合论扩大到包含所有的数学关系，请在别的学科分支中进行研究。需要注意的是，我所谓的领域知识不是特定的业务知识，而是从业务知识中可以分析得到的某种更加通用的普适的结构知识，甚至是可以使用数学进行精确描述的。

  现代软件发展的时间还很短，与数学和物理学这样深刻的学科相比，它无疑是相对幼稚的，是待成长的，是更加的不完美的。在程序构建的基本问题上并没有抽象出什么可以实际操作的精确规律。这是所谓Pattern在软件业流行的部分原因：我们希望用这种半形式化的方式捕获某种思考的结果。但是软件真的除了基于抽象数学的全局的全称性的证明之外，不能够在局部进行某种更加复杂，更加严谨的分析吗。

   我们说结构问题是独立的，这也意味着它和具体的实现语言具有某种意义上的分离性。通过一种语言书写的结构可以在另一种语言中得到表达。我们可以建立语言中立的技术结构。一种所谓的结构在概念上具有某种确定的形态，我们可以脱离具体的语言来理解它。例如我说

引用

面向对象的继承关系从结构观点上看是两个一维集合之间的覆盖关系

在java中我们可以直接使用语言提供的继承机制，而在C语言中我们就需要建立某种结构体，手动维持所有的指针关联。而在Witrix平台中，我们从继承的结构诠释出发，定义了更加复杂的extends算子，这就需要利用java语言编制特定的parser来实现了。但是显然，在思考的时候我们所有的思维指向是结构本身，而不是任何通用语言的语法。

   在物理学中，通过摄动分析我们可以清楚地意识到：同样一个物理现象对应的数学模型可以是众多的，但是在特定的参数区我们会选择某种特定的数学表述，并确定其中的待定参数。

   delta函数是物理学家狄拉克引入的，在Schwatz引入分布概念建立广义函数论之前，物理学家们已经使用这一函数工作了很多年。后来Abraham Robinsen利用数理逻辑方法，建立了非标准分析，通过模型论的方法精确定义了无穷小的概念，从更加直接的角度论证了delta的合理性。但是在物理学家看来，这些数学又有什么区别呢？物理学只是按照物理的诠释进行工作，具体的数学只是它可选的工具而已。

   物理的真理并不是蕴含在数学中的，它需要我们独立的探索，从与数学不同的观点进行思考，检验，最终我们才能做出真正的发现。广义相对论可以采用Riemman几何进行描述，但是它的物理诠释却是Einstein提出的. 没有人说Riemann或者Hilbert发现了广义相对论。另外一方面，因为Einstein的工作触发了对于微分几何的更加深入的研究，靠着物理直觉的导引，我们将这一数学分支推进到了难以想象的深度。"数学是无法涵盖物理学的". 这不是说最终物理学无法采用数学语言进行描述，而是说在这一发展过程中，所有思想的推动来源于物理学的经验，来源于我们在这个物质世界上所进行的反复验证。不是在一个封闭的小屋中，整天摆弄各种数学符号，我们就能够发明所有的物理公式所对应的数学。实际上，现在学术界普遍承认，没有物理学的推进，很多数学的进展是不可能发生的。

   物理系每天都在演算着Feynman路径积分, 但是所有人都知道这是没有什么严格的数学依据的.目前并无法定义路径积分的收敛性,但是所有人对此避而不谈. 只要形式演算合法,物理预测符合实验, 合理性的证明只是数学家们的事情. 在量子场论中所采用的重整化(Renormalization)方法不过是回避无穷大问题的一种形式手段.我们仍然无法在数学层面对所有的演算都给予合理化解释. 在更多的物理分支中工作，你就会发现物理学家的胆子不是一般的大。也许在未来我们能够发现这些物理过程背后数学机制的精确定义, 但也许最终我们也无法找到合适的定义方式. 但这对物理学家来说, 并不是很大的打击.因为指引我们的是物理直觉，是独立于数学的物质世界的意象。

   我所想讨论的不是某种终极意义上的可能性，不是绝对概念之间的冲突，而是在物理现实的约束下，我们如何才能有效工作的问题。我已经反复表述了自己的观点: "结构是可抽象的，是具有独立意义的。这就是Witrix所提出的面向结构的设计视角。不是强调对象的所谓业务含义，不是强调某种通用语言（例如ruby）的灵活的语法结构。在这之间存在着厚重的具有物理意义的可以进行结构分析的技术层". 也许有人觉得我说的这是废话, 但是当系统化的执行一种思想的时候,就会揭示出未预料到的可能性. 整个Witrix平台简单的说起来就是"面向结构的级列分析", 但是如何找到合适的技术形式来体现这一思想,则绝对不是一件平凡的事情. "在Witrix中我们实现的代码重用程度和程序整体结构控制能力是超越了目前已知的所有公开技术的。这不是什么哲学，而是我们在残酷的商业竞争中得以生存的资本".http://canonical.iteye.com/blog/126467

   在我看来，计算机领域充斥着纯数学的深沉遐想和从工程实践而来的轻佻常识，还没有注意到物理学所能带来的不同的同样深刻的视角。我常说，好好学习物理是必要的，因为这个世界远比你想象的要复杂的多。

19 楼 javavsnet 2007-12-07  

canonical同学回答的逻辑性让我这个非数学/物理专业的门外汉觉得你的逻辑性不足以搞数学/物理。不要误会，我是实话直说，对事不对人。T1一直想与你讨论的是：
什么问题（一个很具体的问题）是现有的通用语言无法描述的，进而想与你讨论该问题是否真的无法描述，这是一个实证的态度。你一直回避这个问题，你一直在说有些问题是数学/函数语言无法描述的。这是非常显而易见的答非所问。所以我怀疑你的逻辑思维能力。当然，更可能的情况是你看明白了T1的问题，但是由于某种原因（商业机密？）你不能说，所以你一直绕圈子。如果是后一种情况，你直接说明，大家也就不继续追问了。

18 楼 Trustno1 2007-12-06  

引用

数学是无法涵盖物理学的，现在的已知的数学工具是无法有效承载尚未得到充分探索的领域的物理的

是不是有问题是数学无法涵盖的?我们暂且承认有。那么有问题是数学无法涵盖的，与所有问题都是数学无法涵盖的，是不是等价的?再进一步说，有某种问题A真的是数学无法涵盖的，那么是否可以推断说问题B,C也是数学无法涵盖的？这当中的逻辑是否跳跃的太快了.
所以你拉拉杂杂说了那么多，其实你仍然在逃避我的问题.你怎么判断,某个问题是现今数学能力之外的?世界上的确有很多，现在数学能力无法达到的事情，比如说人工智能。但是这是否意味着,我们认识到的数学能力在任何地方都毫无用处?是不是10+10，你都要掰起脚趾头来算?

你有这样的价值观，有那样的哲学观点,我们当然可以互相尊重,这本身就是一个非常个人的问题.不过,你要是下了某种断言,那么我就必须要让你拿出让人信服的依据.

引用

我无法认同函数式编程的世界观。世界比函数的集合要复杂一些。

引用

我的观点是这和函数式语言中能否加入结构解决任意复杂问题无关。

我不需要你去解决任意问题，我的关注点也没有世界那么大，我现在要的只是你对下面这个断言的证据.这个要求不算很过分吧。

引用

为什么消息传递发生数据关联"的超轻量级进程模型"，是通用语言是无法有效承载Domain Specific Structure?原因在哪里?

说实在的，我就是个就是一个井底之蛙，我只关心巴掌这么大片天为什么是蓝色的?你跟我说，这天比巴掌大的多.这不是答非所问是什么?

17 楼 canonical 2007-12-06  

to dennis_zane:
1. 语言中的时间观念这个论题绝对不是我的原创
2. 我一直强调思维的连续性。不是说"B这样搞来搞去还是达不到A的高度"， 而是说我们如果把系统的特征逐个分解，到底需要做哪些工作才能逐步增加最有价值的部分，特征聚集产生的增值部分又是如何显现的。
3. 一种实现总是包容了太多的思想。思想错了，实现对了。实现死了，思想活着。

to T1:
  原先pojo说：

引用

在我看来，SAX API就是一种“在基元结构上应用基础操作”的API。只不过好东西因为简约而被视之简单，不入主流的法眼。

他这个说法有些基于哲学出发，所以我回复了一句自己的哲学

引用

因为我的理论物理学背景，我无法认同函数式编程的世界观。世界比函数的集合要复杂一些。

关于我的观点我想你也没有完全清楚。

引用

为什么不能用函数式语言处理

我的观点是这和函数式语言中能否加入结构解决任意复杂问题无关。为什么所有的问题不能在集合论中解决，为什么要有独立的数学学科。物理学所有的定律都使用数学表述，是否意味着物理学的真理蕴含在数学之中。我说

引用

实际上现在的通用语言也是无法有效承载Domain Specific Structure的。

其实与以下说法是类似的

引用

数学是无法涵盖物理学的，现在的已知的数学工具是无法有效承载尚未得到充分探索的领域的物理的

我说

引用

我所关心的不是语言层面的问题

这类似于说不要把所有物理问题都推到数学层面去解决。

我们应该研究独立的结构，应该建立单独的价值观和方法论。不要谈及一个技术进展的时候就说某某语言好，不是一说到DSL的优点就要去报ruby的大腿。此外，我的观点也不是去做业务分析，不是去如何更好的实现业务到基础技术结构的映射。

引用

不是强调对象的所谓业务含义，不是强调某种通用语言（例如ruby）的灵活的语法结构。在这之间存在着厚重的具有物理意义的可以进行结构分析的技术层

我想说这个结构层面现在并未得到充分的关注，我们对于结构的问题并不是非常清楚，对程序结构的稳定性更是少有经验。我们在Witrix中做了大量的工作，试图做到如下的图景：

引用

永远只写代码片断，而所有的代码片断组合在一起又构成一个可理解的整体

引用

对背景不是分解让其成为可见的部分，而是采用追加的，增删的方法对背景结构进行修正，则我们有可能在没有完整背景知识的情况下，独立的理解局部变化的结构。即背景是透明的，知识成为局部的。

    
http://canonical.iteye.com/blog/126467
在Witrix中我们实现的代码重用程度和程序整体结构控制能力是超越了目前已知的所有公开技术的。这不是什么哲学，而是我们在残酷的商业竞争中得以生存的资本。

16 楼 Trustno1 2007-12-06  

实际上我理解你说什么,你想表述的挂点其实也是我一贯以来的观点.曾经有一次我和讨论过这个问题。我记得我当时说，我现在觉得并非是我们发明的软件开发技巧不够成熟，对软件技巧背后的原理研究的不够深入。相反我认为是我们现在是对具体需求的研究还很初级，我们对需求的描述完全是表述性的.我相信某种软件技巧特别合适某种需求，并不是一种偶然的巧合。我相信某种特定需求的背后一定是有某种特定的结构，正如每一种软件技巧的背后都与之对应的数学结构。正是这种结构之间的同构，才导致了我们在编程时对软件技巧上的选择.固然在软件技术上寻找银弹是不可能的，但是现在这样见招拆招以纯粹的经验积累来对付千变万化的需求也是徒劳的。因此我觉得对现实中各种不同需求中所反映的结构进行深入的探索才是最重要的。

在基本的问题上，我并不否认你的观点，但是我不能接受你表述问题的方式。实际上我非常反对为了抽象化而随意使用数学工具来描述问题的方法，但是同时我也极端的反对用一种模糊的隐喻去描述问题。无论是采用物理学的隐喻也好,数学的隐喻也好,其实这种隐喻不过是为了方便他人理解。但是这仅仅是一个辅助手段而不是目的,把问题描述清晰便于它人验证才是我们真正的目的，这也是数学的唯一角色-----一种可验证的语言工具.你可以说我感觉这个问题不能用函数式语言处理,到此为止我不介意这么表述。但是我继续问你，这个结构是什么?为什么不能用函数式语言处理?你回答我,因为从物理的角度去看世界不是简单由函数构成的。这个表述就难以令人接受了.这充其量只能说明你自己看待世界的哲学观点。除非我同你有相似的观点,否则我根本无法去验证你到底说的是什么,说的正不正确.

15 楼 dennis_zane 2007-12-06  

说真的，我觉的这个帖子应该精华帖，看两个偶像辩论。看了canonical的《关于函数式语言的只言片语》，我觉的canonical老大并没有去深入学习过函数式语言。

14 楼 Trustno1 2007-12-06  

引用

我并没有说函数式语言的数学基础是泛函分析。说函数式语言的思想来源是泛函分析，是因为在Backus的论文中对函数式语言的一种乐观的情绪甚至扩大到functional algebra can be used to tranform programs and to solve equations whose "unknowns" are programms in much the same way one transform equations in high school algebra。这种信心只能来源于泛函分析和方程论，来自于数学分析学的发展。将函数的函数作为分析对象就构成泛函分析。泛函分析的最核心的思想当然也不等价于它所研究的那些无穷维空间，不等价于种种正交基的构造。它的思想核心在于函数的函数具有独立的分析价值，具有脱离数量空间的具体的结构。

这是我在前面一再指出的问题，函数的函数只是一种形象的通俗类比,这种形象的类比在泛函分析中存在.在递归论论中递归论同样也关心.一个来自数论，一个来自积分论.一个研究自然数域的问题，一个研究实数域的问题.一个关心有限的问题，即函数能否通过本原函数的有限次迭代来得到，也就是函数有限次构造的问题.一个则是研究无限的问题，即分析学在抽象空间上的一般化。

至于你后面写了那么多,其实并没有回答我的问题,无非在反复论述这样一个命题,"XX不是万能的所以YY".这个XX,YY中可以替换成任何东西.你当然能说,相对论不是万能的,这是没错,但是要是接着说因为相对论不是万能的，所以我的理论正确，就有点不合适了吧.

引用

关于现实中的结构问题，我无意去定义什么万能的描述能力。

这里我从来没有要求你定义什么万能的描述能力.我只是要求你按照你自己的描述

引用

现在我要计算两个小球相互碰撞的问题，我可以操起广义相对论，量子力学啥的开始大干一场，也可以用个牛顿力学小试牛刀，甚至可以只用反射关系摆个等式。但是在绝大多数情况下我们都会说这里面的物理是弹性反射而不是相对论。

,把计算机科学中的某个结构哪怕是特例,与语言之间的冲突解释一下就好.那些结构下，基础语言是解决不了的，那些结构下基础语言是可以解决的?为什么?
比如说你下面举了三个例子,那么很简单,我就随便选个例子,为什么消息传递发生数据关联"的超轻量级进程模型"，是通用语言是无法有效承载Domain Specific Structure?原因在哪里?

13 楼 canonical 2007-12-05  

1. 我并没有说函数式语言的数学基础是泛函分析。说函数式语言的思想来源是泛函分析，是因为在Backus的论文中对函数式语言的一种乐观的情绪甚至扩大到functional algebra can be used to tranform programs and to solve equations whose "unknowns" are programms in much the same way one transform equations in high school algebra。这种信心只能来源于泛函分析和方程论，来自于数学分析学的发展。将函数的函数作为分析对象就构成泛函分析。泛函分析的最核心的思想当然也不等价于它所研究的那些无穷维空间，不等价于种种正交基的构造。它的思想核心在于函数的函数具有独立的分析价值，具有脱离数量空间的具体的结构。


2. 我也没有说范畴是基于函数的，“范畴是函数上可以建立的一种结构”，它也可以表现在其他对象上。我的逻辑也不是“因为泛函中大量分析函数式语言中无法体现，所以范畴的得到的规律也极为有限”。关于范畴，它本身只是研究一种基础结构，它本身并没有承载所有的物理事实，基于它不可能对所有的规律一网打尽。不是明白了范畴，就懂了程序。范畴论是一种基础性的语言，有些人致力于基于范畴论来构建数学的其他分支，取代集合论的地位。将计算的本质重新归结于范畴论是无意义的，它不过是对事实的另一种陈述方式。说“函数式语言是基于范畴”是无意义的，因为这和说“所有现代数学都基于集合论”一样。无法发现新的相互作用关系，所有的概念都只是同义反复。不是一拿起数学，就找到了组织。

3. 我对函数式语言并没有什么反对意见。它是非常重要也非常优美的一种技术思想。但是现在一些函数式语言的狂热支持者似乎对函数世界充满了乌托邦式的幻想，一种大一统的世界观让人迷醉，但是它却解决不了现实的问题。所以我说无法认同函数式编程的世界观。作为一种具体的技术工具，问题不在于函数式语言是否体现了计算的本质，而在于它是否向我们提供了称手的兵器。现在我要计算两个小球相互碰撞的问题，我可以操起广义相对论，量子力学啥的开始大干一场，也可以用个牛顿力学小试牛刀，甚至可以只用反射关系摆个等式。但是在绝大多数情况下我们都会说这里面的物理是弹性反射而不是相对论。在理论分析中我们经常使用平面波假设，但只要实际关心的对象不在波包的边缘，没有人会认为平面波不是真实的物理机制。理论物理不是理想物理。在具体的参数设定下，我们只会使用特定的物理学。
   对世界的认识并不是非此即彼的。并不是说函数式语言好它就永远都好，要把所有对立面都灭掉。也不是说函数式不好，命令式就必然的好，就必然的能够解决问题。函数式语言的世界观过分单纯而排他，这是我反对的，我同样无法认同面向对象的本体论论调。就像CISC和RISC架构之争一样，最终我们在现实的物理约束下，运行的最好的芯片是两者思想的结合。这是我们面对物理世界的基本态度。
  
4. 相对论主要是解决了物理规律的协变性的问题，在此过程中它使人们认识到了时空之间奇异的对称性。但是广义相对论的表述中时间也是可逆的。真正定义了时间之箭的是热力学第二定律。根据Landauer's principle: 擦除(erase)1比特信息，耗散到环境中的能量至少是k*T*ln2, 或者说熵增至少是k*ln2. 这意味着只要我们对眼前的黑板不停的写了擦，擦了写，就必然无法回到过去。物理世界是复杂的。

5. 关于现实中的结构问题，我无意去定义什么万能的描述能力。你可以用微分几何，积分几何，广义变分等等手段去证明圆盘是某种意义下的周长最短的东西，但是这一切对你发明轮子并无本质上的助益。不过可以说说现实中的结构。这里不是要证明某种语言中无法描述这些结构，而是说结构是客观存在的，它并不是要在基础语言层面得到充分解决的。实际上现在的通用语言也是无法有效承载Domain Specific Structure的。
A. ErLang大概是目前世界上应用最为深入的函数式语言了。它确实发挥了函数式语言无显式状态变量的优势。但是它对程序构建本质上的帮助更多的来源于无共享的超轻量级进程模型，相当于定制了一般操作系统所提供的基本服务。微软的一个实验性操作系统项目Singularity, 其中也定义了只通过消息传递发生数据关联的超轻量级进程模型，它使用C#的一个扩展语言，额外增加的功能是消息管道上定义的规格状态机，对消息交互的时空模式进行额外的规约。这里对我们真正有价值的是隔离的单元结构。
B. AOP是程序结构空间中的定位和组装技术。在Witrix中我们规范化了切点处的状态空间，并对AOP进行了偏置处理.这种结构调整大大提高了AOP的可用性，使得它成为Witrix中的核心技术手段之一。
C. 面向对象的继承关系从结构观点上看是两个一维集合之间的覆盖关系。在Witrix中扩展了extends所对应的结构操作，创造了新的结构融合手段。
  
6. 抽象数学我还是学过不少的。

12 楼 javavsnet 2007-12-05  

Trustno1 写道

至于你说,语言本身的能力不足以解决现实中的结构问题，这是一个比较有意思的切入点。不过你要讨论这个，那么你就要说明，现实中的结构问题是什么?语言的描述能力又是什么?为什么这种描述能力无法解决某种结构问题?有思想是好事情，但是把思想玄化不是什么好习惯。有问题说问题，一件事情一件事情摆到台面上去分析这是最重要的。物理学中使用数学的目的虽然不是为了追求纯粹的完美性，但是是为了追求沟通的一致性确定性和共同性。有了数学语言，就可以使得一个人的观点可验证,就可以杜绝玄而又玄的形而上学的讨论。

对于这个语言能力与现实不匹配的问题很感兴趣，希望能继续深入的讨论。
另外，一致性确定性有很明显的意义，共同性指的是什么？一致性和共同性有什么区别呢？

11 楼 albertlee 2007-12-05  

太好了~ 谈一谈 monad 和 范畴论的关系吧

10 楼 Trustno1 2007-12-05  

canonical 写道

2. 函数式语言和命令式语言的计算能力相同，但是在具体的情形下它们的描述能力是不同的。我所关心的不是语言层面的问题，因为语言本身的能力并不足以解决现实开发中的所有问题。即现实开发中所需要处理的结构问题并不是在语言层面得到充分解决的，这是我们需要做工作的地方。

canonical 写道

3. 范畴论是从同调代数发展起来的一种非集合论的代数语言，我这里所指的代数结构只是指代数学所研究的一种结构问题。它虽然可以推进我们对于程序基础结构的理解，但是并不足以解决我们所面临的现实问题。此外，一个重要的问题是，一个抽象的概念，当我们物理性的去实现它的话，就必然面临着各种现实的模型之外的约束。如何小心找到合适的实现路径，不触碰可能让模型失效的边界，是我们需要解决的问题。

引用

函数式语言的思想来源是泛函分析，范畴只是函数上可以建立的一种代数结构。泛函中的大量分析结构无法在函数式语言中直接体现。基于范畴论所能推演得到的规律是极为有限的。

首先我在这里指明的是你两个基本的错误，第一你认为函数式语言来自泛函分析，这是一个望文生意的常识性错误，funcional anylisys和functional programming,此functional非彼functional。
虽然这也是我初次接触函数式语言时犯的一大错误。
在我指出函数式语言基于范畴以后，恐怕你因为函数式语言和泛函分析之间的混淆根深蒂固，所以你就开始错误的推演因为函数式语言是基于泛函的，所以范畴是基于函数的.因为泛函中大量分析函数式语言中无法体现，所以范畴的得到的规律也极为有限。这说明你好像并不具备范畴论的一些知识.当然了数学里面山头林立，搞统计的不懂几何是很正常的事情。但是错了就是错了，扯出同调代数遮遮掩掩就来没啥意思了。
至于你说,语言本身的能力不足以解决现实中的结构问题，这是一个比较有意思的切入点。不过你要讨论这个，那么你就要说明，现实中的结构问题是什么?语言的描述能力又是什么?为什么这种描述能力无法解决某种结构问题?有思想是好事情，但是把思想玄化不是什么好习惯。有问题说问题，一件事情一件事情摆到台面上去分析这是最重要的。物理学中使用数学的目的虽然不是为了追求纯粹的完美性，但是是为了追求沟通的一致性确定性和共同性。有了数学语言，就可以使得一个人的观点可验证,就可以杜绝玄而又玄的形而上学的讨论。

引用

如果将状态看作是可以附着在某个对象上的标记，显然状态的存在性便于我们识认概念的唯一性。对象还是那个对象，只是状态标记发生了变化。

我记得,老爱在他那本相对论的意义里，这么说过某件事在空间上的点和时间上的时刻都不具备物理实在，只有事件本身才具有物理实在.状态不是一个单一的量,而是一个与时间复合的量。函数式语言对于状态变更的看法实则就是和闵氏流形中的世界线的时空观念是一致的.