从 Push-Action 到 Encourage-Response

    在Event-Response机制下，使用不同的角度和态度去看待，就会有不同的编程方式。程序接收事件，然后，对事件进行响应。一个机制就可以这样建立起来，于是开启交互式编程时代。但是，若细推该机制，它只是从技术层面上为人们提供了一个编程平台，而如何使用这样的一种技术又会是另外一个值得探讨的问题。对不同的人和应对不同的任务来说，能有多种不同的方式。就笔者仅有的微量编程经验来说，更多的程序只是将Event-Response机制以Push-Action的方式使用。何为Push-Action？用户产生事件，程序总得考虑对该事件的响应，这如同一个Push，所期望的是程序Action。就算程序有的时候不该或不愿意去Action，程序代码里面也得考虑诸如此类的用户事件，并进行阻止，否则非法输入导致程序崩溃的可能性会大大增加。要不限定用户的行为，要不考虑各种的“非”去包容用户。这样，似乎具备代码测试的能力和深思熟虑的素质就成为了作为程序员的重要基础，也成为了划分高低级程序员的重要分界线。限定用户的行为始终总有一种奇奇怪怪的赶脚，若去包容，细想一下，不管是高手还是初哥，如此包容的编程方式可谓一个字“累”！更让人沮丧的是，就算已经是如此努力之后，由于用户事件输入导致的程序崩溃还是占大多数，就更不用说，这些努力对期望功能的深入和优化半毛钱关系都没有。结果是，包容不了用户，反而被人家抱怨和责骂一顿，可怜的程序猿。

   本来我只想“直走”，可是，在设计这个行为的时候，却要花无限多的时间在研究“哪条弯路”是不能走的。而每次需要改变的时候，又得对那“非”的一面操心。实际上，当我们希望和程序有更加“人性化”的交互的时候，我们就已经不能将其看待为“逆来顺受”死板机器。因为通过来规避某些行为来实现某种目标行为，却仍希望对方能够自由地“如愿以偿”响应“主人”的行为，那各种的不理想肯定是必然和“自找”的。本来只是期望自己“要”的，实现的时候，却发现，我们得要研究那些“不要”的，在我们设计功能的时候，对付那些“不要的”就已经让人筋疲力尽了。

    为什么程序本身不是“活生生”的，如同人一般，能自主演变和发展呢？那我们就在设计的时候，让程序具有自我演变的能力的就可以了吧。如果是这样，那结果应该是怎样呢？程序就具有了自主的权力，不再是人Push而Action，而应该是人Encourage，程序选择是否Response。若程序能自我演变，则程序会对交互的事件拥有鉴别的能力，只认同和响应对自己有效的事件，而不用程序员去定义一大堆的“非”。自我演变，不是在推崇人工智能什么的，而是把程序员看作“上帝”，试图去定义一个“活体物种”，并打算让它“活动”起来，完成我们规定的事情。如同这个程序“活体”，由我们为我们要解决的任务创造，它从启动那一刻就开始自我演变，不管外界如何，外界所能做的只是试图对该“活体”产生一个“激励”，但该激励是否会对“活体”产生影响，这得由“活体”本身的状态决定。多个程序“活体”可以组成一个“生态圈”，它们之间甚至可以相互激励，并对各自产生自身的影响，使得“活体”的状态迁移。只要“上帝”足够聪明，就可以使得“活体”在状态迁移的过程中，为我们服务，完成我们最初期望的任务。Encourage-Response，赋予程序“生命”，不知这样定义程序的“生态圈”是否可以多姿多彩呢？下篇继续探讨其中的想法，当然，如此写出来的代码必然是“奇奇怪怪”的吧。