论面向组合子程序设计方法 之 微步毂纹生

Spring的IoC和AOP，也是不需要程序员为“解耦”这一目标编写额外代码的
真的么？
比如我要用到一个print组件，那么我需要注射一个print的实例进去：一自己写一个组装的factory类注射进去，但这种方法需要“编写特殊的代码”，spring的ioc呢 写在xml里面（其实也是通过一个通用的factory），有什么区别？换了个地方java-->xml，换了种写法 标准的java语法--〉spring的特殊的xml的定义.好处呢？
  自己写的“编写特殊的代码”：能提供特别的信息：我需要怎样的print，那一个实例，写错了（编译级别的错误），编译还能发现错误。
  xml方式呢，写错了？过了段时间，应该用哪一种print？自己也忘了，再看代码把。
  其实依赖本身也是一种信息，它代表了现实世界的一种联系。这种联系一定要在一定的地方表达出来，xml 也好java也好，谁来表达？程序员阿，所以“编写特殊的代码”，还是需要的。否则信息丢失，损失就达了

第三节 燃烧的荆棘

http://forum.iteye.com/bloglist.php?userid=6423

有些聪明的小孩能很快搭出一些有意义的东西出来，而一些笨小孩可能摆弄半天仍然是个四不象，难道你的这套东西只适合聪明的小孩？

打断问个问题：
这个和Decorator模式有什么本质的区别

我觉得这个思想很不都，是考虑问题的另一种切入的手段，最终的目的都是为了完成最后的需求，但是切入手段的不同会花费不同的时间。

PS：一般只要能来到这里的应该都是聪明的小孩

呵呵，ajoo终于忍不住了，看到ajoo的发言，我也有些话想说。其实我还是比较欣赏ajoo的，就是不太喜欢他迷恋java的这股劲头。

上次Eliminster说我是不是故意（跟java拥旄）吵架的，吵架我肯定是不敢的，不过有些主观意识，就是希望一些年轻人把注意力从java身上转移开。

ajoo的思想我是十分赞同的，但他用java来表达，实际上削弱想法本身。比如他所谓concept也就是interface，这个理论上可以这么说，但对我们（程序员）而言不就是在表达上的区别么，否则我还可以说这么多语言都没有任何区别。因为方法论和语言本身本就是可以区分开来的。

看实际中的ajoo的例子，对于一个理解不深的人，恐怕很难看出他所谓的co和oo乃至io（或者就叫ajoo：）的区别。

不过，ajoo你不必介意，先做正事要紧，我只是提些建议和意见罢了。

对于一种思想或者标准的理解有时候总是有偏差的，特别是对这种没有定论的思想，所以不能说别人到底懂不懂的问题，只能说是理解的角度和深度不同的问题，看得方面不同，理解的角度不同罢了。

迷恋java是谈不上的。事实上对java我不满意的地方多了。

只不过，相比于java，我更讨厌c++罢了。（我在c++里面也是从崇拜，敬畏，自傲，陶醉，等等阶段过来的，相比于相当一部分的c++扇子，我的c++水平只怕还要强不少呢）
其实，这里从c++过渡过来的java程序员也大有人在呢。gigix我记得当年也是鼓吹gp的c++名人之一吧？

我自然希望java程序员们能够把目光转移到更关阔的天地，比如看看我的jaskell。

我也希望c++程序员能够把目光至少先挪到java上来，一小步的进步也总比没有进步强啊。

这个连载到目前，刚刚露出一点端倪。说实话，质疑反对的声音都在我意料之中。计划中后面的章节也都会提到的。但是说理解，甚至支持的，我倒是有些怀疑，你们真的明白么？我还没说完，你们就明白了？我的表达能力这么强？

虽说我的技术能力是不能跟你比，然则理解能力还是比较有把握的。你在这边讲combinator也不是一次两次了，莫非还不知道你葫芦里卖什么药么。

一个人说明白，比如你或者T1，倒还好说，毕竟你们本身对这个概念就有一定了解。

但是这么多人说理解，赞同，我就有点怀疑了。不大可能是我的表达能力超强（其实，对这个，我有自知之明的，以前多少次悲惨遭遇都是和我表达不清有关系），也许更可能的是，我的地瓜被当作土豆卖了。

说这话其实有点不知好歹，伤人一大片之嫌，先道个歉先。我是希望，说理解的同学们，好意我表示感谢，但是请还是仔细看看，别闹出我当年“歌德巴赫猜想？简单，就是一个加一个等于一对嘛”的错误来。