2007-11-25
面向集合的框架设计
判断和循环是程序中最基本的语句结构。而在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) )是非平凡的, 集合比个体的简单加和要更多, 为此架构中需要保留对集合边界的识别能力, 例如需要允许在数据导入完成之后执行特定的业务规则而不是仅仅针对每一数据行执行业务规则.
在基元结构上应用基础操作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) )是非平凡的, 集合比个体的简单加和要更多, 为此架构中需要保留对集合边界的识别能力, 例如需要允许在数据导入完成之后执行特定的业务规则而不是仅仅针对每一数据行执行业务规则.
评论
hotman_x
2008-03-06
嘿嘿,说句不合时宜的话,一个事物“完美”是因为它已经没有价值,没有改进的必要。费力看到0点以后,发现是一帮观点差不太多的家伙在喷口水。
站在没有观点的立场(或者不表明观点的立场)总是最安全的,永远立于不败之地。
这里有人说“XX语言绝对能有效解决所有其它语言能解决的问题”吗?没有。因为连汇编(如果不考虑微指令的话)也不能这么说。
站在没有观点的立场(或者不表明观点的立场)总是最安全的,永远立于不败之地。
这里有人说“XX语言绝对能有效解决所有其它语言能解决的问题”吗?没有。因为连汇编(如果不考虑微指令的话)也不能这么说。
rubynroll
2007-12-30
耳目一新啊,这样的讨论有时候看起来很爽!口水部分可以掠过,仔细品位实际上每个人想表达的思想都很有深度,只是有时候太挖细节了,导致最重要的信息表达不够那么有效。
Lich_Ray的关于“要先在理论上得到证明...”的说法很有意思,我记得电子科大有个“道系统”嵌入式实时操作系统,可以用数学推演证明(实时性?完备性?),印象深刻。回头看Lich_Ray同学说的话,真希望此系统能够辉煌。不过,我也并不认为没有完备理论证明的系统就没有必要搞,毕竟大部分我们做的东西是没有机会先得到数学证明的,完美的东西固然好,不完美的东西也很有价值。
Lich_Ray的关于“要先在理论上得到证明...”的说法很有意思,我记得电子科大有个“道系统”嵌入式实时操作系统,可以用数学推演证明(实时性?完备性?),印象深刻。回头看Lich_Ray同学说的话,真希望此系统能够辉煌。不过,我也并不认为没有完备理论证明的系统就没有必要搞,毕竟大部分我们做的东西是没有机会先得到数学证明的,完美的东西固然好,不完美的东西也很有价值。
crazyox
2007-12-27
......
感觉自己来自另一个世界, 好功力呀! 先收藏了, 等以后能看懂的时候再说!
感觉自己来自另一个世界, 好功力呀! 先收藏了, 等以后能看懂的时候再说!
SilenceCliff
2007-12-12
T1的陈述更能 使我心悦诚服。或许个人阅读结构和解读视角的问题。
Anyway,本质这种东西,耳熟能详之时,扑朔迷离之始。
Anyway,本质这种东西,耳熟能详之时,扑朔迷离之始。
hampster
2007-12-12
有点发晕,优雅又易懂的设计不好吗?
javavsnet
2007-12-11
good!
canonical
2007-12-11
引用
good!
我的原话不是这一句。谁在后台改了这个帖子?
jelly
2007-12-11
确实看不懂,为什么大家都喜欢说一些别人看不懂的东西呢?
将简单的逻辑非要套上学究的术语,那不是好像孔乙己一样。
我认为将复杂的道理用通俗的语言能够表达出来才是大师的境界,才是我们追求的境界把,不然岂不是曲高和寡,身在高处不胜寒?
canonical
2007-12-10
我所阐述的只是一种视角的转换,它不是说必然给你提供某种超越当下的能力,而是说以一种不同的眼光看待所有的一切。视角变换后,我们发现了一些新的命题,而在原先的视角下在我们的话语体系中原本是无法表达这些命题的。串行程序假设了只有1颗CPU, 而函数式语言假设了可以有无限多个CPU, 你不觉得1至无穷之间缺点什么吗。你感觉不到现在的软件领域有什么不平凡的例子,是吗?这说明你创造的时机来临了。你可以创造一些东西把1至无穷之间的空白补齐,概念空间是连续的。
整个Witrix就是针对视角转换之后一次不平凡的技术尝试,当然限于商业机密,我不可能阐述很多。我所能够表达的都已经写在了我以前的blog中,有兴趣自己去看吧。
整个Witrix就是针对视角转换之后一次不平凡的技术尝试,当然限于商业机密,我不可能阐述很多。我所能够表达的都已经写在了我以前的blog中,有兴趣自己去看吧。
javavsnet
2007-12-10
我想我刚刚明白了canonical同学/前辈的意思。canonical同学是说某种通用语言,对于某个领域问题的描述能力是不够的。在有了两个“某”以后,这句话是无懈可击的真理。但是这句话对于我来说太泛泛了,基本上是没有用的。canonical同学的10个线程的例子忒通俗易懂了,也忒不够深入了,没有讨论的余地。我很想看到更复杂更深入的例子,说明通用语言的结构在描述某些问题的时候是不够了,例如T1说的轻量级线程通讯的例子(也许我没有集中起足够的注意力,没有精确的描述出来),这里T1说的问题只是一个例子,我指的不是这个例子,是类似这个例子的,复杂的,需要深入思考才能得出结论的例子。这个要求可能有点过分,我的本意就是想通过讨论长学问。
canonical同学的另一个观点,结构是独立于语言的,可以抽象出通用的结构来描述领域问题,这个观点实在一些,不过我还是很贪婪的希望能看到更多的例子说明。用你们的增强了的extends算子在描述领域问题的时候究竟有什么直观的好处,这样俺更容易理解。
canonical同学的另一个观点,结构是独立于语言的,可以抽象出通用的结构来描述领域问题,这个观点实在一些,不过我还是很贪婪的希望能看到更多的例子说明。用你们的增强了的extends算子在描述领域问题的时候究竟有什么直观的好处,这样俺更容易理解。
canonical
2007-12-09
引用
创新往往要不师古,但不师古未必就是创新,而是比拼合适的选择并加以利用。
你这话我很同意啊, 关键是和我们的讨论有什么关系. 你不要总是试图在本质上证明我所说的所有的东西本质上都是无意义的.
引用
世界上有3000~5000种编程语言,支持函数式编程的约有1/4。事实上,不可避免使用函数式编程的领域几乎是没有的,即便是对程序效率要求极高的地方,使用编译后的 ML、OCaml、Haskell 一般都可以获得比命令式语言更高的执行效率,开发效率就更不用谈了。
这件事实与我们讨论的问题有关吗? 我说过函数式语言执行效率低吗, 我说过函数式语言的开发效率必然低吗. 可是在所有领域, 函数式语言开发效率都比其他语言高吗? 再说不同的函数式语言之间的开发效率难道就没有高低之分吗? 比如在其他函数式语言你开发类似ErLang解决的那些程序问题试试?
引用
行了,差不多了,不跟你吵了。最后祝愿你的系统在消亡之前得到证明或者是验证
我没和你吵,只是耐心的和你讲道理. 此外我们所讨论的一切和我的系统有什么关系? 所有的系统都会消亡的, 但我只是要解决现在的问题. 你不觉得你的思维方式中只有永远,没有现在吗.
引用
不要因为 Erlang 名气响就把它拖来说事,它还算不上FP中的第一
你这话不还是说函数式语言之间还是有区别的吗.
我的系统的意义需要什么抽象的证明吗? 用户在用我还要证明什么存在的意义? 用户在用不是一种实践吗? 你到底对实践是怎么定义的.
首先我的原帖中并没有宣扬什么解决问题的灵丹妙药。我只是说结构问题是语言中立的, 是需要独立于语言来看待和认识的。 这一观点有什么创新吗,我看不出来。在物理领域, 我们早已接受了如下事实: 物理问题是独立于数学问题存在的, 我们需要建立单独的价值观和思维方式。
为了避免我有人身攻击之嫌,此处我删除一些话语. Licy_Ray现在要求和我改为站内短信交流. 他不回帖不意味着他改变观点
canonical
2007-12-09
我说过哪个脏字,我的帖子在你的帖子之后发的. 你说出来我就改正.
你在那里一个劲的说你不懂xx, 你不行, 我说什么了?
我本来就用javascript构造的部分结构,它们属于框架的一部分.你所理解的框架是什么东西? 一种语言吗? javascript能够解决所有的问题吗? 我后台用的java, 你告诉我,我应该怎么办?
你这个信仰我不同意,怎么了?
再说你一再说我这个人不行,我觉得很奇怪.你对自己没信心,就一定要贬低别人吗.
我从来无意推广我们的系统, 仅是把一些思想拿出来讨论而已. 你自己认为世界上的问题已经解决完了的话,那么回家睡觉好了,干吗回帖呢
我的系统能不能发展下去是一个独立的问题,即使它不存在了, 它在特定的时空具有存在的价值, 这不就是物理意义吗. 难道说1000年后看今天的东西说它们都是虚假的吗
从数学上说,它们是等价的.但是实际使用上,总有人偏好这个,有人偏好那个, 总是某种情况下应用某个语言会方便一些,另一些麻烦一些, 这些不是差异吗. 如果他们是全同的,大家还搞个什么劲呢.
java不是暗器. 只是在现实中,我必须在后台使用java, 在前台使用javascript, 我还必须要解决一系列的结构问题. 你说我应该全用xx语言吗.
我什么时候说过不懂,不通这样的话了? 我说的是有些事实可能不是大家都熟悉. ok, 如果你觉得我说的事实有问题,那么大家可以辩论嘛. 难道有些事情你不知道,你就急了?
你心中有了框架,可还是要编代码. 你还是要把一些结构在特定的程序语言上实现出来. ok, 你说这些东西不算什么,它们都是语言的一部分. 那它们到底是不是语言,还是帮助库, 还是某种其他的东西. 编制出来的东西是否体现了某种程序语言原本没有表达的关系? 你可以说汉语已经包括了所有的诗歌, 你觉得我相信吗
我没有发布什么彻底解决了某某问题的新系统, 只是说处理一种结构问题对我们的工作是有益的. 我说错了吗.
我的java? java是我的吗? 我们选择java是在目前的技术商业环境下所必然要做出的选择. 我只是说在这种现实约束情况下我们仍然要工作而已.
可惜客户未必会让你推荐什么产品. 我们只向客户推荐有用的产品.
ok, 我现在告诉你只允许你用xx语言,上面没有xx思想的直接体现. 咋了, 你罢工吗. 现在就是有一个结构问题要解决, 它是和语言无关的. 语言提供了我就直接用, 语言没有提供了我就写代码构造. 难道除了语言直接体现的结构之外, 程序本身就无法构造任何具有通用价值的结构了吗.
在不同的领域用, 我干吗一定要换框架? 你觉得框架是什么? 是某种帮助类吗. 再说, 框架不是一种思想吗. 我现在说的是结构问题是独立的, 它可以体现在框架中. 如果一个新的领域不适合使用我原先使用的语言, 我根据同样的结构分析思想重新构建此一结构不可以吗.
你在那里一个劲的说你不懂xx, 你不行, 我说什么了?
我本来就用javascript构造的部分结构,它们属于框架的一部分.你所理解的框架是什么东西? 一种语言吗? javascript能够解决所有的问题吗? 我后台用的java, 你告诉我,我应该怎么办?
引用
世界上将在一两个强大的数学模型支持下出现无数的领域特定技术来供我们选择,仅因一时之需而产生的东西将被理性地融合
你这个信仰我不同意,怎么了?
再说你一再说我这个人不行,我觉得很奇怪.你对自己没信心,就一定要贬低别人吗.
我从来无意推广我们的系统, 仅是把一些思想拿出来讨论而已. 你自己认为世界上的问题已经解决完了的话,那么回家睡觉好了,干吗回帖呢
我的系统能不能发展下去是一个独立的问题,即使它不存在了, 它在特定的时空具有存在的价值, 这不就是物理意义吗. 难道说1000年后看今天的东西说它们都是虚假的吗
引用
函数式语言,几乎都是一样的
从数学上说,它们是等价的.但是实际使用上,总有人偏好这个,有人偏好那个, 总是某种情况下应用某个语言会方便一些,另一些麻烦一些, 这些不是差异吗. 如果他们是全同的,大家还搞个什么劲呢.
引用
你框架中使用的 Java 又成了哪门子“独门暗器”了
java不是暗器. 只是在现实中,我必须在后台使用java, 在前台使用javascript, 我还必须要解决一系列的结构问题. 你说我应该全用xx语言吗.
引用
总说别人不懂物理不通数学
我什么时候说过不懂,不通这样的话了? 我说的是有些事实可能不是大家都熟悉. ok, 如果你觉得我说的事实有问题,那么大家可以辩论嘛. 难道有些事情你不知道,你就急了?
引用
你心中就有了框架
你心中有了框架,可还是要编代码. 你还是要把一些结构在特定的程序语言上实现出来. ok, 你说这些东西不算什么,它们都是语言的一部分. 那它们到底是不是语言,还是帮助库, 还是某种其他的东西. 编制出来的东西是否体现了某种程序语言原本没有表达的关系? 你可以说汉语已经包括了所有的诗歌, 你觉得我相信吗
我没有发布什么彻底解决了某某问题的新系统, 只是说处理一种结构问题对我们的工作是有益的. 我说错了吗.
引用
你以为我提及你的 Java 是惧怕吗?未免有些自恋了吧?
我的java? java是我的吗? 我们选择java是在目前的技术商业环境下所必然要做出的选择. 我只是说在这种现实约束情况下我们仍然要工作而已.
引用
我当然不会推荐只用xx语言甚至是只用xx思想,但我肯定不会推荐一个不用xx思想的产品。
可惜客户未必会让你推荐什么产品. 我们只向客户推荐有用的产品.
引用
因为使用了某个框架,只需要500行,但使用某个思想也只需要500行,你选择哪个
ok, 我现在告诉你只允许你用xx语言,上面没有xx思想的直接体现. 咋了, 你罢工吗. 现在就是有一个结构问题要解决, 它是和语言无关的. 语言提供了我就直接用, 语言没有提供了我就写代码构造. 难道除了语言直接体现的结构之外, 程序本身就无法构造任何具有通用价值的结构了吗.
在不同的领域用, 我干吗一定要换框架? 你觉得框架是什么? 是某种帮助类吗. 再说, 框架不是一种思想吗. 我现在说的是结构问题是独立的, 它可以体现在框架中. 如果一个新的领域不适合使用我原先使用的语言, 我根据同样的结构分析思想重新构建此一结构不可以吗.
Lich_Ray
2007-12-09
不需要说你什么时候说过,更不需要掩饰什么,你的系统无非是这一类东西,或者更差。不服气吗?我本来不想说你忽悠客户的,但你自己既然这样说了,那我就不客气了:我可以用 JavaScript 轻松地构造出同样有力的程序而不需要任何所谓“框架”,因为函数式编程对于语言的依赖要求更少。你的框架,作为一个产品,当然是有价值的,但不是所有有价值的东西都有继续存在的价值,这一点我希望你能明白。
再说抽象。真的难以置信一个懂得理论和抽象的价值的人会说出这样一番话。你当然是知道我所说的东西的,但很明显,你仍然站在拜火教的一方为自己并不高明的系统在不停的辩解。我没有对你进行任何人身攻击,第一个脏字是你说出来的,请不要忽视这一点。
我曾经一度怀有非此即彼端幻想,但是,我在学习了近40种编程语言和几十篇经典论文之后放弃了这种幻想,代之以新的幻想:世界上将在一两个强大的数学模型支持下出现无数的领域特定技术来供我们选择,仅因一时之需而产生的东西将被理性地融合。这是我得出的结论。
就拿函数式编程来说,你说“难道所有的函数式语言都是一样的吗?”,正说明了你对函数式编程的不了解。事实上,函数式语言,几乎都是一样的,不同在于这个纯一点那个不够纯,这个用的是应用序求值那个是正则序,这个IO是简易的那个是基于延续的,这都只是“人民内部矛盾”,不是本质性问题。Lambda 演算告诉我们,只要一个语言能够支持闭包就可以进行函数式编程,差异不过是一点语法和程序长短。我写过一篇小文就举了这样一个例子:http://lichray.javaeye.com/blog/101055。众多的函数式语言正在验证我前文提到的猜想。
*** 我在贬低你吗?我当然知道你理解理论和抽象,但你表现得完全像一个不理解的人。你在掩饰些什么呢?是你框架中使用的 Java 又成了哪门子“独门暗器”了?我只不过是提醒你而已。相比之下,倒是你总说别人不懂物理不通数学,而且没有拿出任何东西来证明,现在还不觉得有愧,还在追问别人自己哪儿说了脏字。没关系,那不是脏字,不会被搜索引擎过滤掉的,满意了吧?
*** 我所理解的框架是什么?核心的编程技术罢了。如果你能学习了一种思想之后,做到对很多问题拿到手就能迎刃而解,你心中就有了框架。
*** 我当然不认为计算机的问题都解决完了,计算机发明了不过60年而已。但要解决这些问题,需要的是冷静的头脑和潜心地研究,而不是在那之前动辄就发布新系统!弱水三千,我只取一瓢饮;解决的路有很多,我只选择一两条。
*** 你以为我提及你的 Java 是惧怕吗?未免有些自恋了吧?我当然不会推荐只用xx语言甚至是只用xx思想,但我肯定不会推荐一个不使用xx思想的产品。创新往往要不师古,但不师古未必就是创新,而是比拼合适的选择并加以利用。
*** 编码当然必要的,但我们来看这样一个例子:如果某个项目原本要1000行代码,因为使用了某个框架,只需要500行,但再在不同的领域碰到同样的问题,你又得换框架;但使用某个思想也只需要500行。你选择哪个?心中有正气,不怕鬼敲门。这是我所追寻的。
*** 世界上有3000~5000种编程语言,支持函数式编程的约有1/4。事实上,不可避免使用函数式编程的领域几乎是没有的,即便是对程序效率要求极高的地方,使用编译后的 ML、OCaml、Haskell 一般都可以获得比命令式语言更高的执行效率,开发效率就更不用谈了。
就我个人及遇到的问题而言,的确如此。还有,不要因为 Erlang 名气响就把它拖来说事,它还算不上FP中的第一。
*** 行了,差不多了,不跟你吵了。最后祝愿你的系统不要在被证明没有意义之前就已经消亡了。
再说抽象。真的难以置信一个懂得理论和抽象的价值的人会说出这样一番话。你当然是知道我所说的东西的,但很明显,你仍然站在拜火教的一方为自己并不高明的系统在不停的辩解。我没有对你进行任何人身攻击,第一个脏字是你说出来的,请不要忽视这一点。
我曾经一度怀有非此即彼端幻想,但是,我在学习了近40种编程语言和几十篇经典论文之后放弃了这种幻想,代之以新的幻想:世界上将在一两个强大的数学模型支持下出现无数的领域特定技术来供我们选择,仅因一时之需而产生的东西将被理性地融合。这是我得出的结论。
就拿函数式编程来说,你说“难道所有的函数式语言都是一样的吗?”,正说明了你对函数式编程的不了解。事实上,函数式语言,几乎都是一样的,不同在于这个纯一点那个不够纯,这个用的是应用序求值那个是正则序,这个IO是简易的那个是基于延续的,这都只是“人民内部矛盾”,不是本质性问题。Lambda 演算告诉我们,只要一个语言能够支持闭包就可以进行函数式编程,差异不过是一点语法和程序长短。我写过一篇小文就举了这样一个例子:http://lichray.javaeye.com/blog/101055。众多的函数式语言正在验证我前文提到的猜想。
*** 我在贬低你吗?我当然知道你理解理论和抽象,但你表现得完全像一个不理解的人。你在掩饰些什么呢?是你框架中使用的 Java 又成了哪门子“独门暗器”了?我只不过是提醒你而已。相比之下,倒是你总说别人不懂物理不通数学,而且没有拿出任何东西来证明,现在还不觉得有愧,还在追问别人自己哪儿说了脏字。没关系,那不是脏字,不会被搜索引擎过滤掉的,满意了吧?
*** 我所理解的框架是什么?核心的编程技术罢了。如果你能学习了一种思想之后,做到对很多问题拿到手就能迎刃而解,你心中就有了框架。
*** 我当然不认为计算机的问题都解决完了,计算机发明了不过60年而已。但要解决这些问题,需要的是冷静的头脑和潜心地研究,而不是在那之前动辄就发布新系统!弱水三千,我只取一瓢饮;解决的路有很多,我只选择一两条。
*** 你以为我提及你的 Java 是惧怕吗?未免有些自恋了吧?我当然不会推荐只用xx语言甚至是只用xx思想,但我肯定不会推荐一个不使用xx思想的产品。创新往往要不师古,但不师古未必就是创新,而是比拼合适的选择并加以利用。
*** 编码当然必要的,但我们来看这样一个例子:如果某个项目原本要1000行代码,因为使用了某个框架,只需要500行,但再在不同的领域碰到同样的问题,你又得换框架;但使用某个思想也只需要500行。你选择哪个?心中有正气,不怕鬼敲门。这是我所追寻的。
*** 世界上有3000~5000种编程语言,支持函数式编程的约有1/4。事实上,不可避免使用函数式编程的领域几乎是没有的,即便是对程序效率要求极高的地方,使用编译后的 ML、OCaml、Haskell 一般都可以获得比命令式语言更高的执行效率,开发效率就更不用谈了。
引用
可是在所有领域, 函数式语言开发效率都比其他语言高吗? 再说不同的函数式语言之间的开发效率难道就没有高低之分吗? 比如在其他函数式语言你开发类似ErLang解决的那些程序问题试试?
就我个人及遇到的问题而言,的确如此。还有,不要因为 Erlang 名气响就把它拖来说事,它还算不上FP中的第一。
*** 行了,差不多了,不跟你吵了。最后祝愿你的系统不要在被证明没有意义之前就已经消亡了。
canonical
2007-12-09
我什么时候说过“把对象打包成collections,封装循环细节,循环组件化,自动选择相应类型的迭代器,连结处理过程,不就是你的系统的思路和技术吗”。
如果你不清楚就不要随便议论。此外即使我的论点是重复的,我又不是要解决icon的问题,不是要把这件事情推到语言层面。我可以用现在其他方式都不可能的方式解决我的问题,这不就是价值吗? 你说我挣客户的钱是忽悠客户吗。我在有限资源的情况下挣到了钱,我怎么就失败了呢
退一万步说,ok, 我的实现没有某个伟大的函数式语言优美。但是我的论题是某种结构问题是具有独立价值的,它和语言是无关的,只要解决了这一结构问题就能带给我们价值,而不需要依赖特定的语言的。你回帖从来不看帖吗。
即使是函数式语言,你认为所有的函数式语言都是完全一样的吗。难道你认为它们之间不存在某种结构性差异吗。你觉得那些不停发明新的函数式语言的人大脑都进水了吗。
说我不懂抽象,你的论据从哪来的。我真的无法想象。我基本学过数学系,物理系,计算机系的所有课程,怎么会不知道理论和抽象是什么呢。你除了毫无意义的人身攻击和无哩头的预言之外,还能再说点什么?
非此即彼,天下唯我,难道不是我们思维中经常陷入的一个误区吗
如果你不清楚就不要随便议论。此外即使我的论点是重复的,我又不是要解决icon的问题,不是要把这件事情推到语言层面。我可以用现在其他方式都不可能的方式解决我的问题,这不就是价值吗? 你说我挣客户的钱是忽悠客户吗。我在有限资源的情况下挣到了钱,我怎么就失败了呢
退一万步说,ok, 我的实现没有某个伟大的函数式语言优美。但是我的论题是某种结构问题是具有独立价值的,它和语言是无关的,只要解决了这一结构问题就能带给我们价值,而不需要依赖特定的语言的。你回帖从来不看帖吗。
即使是函数式语言,你认为所有的函数式语言都是完全一样的吗。难道你认为它们之间不存在某种结构性差异吗。你觉得那些不停发明新的函数式语言的人大脑都进水了吗。
说我不懂抽象,你的论据从哪来的。我真的无法想象。我基本学过数学系,物理系,计算机系的所有课程,怎么会不知道理论和抽象是什么呢。你除了毫无意义的人身攻击和无哩头的预言之外,还能再说点什么?
非此即彼,天下唯我,难道不是我们思维中经常陷入的一个误区吗
canonical
2007-12-09
首先不要先质疑我的正常思维能力。做人身攻击只会暴露自己的虚弱。如果你想从辩论中获得一些什么,应该仔细看一看别人论述的整体,而不是抓住只言片语,用自己的理解歪曲后喷发一种不屑。
没有人否认抽象的意义,但是抽象是否就是抽象到无穷大,这是个可以明确定义的问题,也是数学领域正在解决的问题。如果你懂得更多的物理便会明白我的话语,例如学一点摄动分析。
我所说的正是说:你明白了终极的意义,明白了一种推向无穷的抽象并不是理解了世界的全部,我们仍然要明白如何解决一些更加小范围,但是却又普遍发生的事情。
在我们的思考中没有明确定义何处是边界,没有明确的限制,这便是导向无穷的一种思维方式。和现实中是否真的允许创建无穷多的线程无关。 这是理论上的问题,其实是一个抽象的问题。
说到10这个确定的数字,不过是一种极端化的比喻。我常说概念是连续的,并不是非此即彼的,因此并不是从一种普遍情况到一种最特殊的情况之间不再有其他情况了。 在这中间环节,存在着非常深刻的复杂的物理事实。但是这些事实却又是某种有限性向我们揭示出来的。(请不要把这里的有限性理解为算术中的10以内)
没有人说要放弃探索,实际上我一直强调要探索。只是需要调整一下观察的视角,我们便可以发现一些新的东西。其实作为一名探索者,如果我说的话语是反对探索的,反对证明的,那我如何解释自己的行为呢。
你并不了解我的系统,评论什么呢?
这句话的逻辑非常奇怪,在理论证明之前,实践无法证明。。。。 如果你说的是我的系统,我的系统只要为我解决问题,我需要证明什么呢。证明我会节约开发成本,还是客户会多付给我费用。我现在做事情比所有想见的其他方式都要更加迅捷,我还需要证明什么? 如果你说的不是我的系统,那么别人的系统在用理论证明它的强大之前,就能够被足够的现实应用证明它是有效的?
现在来一个理论推演吧:
1. 任何系统都在一定约束下运行,即它们需要符合某些约束条件
2. 通用语言描述了某些结构,但是这些结构是充分通用的,能够应用到尽可能广泛的领域的
3. 线程数=10这个约束过份特殊,显然通用语言是不会考虑这个约束。实际上目前在通用语言设计中,无限资源假定基本都是默认的。
4. 我们承认某些现实的约束通用语言是不会考虑的
5. 在最特殊的,明显不会考虑的约束以及非常通用,一般通用语言必然考虑的约束之间,是否存在着更多的,非平凡的结构呢
6. 假如10年以内我们所有的硬件都只能支持10个内核,在我的产品研发中假定10个线程有问题吗。难道我在开发的时候就不再需要抽象了吗。我在其他方面仍然是需要建立抽象的。
7. n个抽象约束+1个具体约束,以及 n个无限约束+1个有限约束 仍然是有效的抽象形式。原谅我在这里又使用了有效一词,它真的很难理解吗。
我说到函数式语言的时候,基本的态度就是说不要太沉迷于一种特殊的抽象方式,应该多看看别的视角。在不同的情况下存在着做事情的不同的最优方式。 我这句话你有异议吗。
现在计算机领域所谓的理论主要是基于数学视角的,没有考虑物理世界因为我们观察的有限性,因为资源的有限性所造成的种种约束,此外数学中目前也没有考虑到物理世界真实的各种复杂性的存在。在我们想到一种计算机理论的时候,图像过于简单化,这种简单化被认为是优美的全部。其实我们应该思维更加开放一些。
做研究是靠真正的工作,而不是靠一种宗教信仰。
我为什么不能比他们眼界更广,他们所在的时代物理学的发展状况是怎样的。而且这是一种人身判断,有意义吗。
你这话从何说起?你了解我的系统吗? 再说我的系统怎么样和我现在讨论的问题又有什么关系呢退一步说我的系统不
好,我的论题就不存在了吗?这是什么逻辑。
我并没有说我要创造一种新的语言,我只是要解决自己工作中的问题。现在你说神已经确定了两种通用语言:函数式和逻辑式,这和我的论点冲突吗。除了语言,计算机世界便是荒芜的沙漠吗?如果你认为所有的问题都已经研究完了,那么世界上每年那么多研究经费拿来干什么了? 为先贤的理论擦屁股吗?
没有人否认抽象的意义,但是抽象是否就是抽象到无穷大,这是个可以明确定义的问题,也是数学领域正在解决的问题。如果你懂得更多的物理便会明白我的话语,例如学一点摄动分析。
我所说的正是说:你明白了终极的意义,明白了一种推向无穷的抽象并不是理解了世界的全部,我们仍然要明白如何解决一些更加小范围,但是却又普遍发生的事情。
在我们的思考中没有明确定义何处是边界,没有明确的限制,这便是导向无穷的一种思维方式。和现实中是否真的允许创建无穷多的线程无关。 这是理论上的问题,其实是一个抽象的问题。
说到10这个确定的数字,不过是一种极端化的比喻。我常说概念是连续的,并不是非此即彼的,因此并不是从一种普遍情况到一种最特殊的情况之间不再有其他情况了。 在这中间环节,存在着非常深刻的复杂的物理事实。但是这些事实却又是某种有限性向我们揭示出来的。(请不要把这里的有限性理解为算术中的10以内)
没有人说要放弃探索,实际上我一直强调要探索。只是需要调整一下观察的视角,我们便可以发现一些新的东西。其实作为一名探索者,如果我说的话语是反对探索的,反对证明的,那我如何解释自己的行为呢。
你并不了解我的系统,评论什么呢?
引用
你的系统,在你用理论证明它的强大之前,是不可能被足够的现实应用证明它的有效的
这句话的逻辑非常奇怪,在理论证明之前,实践无法证明。。。。 如果你说的是我的系统,我的系统只要为我解决问题,我需要证明什么呢。证明我会节约开发成本,还是客户会多付给我费用。我现在做事情比所有想见的其他方式都要更加迅捷,我还需要证明什么? 如果你说的不是我的系统,那么别人的系统在用理论证明它的强大之前,就能够被足够的现实应用证明它是有效的?
现在来一个理论推演吧:
1. 任何系统都在一定约束下运行,即它们需要符合某些约束条件
2. 通用语言描述了某些结构,但是这些结构是充分通用的,能够应用到尽可能广泛的领域的
3. 线程数=10这个约束过份特殊,显然通用语言是不会考虑这个约束。实际上目前在通用语言设计中,无限资源假定基本都是默认的。
4. 我们承认某些现实的约束通用语言是不会考虑的
5. 在最特殊的,明显不会考虑的约束以及非常通用,一般通用语言必然考虑的约束之间,是否存在着更多的,非平凡的结构呢
6. 假如10年以内我们所有的硬件都只能支持10个内核,在我的产品研发中假定10个线程有问题吗。难道我在开发的时候就不再需要抽象了吗。我在其他方面仍然是需要建立抽象的。
7. n个抽象约束+1个具体约束,以及 n个无限约束+1个有限约束 仍然是有效的抽象形式。原谅我在这里又使用了有效一词,它真的很难理解吗。
我说到函数式语言的时候,基本的态度就是说不要太沉迷于一种特殊的抽象方式,应该多看看别的视角。在不同的情况下存在着做事情的不同的最优方式。 我这句话你有异议吗。
现在计算机领域所谓的理论主要是基于数学视角的,没有考虑物理世界因为我们观察的有限性,因为资源的有限性所造成的种种约束,此外数学中目前也没有考虑到物理世界真实的各种复杂性的存在。在我们想到一种计算机理论的时候,图像过于简单化,这种简单化被认为是优美的全部。其实我们应该思维更加开放一些。
做研究是靠真正的工作,而不是靠一种宗教信仰。
引用
但你才写了几年程序,就自认为比100年来的数学家和计算机科学家眼界更广
我为什么不能比他们眼界更广,他们所在的时代物理学的发展状况是怎样的。而且这是一种人身判断,有意义吗。
引用
你的系统是40~50年前已经被抛弃了的东西,体现的最出色的两个语言是 Apl 和 Icon
你这话从何说起?你了解我的系统吗? 再说我的系统怎么样和我现在讨论的问题又有什么关系呢退一步说我的系统不
好,我的论题就不存在了吗?这是什么逻辑。
我并没有说我要创造一种新的语言,我只是要解决自己工作中的问题。现在你说神已经确定了两种通用语言:函数式和逻辑式,这和我的论点冲突吗。除了语言,计算机世界便是荒芜的沙漠吗?如果你认为所有的问题都已经研究完了,那么世界上每年那么多研究经费拿来干什么了? 为先贤的理论擦屁股吗?
Lich_Ray
2007-12-09
canonical 前辈真的很能扯。其实吧,我觉得他生下来就可以去死了,反正他的“终极意义”也就是去死;他其实也不需要学习什么编程语言,只要发明一种能快速重组几亿个晶体管的技术就可以了;他也不需要学习物理学,因为他看不见物理学的模糊本质在数学中的体现只看见了其在自然中的体现。既然你已经生在自然中了,那还要学什么物理呢?他也不需要学习数学,因为他只是看到了数学对于存在性的弱化表达而不去思考弱化的意义和力量,因此成为了某种形式的拜火教徒,现在正在举大旗反对我们基督教徒。
我沉默了很久,今天被 canonical 前辈唤醒了。愿拜火教的主保佑 canonical 同学在找到他的终极意义之前明白抽象的意义。
*** 你可以不信任任何抽象,但你仍然不能否认现实存在的抽象本质 ***
*** 从开普勒发现行星轨道是椭圆而不是圆的时候起,到现在杨振宁李政道发现宇称不守恒,人类明白过来,宇宙的美与人心的美有交集,但不相同;我们爱哲学、爱自己,但我们更爱宇宙。请别阻止我们的探索,我们不是圈中的羊羔 ***
*** 我们还远远没有抽象到无穷大的能量。人们研究了一千年物理,才写了几十年程序?请别打肿脸充胖子,小孩说大人话 ***
*** 没有人说过函数式语言能在所有的方面超过命令式语言,但我能用现有知识证明一个程序的完备性,难道这不是一种进步吗? ***
*** 没有什么东西能够以其一贯的思路搞定一切,但你不能仅仅因为知道这一点就简单地放弃了探索,退回那个一切搞定你的时代 ***
*** 我认为丘奇等人已经给我们指明了一条道路,如果你也能用那样美好的方式把你自己的道路指给我们,我们也愿意尝试。但问题是你的系统没有让我们看到一点数学的或者物理的坚固和美,有的只是来自50年代计算机科学界的狂飙突进式的想法。也许在现在的几个角落有超过其他系统的价值,但这显然不是一个探索者、研究者所应有的态度。你的系统,在你用理论证明它的强大之前,是不可能被足够的现实应用证明它的有效的。
没有任何逻辑问题,请注意前面“你的系统”四个字。既然你自认为自己的思维没有问题,应该能理解我在说什么。:)
眼界自然应该更广一点。但你才写了几年程序,就自认为比100年来的数学家和计算机科学家眼界更广?他们已经广了50年了,广了50年才选定的函数式编程,逻辑式编程这么两条路,你不认为你现在多少有些不自量力吗?也许我的思想有些在阻碍你创新的意思,也许你比我年长很多,但我还是不得不不客气地指出:真的,你的系统是40~50年前已经被抛弃了的东西,体现的最出色的两个语言是 Apl 和 Icon。节哀顺变吧。
如何说起?把对象打包成collections,封装循环细节,循环组件化,自动选择相应类型的迭代器,连结处理过程,不就是你的系统的思路和技术吗?去看看 Icon 就知道自己想法的落后和幼稚了,如果你仔细研究了函数式编程的思想,估计就会更惭愧了。
为什么要提到你的系统?你的系统就会成为无数个因为缺乏理论支持而失败的系统之一,难道你还没有这个觉悟吗?
无须多言,用不了多久,你就无言有须了,那时候也许你会重新审视一下理论和抽象的意义。
我沉默了很久,今天被 canonical 前辈唤醒了。愿拜火教的主保佑 canonical 同学在找到他的终极意义之前明白抽象的意义。
*** 你可以不信任任何抽象,但你仍然不能否认现实存在的抽象本质 ***
*** 从开普勒发现行星轨道是椭圆而不是圆的时候起,到现在杨振宁李政道发现宇称不守恒,人类明白过来,宇宙的美与人心的美有交集,但不相同;我们爱哲学、爱自己,但我们更爱宇宙。请别阻止我们的探索,我们不是圈中的羊羔 ***
*** 我们还远远没有抽象到无穷大的能量。人们研究了一千年物理,才写了几十年程序?请别打肿脸充胖子,小孩说大人话 ***
*** 没有人说过函数式语言能在所有的方面超过命令式语言,但我能用现有知识证明一个程序的完备性,难道这不是一种进步吗? ***
*** 没有什么东西能够以其一贯的思路搞定一切,但你不能仅仅因为知道这一点就简单地放弃了探索,退回那个一切搞定你的时代 ***
*** 我认为丘奇等人已经给我们指明了一条道路,如果你也能用那样美好的方式把你自己的道路指给我们,我们也愿意尝试。但问题是你的系统没有让我们看到一点数学的或者物理的坚固和美,有的只是来自50年代计算机科学界的狂飙突进式的想法。也许在现在的几个角落有超过其他系统的价值,但这显然不是一个探索者、研究者所应有的态度。你的系统,在你用理论证明它的强大之前,是不可能被足够的现实应用证明它的有效的。
引用
你的系统,在你用理论证明它的强大之前,是不可能被足够的现实应用证明它的有效的。
没有任何逻辑问题,请注意前面“你的系统”四个字。既然你自认为自己的思维没有问题,应该能理解我在说什么。:)
眼界自然应该更广一点。但你才写了几年程序,就自认为比100年来的数学家和计算机科学家眼界更广?他们已经广了50年了,广了50年才选定的函数式编程,逻辑式编程这么两条路,你不认为你现在多少有些不自量力吗?也许我的思想有些在阻碍你创新的意思,也许你比我年长很多,但我还是不得不不客气地指出:真的,你的系统是40~50年前已经被抛弃了的东西,体现的最出色的两个语言是 Apl 和 Icon。节哀顺变吧。
如何说起?把对象打包成collections,封装循环细节,循环组件化,自动选择相应类型的迭代器,连结处理过程,不就是你的系统的思路和技术吗?去看看 Icon 就知道自己想法的落后和幼稚了,如果你仔细研究了函数式编程的思想,估计就会更惭愧了。
为什么要提到你的系统?你的系统就会成为无数个因为缺乏理论支持而失败的系统之一,难道你还没有这个觉悟吗?
无须多言,用不了多久,你就无言有须了,那时候也许你会重新审视一下理论和抽象的意义。
canonical
2007-12-09
T1你和我争执的问题已经远远偏离了我所要表达的意图。不过如果你愿意辩论具体的细节问题,我也奉陪到底。
这里其实定义了一个数学意义上的有效性。但是物理层面上我们说只要一种方法比另一种方法能够更快的解决问题,我们就说第一种方法比第二种方法有效,而无论密码被破解的时候该密码是否已经过了有效期限。
对于你的问题
我已经做了说明
关于ErLang的例子, 我的原意是用来说明结构问题是独立的,它是和具体语言无关的.即基于消息传递发生数据关联的超轻量级进程模型这一结构不是和ErLang语言绑定的. 为此我特意加了一段说明:"这里不是要证明某种语言中无法描述这些结构,而是说结构是客观存在的,它并不是要在基础语言层面得到充分解决的". 即使在语言层面我们并不解决这个结构问题, 它仍然客观存在着,我们仍然可以用其他的技术手段去定义,去解决. 解决了这个结构问题就必然会带给我们价值,而无论我们使用何种实现语言.
ErLang实现了一个结构,这个结构成功了,并不意味着这一结构是ErLang语言排他性的独有的。
我并不是说特定的领域结构无法在某个特定的通用语言中有效实现。我想这里你对我的话语有些误解。
如果我们认为一种通用语言是比较稳定的,则它一般选择只内置一些通用的不带有领域特定含义的概念. 而缺乏领域知识,或者说因为通用语言故意的摒弃领域依赖, 它在处理领域相关的问题的时候并不是有效的.这种有效性不是数学含义上的,而是可以进行物理度量的.
现在ErLang对通信领域具有良好的支持,你可以说它对于通信领域的结构是有效的。但是显然在ErLang中编写界面就不如面向对象语言得心应手。在ErLang中实现界面结构的时候,它对于界面结构的表述就不是那么符合我们直观的,对我们的实现过程来说就不是那么经济的。因此在界面结构的实现上,目前我们可以说ErLang相对于面向对象语言而言就是不那么有效的。也许你会说ErLang做XX发展之后怎见得就更差。但是如果允许引入未来这一具有无限可能性的因子,我们基本上无法针对现实的情况作出判断。例如我们目前并无法证明广义相对论相对于牛顿力学是更加精确的,如果允许在太阳星系中增加越来越多的隐蔽的摄动星体的话。按照库恩的科学革命论,每一个科学时代都具有着自己的科学范式,它总是具有着充分的自我辩护能力。范式的更新意味着格式塔的崩溃。回顾历史,哥白尼刚提出日心说的时候,并不是在计算精度,计算简洁性上真的远胜托勒密的地心说,只是日心说的哲学隐喻撼动了人心。
我说
传统上数学使用的一种逼近范式是:当n趋于无穷大的时候,偏差趋于无穷小。现在物理学对数学的一种常见要求却是:当n限定在有限数量范围的时候(例如10以内),我们如何才能尽量减少偏差。这要求对小样本数学进行深入的研究,它所具有的物理内涵也是不同的。
在物理的视角下,我们所关心的不是世界在终极的意义上能否分解为函数的复合,不是要导向一种宗教式的顶礼膜拜,而是强调要尊重自己所直接感受到的,充分利用我们因为在这个世界上存在而获得的直观意象,发掘自己的直觉,这样我们才能在无限复杂的世界上借助有限的信息做出选择。
引用
比如说懂得密码学的人回答这个问题,它会告诉你通过理论计算用穷举法破解多少长位的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以内),我们如何才能尽量减少偏差。这要求对小样本数学进行深入的研究,它所具有的物理内涵也是不同的。
在物理的视角下,我们所关心的不是世界在终极的意义上能否分解为函数的复合,不是要导向一种宗教式的顶礼膜拜,而是强调要尊重自己所直接感受到的,充分利用我们因为在这个世界上存在而获得的直观意象,发掘自己的直觉,这样我们才能在无限复杂的世界上借助有限的信息做出选择。
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的有效方法是什么,不一定是在语言层面上,用你的原话来说,
引用
也可以通过框架等实现, 或者表现为某种设计模式,某种编程技巧.
.任何方法都可以,唯一的要求就是希望你能去掉某种这个形容词,然后给我们一个切切实实,看的见摸得着可以分析的实例.
最后请问,这两种方法,相比较起来,为什么说前一种方法,要比后一种方法有效?
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作为界面和单实体的交互模型.
函数式语言为我们提供了一种具体的技术工具, 但是在现实的开发中, 为了有效的处理结构问题, 显然我们需要多种视角的组合, 而不是把所有可想见的图景都纯化为函数. 我们对世界的体验是多样化的. 这就是我所谓"世界比函数的集合要复杂"的含义.
首先我所谓“现在的通用语言”,它并不意指“现在至未来所有通用语言之合集”,而是指“目前正在被使用的某一种通用语言”,这种差别便体现了我所强调的不同的价值观和不同的视角。不是一种覆盖一切的全称判断,而是在特定物理约束下的物理实体。
现在无论我们设计什么大型系统,一般总是要优先考虑微内核设计。但是很显然,如果我们的编程控制能力极强(强大到不现实的地步),我们可以把所有的代码实现为一个大的整体。一个整体的好处是勿用质疑的,否则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作为界面和单实体的交互模型.
函数式语言为我们提供了一种具体的技术工具, 但是在现实的开发中, 为了有效的处理结构问题, 显然我们需要多种视角的组合, 而不是把所有可想见的图景都纯化为函数. 我们对世界的体验是多样化的. 这就是我所谓"世界比函数的集合要复杂"的含义.
Trustno1
2007-12-08
恕我这个死脑筋,再跟你较真一下.
一个人总是受限于他的知识范围,因此他也经常在自己的知识范围内篡改曲解别人的意见。首先我从未说过上面的话,我没有说过一个问题是现有的通用语言无法描述的。 我说的是
请等一下,请你这里思维不要跳跃,不要答非所问哦.这一句是javasnet说的.他把能不能描述和能不能有效描述混在一起,那是他的事情.请你直接回答我下面的问题.
我可是在直接应用你的原话哦.
既然有一公升汽油,那么为什么不先拿这一公升坐辆车往前开个几十公里,再往下走呢?是不是因为反正到不了终点所以干脆把汽油扔了?这就好比一个笑话,有人生了一个儿子,说反正他七老八十岁以后都要死的,那么不如现在把它掐死,一样是死.
既然你谈到了所谓的有限的约束条件,只要你能清晰化的表达你的思想,那我也不反对讨论约束条件.
那么我就把上面的问题变化一下,把原因和约束条件放到句子的前面强调一下,然后请你继续回答一下.
我这个人很笨的,也没有念过什么物理学,看不懂那么多的物理学,哲学性的话题.只需要你罗列出个可以验证的1,2,3.然后我照你的1,2,3去验证一下.这恐怕是唯一能让我这样很轻佻的人再也不轻佻的办法.
引用
javasnet 写道
么问题(一个很具体的问题)是现有的通用语言无法描述的
一个人总是受限于他的知识范围,因此他也经常在自己的知识范围内篡改曲解别人的意见。首先我从未说过上面的话,我没有说过一个问题是现有的通用语言无法描述的。 我说的是
请等一下,请你这里思维不要跳跃,不要答非所问哦.这一句是javasnet说的.他把能不能描述和能不能有效描述混在一起,那是他的事情.请你直接回答我下面的问题.
引用
我不需要你去解决任意问题,我的关注点也没有世界那么大,我现在要的只是你对下面这个断言的证据.这个要求不算很过分吧。
引用
为什么消息传递发生数据关联"的超轻量级进程模型",是通用语言是无法有效承载Domain Specific Structure?原因在哪里?
引用
为什么消息传递发生数据关联"的超轻量级进程模型",是通用语言是无法有效承载Domain Specific Structure?原因在哪里?
我可是在直接应用你的原话哦.
引用
现在的通用语言也是无法有效承载Domain Specific Structure的。
引用
比如说我现在有无穷多种方式从北京跑到上海,但是如果限定只允许用1升汽油,那么我们的选择就近乎于0。飞机和汽车的运输能力是相同的吗。物理学的一个基本精神在于一种物理性的约束是始终存在的。而事实上,我们在实际工作中也总是在各种有限的物理条件下工作。
也许有些人认为这种区分是无关紧要的,我们只关心某种终极的东西。但是物理学中有着太多的例证,说明在有限约束下,整个系统呈现出完全不同的性质。
也许有些人认为这种区分是无关紧要的,我们只关心某种终极的东西。但是物理学中有着太多的例证,说明在有限约束下,整个系统呈现出完全不同的性质。
既然有一公升汽油,那么为什么不先拿这一公升坐辆车往前开个几十公里,再往下走呢?是不是因为反正到不了终点所以干脆把汽油扔了?这就好比一个笑话,有人生了一个儿子,说反正他七老八十岁以后都要死的,那么不如现在把它掐死,一样是死.
既然你谈到了所谓的有限的约束条件,只要你能清晰化的表达你的思想,那我也不反对讨论约束条件.
那么我就把上面的问题变化一下,把原因和约束条件放到句子的前面强调一下,然后请你继续回答一下.
引用
是什么原因,什么样的约束条件,导致了现在的通用语言是无法有效承消息传递发生数据关联"的超轻量级进程模型"
我这个人很笨的,也没有念过什么物理学,看不懂那么多的物理学,哲学性的话题.只需要你罗列出个可以验证的1,2,3.然后我照你的1,2,3去验证一下.这恐怕是唯一能让我这样很轻佻的人再也不轻佻的办法.
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 99102 次
- 性别:

- 来自: 北京

- 详细资料
搜索本博客
最近加入圈子
链接
最新评论
-
关于REST
说的太抽象,看完之后好像是理解了,又好像很模糊。
-- by zjq_blog -
[导入]关于jsplet的一些 ...
我有一个疑问:把一个request || response带入到biz里面会不会 ...
-- by deepthink -
C++配置管理
boost里已经有现成的啦!
-- by jimmy_c -
不完全的计算
当我们 oo 的时候,一般都不认为自己在“计算”,当我们计算的时候,根本就想不起 ...
-- by hotman_x -
面向集合的框架设计
嘿嘿,说句不合时宜的话,一个事物“完美”是因为它已经没有价值,没有改进的必要。费 ...
-- by hotman_x






评论排行榜