|
锁定老帖子 主题：论面向组合子程序设计方法 之 微步毂纹生
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-08-10
ajoo 写道 效率问题确实一语种地。 java中如果应用co，必然是几层十几层的多态函数调用。所以应用在效率敏感的场合是不合适的。 我用co开发的jparsec parser combinator库，效率就上不去。 不过我怀疑logging这种东西这几层的函数调用开销有多么要紧。 要真考虑效率，还就得象我们可爱的c++拥趸说的一样，改用c++，用gp,魔板。不过生产力就更低下了。trade-off。 好在我这个logger只是给我的build tool自己用的。你说的这些问题在我这里都没有。而你不认可的灵活性需求在我这里却是实实在在的。 log4j是想用在生产环境中，所以才会对效率不厌其烦的表述。我还没有看到另外一个有名的开源项目在宣传自己是多么多么的高效迅捷。而且，确实有很多人，比如像我，对在生产环境中仍然使用一定级别的日志有迫切需要。 通过深入了解这个玩意儿，我发现对于企业级项目的支持，python相比java是差多了。log4j的架构怎么样我们不去讨论。但光就那么多的appender(日志输出通道)，就让我惊艳不已。 |
| 返回顶楼 | |
|
发表时间：2005-08-10
charon 写道 当然，扩展只是在遵循它的那个logger,layout,appender,filter构架的前提下的，但是，本身这个架构对付logging这件事情，已经足够了。 到现在为止，对我的需求你都是挤牙膏似的问两句答一句。迄今我也没看见一个完整的例子。 好在，这并不是重点，log4j是否完成了某项功能对我的论点影响不大。 charon 写道 引用 我是说我的build tool决定了这个需求对我的项目是实际的，并不是空想。我不认同你的“一个功能log4j没有支持，证明它不实际”的论断。所以你这个回答不搭嘎。 一个工具包不可能去做所有的事情，如果能够做到对常见的场景通过简单的方式就可以搞定，对于不常见的提供一些稍为负载一点的东西或者通过扩展来搞定，那就是很棒的了。 对于你的那个需求，做到只是举手之劳，关键在于为什么没去做。好歹log4j发展了将近十年，有一个庞大的用户群体，基本可以认为这个社区对于所谓的需求有一个深刻的认识。 而且，对于一个特殊的东西，如果需要扩展，CO并不能比其他的方式要更好一些，大家都是写代码。如果能够不写代码光写配置搞定，那可能就牛牛了。 我的哪个需求？我那可是十几个需求呢。你到轻巧，一句举手之劳就完了。 charon 写道 引用 数文件个数有意义么？还是数代码行数好些。你可以数数组合子方法里面和这个讨论相关的代码行数，我估计不超过200行。 log4j核心的几个类还是非常干净的。同等功能即便用CO的方式实现，我估计代码行不会少。这几个核心的类，其质量在开源项目中算是很不错的了。 我觉得那种需求较为明确，能够通过精巧的设计来获得针对某个领域的架构的那种场景，CO并没有什么明显的优势。 我觉得需求越灵活，越模糊，co的用武之地就越大。反之如果需求很死，那么oo就更合适。或者，象很多系统一样，需求并不死，但是它就是吭哧吭哧地硬做，也做的出来，只不过不象co很多需求的解决方案可以自然而然地演化出来。 其实，不知道你感觉到没有。co很象是设计一门语言中的语言，有顺序，有分支，有异常。基本上编程语言有的东西它都有了。只不过一个编程语言有编译器来专门处理，而co的组合子则是借助宿主语言本身的能力。 而人们为什么设计general purpose的语言？不就是为了表达多变不确定的各种需求吗？James Gosling在设计java的时候，不可能预见到我们这些程序员会用这个语言具体做某一件事情。但是，他不必要知道。只要这个语言提供了基本的设施（顺序，分支，函数定义，类，接口定义，异常处理），就够了。 co的意义，我觉得也在这里。 charon 写道 引用 我已经演示了用co可以怎样“轻松”地做一个logging系统的核心，你觉得自己做一个log4j的核心也会有这种举重若轻的感觉么？ 其实在看你这个东西的时候，我一直有一个担心，随着要解决东西的增加，组合的复杂度马上就会显现出来。因为我现在还没有看到降解复杂度的方法，也许你已经有想法了？ 我不知道你怎么会有这种想法。如果真是要解决的东西增加，oo的复杂度只怕会上升得更快，至少对这个logging得例子我相信是这样。 charon 写道 引用 你说的“分级表述”，什么意思？能不能具体点？ 我是觉得，可调试性是个更大的问题。效率也比较讨厌。 其实CO的做法抽象上去和构建一个公理系统差不多，只不过用了一种渐进的方式。好比有一大堆各类零件和一些装配规则，要装配出脑子里面想象的东西，比较简单的时候还好办，稍微复杂一些的东西就会有问题。公理系统中的证明通常都比较难，组合的装配也不会太简单。采用OO的方式，存在类的静态结构，在理解上相对好一些，而采用CO的方式，除了原子以外，其他的都是动态构造的(如果也弄一些静态块，就有点失去意义)，对于理解力绝对是一个考验。所以，肯定需要一个类似的方式来解决。而且，这里面有些东西是浮现出来的(emergence), 打个比方，我们用简单细粒度的几种构造快搭出一个积木人来，此时，各个构造快之间的接口是可以简单定义的。但是，把腿部和躯干连接起来的驳口，在事先是无法考虑到的。本身要对接的两个立面各自都由若干组合子构成，其实是组合子构成的构造的一个对接。 我对你说得这个组合子对接很感兴趣。能不能具体点？对了，如果你看看haskell，所谓combinator最大的好处就是组合子和组合子之间的组合。在fp里面的combinator的一个大强项怎么到这里变成弱点了？ charon 写道 还有一个问题，是在渐进的过程中怎么确保正交性，很可能会出现同一件事情可以有多个方式来解决的情形，此时这个正交性很可能已经被破坏掉了，组合子和组合规则(其实也是组合子了)都会存在这个问题。不过，这个对于受过严格训练的人来说，并不是太大的挑战，但对于我这样的，很可能就跑飞了。前面有位哥们希望通过生产新的组合子来搞定可能出现的效率问题，我怎么看都像是要积极主动地破坏正交性。 正交性是手段，不是目的。适当有些重叠不见得有什么大不了的。我前面回答swing的那个action的例子，map这个组合子本来可以用bind来推演，但是直接实现也无不可。做一件事有多种方法是很自然的，有什么必要避免？ |
| 返回顶楼 | |
|
发表时间：2005-08-10
引用 到现在为止，对我的需求你都是挤牙膏似的问两句答一句。迄今我也没看见一个完整的例子。 好在，这并不是重点，log4j是否完成了某项功能对我的论点影响不大。 hehe,这个并不需要用完整的例子才能说明问题吧。前面1-10的那几项需求，其实就是非常基本的东西，看log4j文档就可以确定的，不必要我写个配置文件出来才算是真的存在。 后面的11-14，其实就是exception的分开输出，前面给的那个配置文件和那个子类是完全可以运转的，我可是在自己的机器上试过的。 你总不会认为有些功能分别在的时候有，但是整合起来就没有了巴。log4j要是这样，早就关门了 不过，问题的关键确实不在这里。 |
| 返回顶楼 | |
|
发表时间：2005-08-10
ajoo 写道 正交性是手段，不是目的。适当有些重叠不见得有什么大不了的。我前面回答swing的那个action的例子，map这个组合子本来可以用bind来推演，但是直接实现也无不可。做一件事有多种方法是很自然的，有什么必要避免？
这是一个坎，不允许重复，那么很容易把握。但是，稍微有一点重复，这个度就很难说了。不同的人会有不同的做法，最后导致从正交的观点出发，设计出一个缠绕的东西来。 perl自豪的地方是同一件事情可以有很多种方法，但是这也是被很多人所诟病的。 |
| 返回顶楼 | |
|
发表时间：2005-08-10
论面向组合子程序设计方法 之 oracle
http://forum.iteye.com/bloglist.php?userid=6423 |
| 返回顶楼 | |
|
发表时间：2005-08-10
charon 写道 ajoo 写道 正交性是手段，不是目的。适当有些重叠不见得有什么大不了的。我前面回答swing的那个action的例子，map这个组合子本来可以用bind来推演，但是直接实现也无不可。做一件事有多种方法是很自然的，有什么必要避免？
这是一个坎，不允许重复，那么很容易把握。但是，稍微有一点重复，这个度就很难说了。不同的人会有不同的做法，最后导致从正交的观点出发，设计出一个缠绕的东西来。 perl自豪的地方是同一件事情可以有很多种方法，但是这也是被很多人所诟病的。 有一件事只有一种方法的语言么？比如说？ |
| 返回顶楼 | |
|
发表时间：2005-08-10
引用 你总不会认为有些功能分别在的时候有，但是整合起来就没有了巴
这话难说。组合子的强大就在于可以把单独的一些功能组合起来完成复杂功能。 而不用组合子也能做到这点可不是不值一提的小事。 需求中的那些if-else能不能实现，还真不是这些功能分别都支持就能证明用这些if-else整合起来之后仍然支持的。 |
| 返回顶楼 | |
|
发表时间：2005-08-10
引用 我不知道你怎么会有这种想法。如果真是要解决的东西增加，oo的复杂度只怕会上升得更快，至少对这个logging得例子我相信是这样。 OO的解法中，因为静态层次结构的存在，复杂度在一定程度上是被分治的。至少在现在我还没有从你的表述中看到类似的机制。 引用 我对你说得这个组合子对接很感兴趣。能不能具体点？对了，如果你看看haskell，所谓combinator最大的好处就是组合子和组合子之间的组合。在fp里面的combinator的一个大强项怎么到这里变成弱点了？ fp出现很多年了，现在也一直没有成为应用上的主流（可能连支流也还算不上），我想里面肯定有内在的原因的。我不否认fp在某些方面的强大，但是更像知道它的应用范围，或者说它的边界在哪里，哪些事情做不了。 简单组合子和规则组成的系统，解空间的实用意义不大。复杂的系统，会有预知之外的情况出现。这个很难表述，一个线索是元胞自动机；另一个线索是可能比较实际一点，比如，就拿造房子来说，组合子可能就是砖头木块胶合物之类的，但是怎么保障用这些小粒度组合子构造出来的房门框架，能够和另外一些组合子组合而成的门能够大小匹配，钮合顺当？因为OO可以定义静态中间结构，可以自顶向下，这些都不是问题。但对于CO而言，似乎只有试错一途？ |
| 返回顶楼 | |
|
发表时间：2005-08-10
ajoo 写道 charon 写道 ajoo 写道 正交性是手段，不是目的。适当有些重叠不见得有什么大不了的。我前面回答swing的那个action的例子，map这个组合子本来可以用bind来推演，但是直接实现也无不可。做一件事有多种方法是很自然的，有什么必要避免？
这是一个坎，不允许重复，那么很容易把握。但是，稍微有一点重复，这个度就很难说了。不同的人会有不同的做法，最后导致从正交的观点出发，设计出一个缠绕的东西来。 perl自豪的地方是同一件事情可以有很多种方法，但是这也是被很多人所诟病的。 有一件事只有一种方法的语言么？比如说？ 现实应用的语言，应该说没有，但是有些语言，比如python，有些接近这个目标了。 这里的关键是CO“声称”从正交出发，但是却混同了非正交的做法，hehe.，在说法上就需要变一变了。 |
| 返回顶楼 | |
|
发表时间：2005-08-10
ajoo 写道 引用 你总不会认为有些功能分别在的时候有，但是整合起来就没有了巴
这话难说。组合子的强大就在于可以把单独的一些功能组合起来完成复杂功能。 而不用组合子也能做到这点可不是不值一提的小事。 需求中的那些if-else能不能实现，还真不是这些功能分别都支持就能证明用这些if-else整合起来之后仍然支持的。 如果是这样，那我相信同样的场景即便用上了组合子，仍然不能保证整合起来之后仍然能够支持。毕竟你这里提到的组合子也没有魔咒在，而且，如果用较为随意的方式来设计组合子，很可能本来对于组合系统而言的一些特性已经不成立了。 |
| 返回顶楼 | |
