|
锁定老帖子 主题：论面向组合子程序设计方法 之 微步毂纹生
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-08-09
ajoo，我也不知道该说什么好了，我为前面的有些不顾及你的感受的话表示抱歉。
|
| 返回顶楼 | |
|
发表时间：2005-08-09
ozzzzzz 写道 gigix 写道 ajoo 写道 ozzzzzz 写道 问题在于，我觉得－1、0、1重要，而你觉得0、1重要。如何协调呢？
同时就如你所说，不管多复杂的场景，都可以使用基本的运算组合的combinator来表现。那么该如何确定使用co和oo究竟那个会更加节省呢？ 所以，我说需要一些经验和数学上的基础。基本上，这里，我没有能力论证0比-1重要。只能说，你就暂时相信这个吧。0是最最重要的（你说的-1是什么意思？没太明白） 至于什么时候oo，什么时候co，如果你是超级大牛，自然基本什么时候都能co，但是对一般人，还是经验说了算。我这个方法论并不比oo精确。 -1的意思就是“减法”操作。没记错的话，丘奇貌似是证明了只要有lambda就足够，并且数的基础也只有0和加法操作，并没有减法。 如果作为数其实只要有0，和单位就够了。但是在实际的情况中，没有那么多公理性的东西怎么办？我不是ajoo说的超级大牛，所以很可能会在某些时候迷失，那么有什么好的指导性的建议呢？ 你看看前一页我的回复罢。我觉得，co的好处可能不在于他能提供一组完备的东西，而在于他的每个combinator复用的机会更大。 |
| 返回顶楼 | |
|
发表时间：2005-08-09
Readonly 写道 ajoo, 假设有如下的代码：
foreach(e: entities){
logger.println(Logger.DEBUG, "entity id: " + e.getId());
e.blah();
}
如果循环数目过多，那么改写成这样的代码，对于性能会比较好：
foreach(e: entities){
if(logger.isEnable(Logger.DEBUG)){
logger.println(Logger.DEBUG, "entity id: " + e.getId());
}
e.blah();
}
那么对于你原先的Logger Interface得加上 public boolean isEnable(int level); 那么所有组合出来的各种Logger的实现也得加上这个方法的实现，那么能否show一下，TimestampLogger， SequenceLogger应该怎么改写呢？ 此时就看出lazy得好出来了。如果是haskell或者jaskell，根本就没有这个问题。 isEnabled(Logger.DEBUG)是什么意思？对DEBUG这个级别的消息是否enable? 不过这也太繁琐了吧？ if(logger.isEnable(Logger.DEBUG););{
logger.println(Logger.DEBUG, "entity id: " + e.getId(););;
}
anyway, 对timestamp，应该无所谓吧？ TimestampLogger implements Logger{
private final Logger logger;
...
public boolean isEnabled(int level);{
return logger.isEnabled(level);;
}
public void println(int lvl, String msg);{
if(!isEnabled(lvl););{
return;
}
...
}
}
SequenceLogger稍微麻烦些，而且，感觉这样对效率并没有太大好处了。 TimestampLogger implements Logger{
private final Logger[] loggers;
...
private boolean any_one_of_the_loggers_is_enabled(int lvl);{
foreach(l: loggers);{
if(l.isEnabled(lvl);); return true;
}
return false;
}
public boolean isEnabled(int level);{
return any_one_of_the_loggers_is_enabled(level);;
}
public void println(int lvl, String msg);{
foreach(l: loggers);{
l.println(lvl, msg);;
}
...
}
}
|
| 返回顶楼 | |
|
发表时间：2005-08-09
ozzzzzz 写道 gigix 写道 ajoo 写道 ozzzzzz 写道 问题在于，我觉得－1、0、1重要，而你觉得0、1重要。如何协调呢？
同时就如你所说，不管多复杂的场景，都可以使用基本的运算组合的combinator来表现。那么该如何确定使用co和oo究竟那个会更加节省呢？ 所以，我说需要一些经验和数学上的基础。基本上，这里，我没有能力论证0比-1重要。只能说，你就暂时相信这个吧。0是最最重要的（你说的-1是什么意思？没太明白） 至于什么时候oo，什么时候co，如果你是超级大牛，自然基本什么时候都能co，但是对一般人，还是经验说了算。我这个方法论并不比oo精确。 -1的意思就是“减法”操作。没记错的话，丘奇貌似是证明了只要有lambda就足够，并且数的基础也只有0和加法操作，并没有减法。 如果作为数其实只要有0，和单位就够了。但是在实际的情况中，没有那么多公理性的东西怎么办？我不是ajoo说的超级大牛，所以很可能会在某些时候迷失，那么有什么好的指导性的建议呢？ 只有积攒些经验了。而且，就算你弄得不完备，连0都找不出来，但是至少写几个decorator还是可以的了。decorator没那么系统，不需要完备性，比较ad-hoc。所以，摸着石头过河，找到了0，可以构建比较完备的组合体系自然好，找不到，弄几个decorator也不损害什么。 |
| 返回顶楼 | |
|
发表时间：2005-08-09
看到gigix 写的例子，不知道是不是我胡思乱想啊 ，倒觉得gigix 和ajoo受函数式编程的影响很大，函数式编程就类似这种组合子的概念。
而且不但这种方法，函数式对复杂问题的演绎过程不知不觉也被应用到我们分析复杂应用系统上面来。 |
| 返回顶楼 | |
|
发表时间：2005-08-09
firebody 写道 看到gigix 写的例子，不知道是不是我胡思乱想啊 ，倒觉得gigix 和ajoo受函数式编程的影响很大，函数式编程就类似这种组合子的概念。
而且不但这种方法，函数式对复杂问题的演绎过程不知不觉也被应用到我们分析复杂应用系统上面来。 exactly 那东西就是从SICP上抄下来的。真实项目里一试，还挺好用。 |
| 返回顶楼 | |
|
发表时间：2005-08-09
firebody 写道 看到gigix 写的例子，不知道是不是我胡思乱想啊 ，倒觉得gigix 和ajoo受函数式编程的影响很大，函数式编程就类似这种组合子的概念。
而且不但这种方法，函数式对复杂问题的演绎过程不知不觉也被应用到我们分析复杂应用系统上面来。 老大，第一篇，创世纪里，我就老大字摆在那里：这是函数式编程里面的重要思想。 合着你一直以为这是我的发明？ 服了你了！ 
|
| 返回顶楼 | |
|
发表时间：2005-08-09
gigix 写道 ozzzzzz 写道 gigix 写道 ajoo 写道 ozzzzzz 写道 问题在于，我觉得－1、0、1重要，而你觉得0、1重要。如何协调呢？
同时就如你所说，不管多复杂的场景，都可以使用基本的运算组合的combinator来表现。那么该如何确定使用co和oo究竟那个会更加节省呢？ 所以，我说需要一些经验和数学上的基础。基本上，这里，我没有能力论证0比-1重要。只能说，你就暂时相信这个吧。0是最最重要的（你说的-1是什么意思？没太明白） 至于什么时候oo，什么时候co，如果你是超级大牛，自然基本什么时候都能co，但是对一般人，还是经验说了算。我这个方法论并不比oo精确。 -1的意思就是“减法”操作。没记错的话，丘奇貌似是证明了只要有lambda就足够，并且数的基础也只有0和加法操作，并没有减法。 如果作为数其实只要有0，和单位就够了。但是在实际的情况中，没有那么多公理性的东西怎么办？我不是ajoo说的超级大牛，所以很可能会在某些时候迷失，那么有什么好的指导性的建议呢？ 你看看前一页我的回复罢。我觉得，co的好处可能不在于他能提供一组完备的东西，而在于他的每个combinator复用的机会更大。 gigix这个小子看来理解力还是有问题。 co要获得成功的关键在于可以找到一套操作combinator的类似gof的东西，而不会在乎于具体combinator复用的多少。也就是说co需要的是一套从寻找最初的combinator，到进行combinator组合的原则，判断combinator是不是需要重构，判断是不是combinator是不是该被分解，判断combinator是不是该被组合为一个更基本的combinator。 其实就好像C/H/O组成的基本的生态结构，但是如果没有什么原则，那么这些生态结构就是不稳定的无规则体。ajoo现在不能满足我的是在这里，而不是他介绍的那些东西。 |
| 返回顶楼 | |
|
发表时间：2005-08-09
可是oz，oo的gof的模式，也是主观的很啊。对同一个问题，有人觉得应该visitor，有人觉得应该factory，一样没有一个可以依赖的精确的准则呀。
gof确实给出了一些场景，总结了很多东西，这也是他们能够出书，而我们只能随便经验性的谈论的区别。 对co，我觉得也是有一些模糊的规律可循的。可惜，这种作总结的工作我不擅长。也许象martin fowler这样的人才合适。 不过，我倒是觉得，oo里面提出的那些原则：正交，单一职责，重构，都是可以原封不动地挪到co里面的。程序开发是有些共性存在的，这并不是oo的专利。 |
| 返回顶楼 | |
|
发表时间：2005-08-09
TiGEr.zZ 写道 ajoo，我也不知道该说什么好了，我为前面的有些不顾及你的感受的话表示抱歉。
话说开了就好。那么你现在能具体地提出你的批评了么？ |
| 返回顶楼 | |
