canonical

       负数没有直接的几何意义，因此它被认为是对应于不存在的事物。而按照古希腊的逻辑，不存在的事物是不可能存在的，因而也就是无法被理解的，更不可能参与到 推理过程中，因此是无意义的，无法被定义的， 因此它是不存在的。中国人注重的是运算的合理性，而不是数的真理性，大概在公元前400年左右就创造了负数和零的概念。而在西方直到公元7世纪（唐代）的 一本印度人的著作中才出现负数，它被用来表示负债。西方人没有能够创造负数，他们对负数的接受更迟至15世纪左右。这件事实在一定程度上说明了存在某种深 刻的困难阻碍我们理解负数概念。
       在引入负数之前，3x^2 + 8 = 4x 和  3x^2 + 4x + 8 = 0 这两个方程的结构是完全不同的，它们需要不同的求解技术，因此也就不可能利用符号抽象出 a x^2 + b x + c = 0。引入负数才使得我们能够以统一的方式提出问题，并研究通用的求解技术。
      群论(Group Theory)是对结构进行抽象研究的数学分支。群的定义包括四条规则
1.    元素之间的运算满足结合律 (a * b) * c = a * (b * c)
2.    元素之间的运算封闭，即 a * b 仍然属于该群
3.    存在单位元，即对所有a, a * e = e*a = a
4.    每个元素存在对应的逆元，a * a^-1= e
      逆运算是非常重要的结构要求，逆元是对负数的一种抽象推广。如果没有逆元，则只能构成半群(semi-group)，它的性质要少很多。

      目前软件设计中所有的原则都指向组装过程，从无到有，层层累进。构件组装的隐喻中所包含的图像是操纵实际可见的积木，是缺少逆元概念的。

      考察一个简单的例子，假设需要的产品是三角形内部挖去一个五边形的剩余部分。有三种生产策略：
1.    对最终需要的产品形态进行三角剖分，使用8个小三角形拼接出来。这种方式比较繁琐，而且最后粘接工序的可靠性和精确性值得怀疑。
2.    拿到一个真实的三角形，然后用刀在内部挖出一个五边形的洞。这种方式需要消耗一定的人工，而且也很难保证五边形的精确性，即使我们曾经精确的生产过其他五角形和三角形。实际上一般情况下我们是逐步锉出一个五边形的，并没有充分利用到五边形的对称性。
3.    在概念空间中做一个抽象计算  (-五边形) + (三角形) = 所需产品
如果我们能够生产一种负的五边形和一种正的三角形，则可以立刻得到最终的产品。

 
在软件开发的实践中，我们目前多数采用的是两种方式：
1.    采用可视化设计工具通过拖拽操作开发出完整的界面和后台
2.    拷贝一些已有的代码，删除掉不需要的部分，增加一些新的实现，也可能对已有实现做一些不兼容的修正。

在第二种方式中
           新结构的构造 = 已有结构 + 软件之外的由人执行的一个剪裁过程
这个剪裁过程表现为一个时间序列。如果我们对原有结构进行了调整，则需要重新关联一个时间序列，而此时间序列并不会自动重播。为了压缩以时间为度量单位的 生产成本，我们必须减少对时间序列的依赖。在时间序列中展开的一个构造过程可以被转化为一个高维设计空间中的一种更加丰富的构造原理，我们最终的观测可以 看作是设计空间向物理空间的一个投影（想象一束光打下来）。这种方式更容易保证程序的正确性。
          时间序列 --[原理转化]--> 空间关系

    这样我们就可以使用第三种生产策略：利用构造原理进行抽象计算。如果我们只盯着产品的最终形态看，只是想着怎么把它像搭积木一样搭建出来，就不可能识别出 系统结构本身所蕴含的对称性。如果我们发现了系统内蕴的结构特征，但是却只能通过构造过程中的行动序列来追随它，同样无法实现有效的工作复用。同时因为这 个行动序列一般处于系统规则约束之外，完全由人的自觉来保障，因此很难保证它的正确性。现实世界的规范要求并不是模型本身所必须满足的，只要我们能够创造 新的结构原理，在概念空间中我们就可以拥有更多的自由。现在业内鼓吹的软件构造原理多半是参照物理世界中生产具体物质产品的生产工序，却没有真正把握信息的抽象本质。掌握规则，制订规则，才是信息空间中的游戏规则。

    物理学中最重要的分析学思想之一是微扰论(Perturbation). 针对一个复杂的物理现象，首先建立一个全局的规范的模型，然后考虑各种微扰条件对原有模型的影响。在小扰动情况下，模型的变化部分往往可以被线性化，被局 域化，因而问题得到简化。微扰分析得到的解依赖于全局模型的解而存在，因而这是一种主从关系的分解方式。但是如果主体模型是我们已经熟知的物理现象，则我 们关注的重点可以全部放在扰动解上，认为所有特定的物理规律都体现在扰动解中。如果微扰分析得到的物理元素足够丰富，则微扰模型本身可以成为独立的研究对 象，在其中我们同样可以发现某种普适的结构规律。
    考察如下的构造过程
       X = a + b + c
       Y = a + b + d = (a + b + c) - c + d = X - c + d
    对于数学而言，上述的推导是等价的，但是对于物理学而言，Y = a + b + d 和  Y = X - c + d是有着本质不同的。第一种方式要求打破原先X的构造，而重新的组装其实是有成本的，特别是在X本身非常复杂的情况下。典型的，如果X是经过测试的功能， 重新组装后原先由测试保障的概念边界被打破。
         我们可以从Y = X + dX抽象出扰动模型  dX = - c + d
主从分解模式自然的导出逆元概念。

      如果没有逆元，我们必然需要分解。但是如果发掘了背景这一概念，在逆元运算下，对背景不是分解让其成为可见的部分，而是采用追加的，增删的方法对背景结构 进行修正，则我们有可能在没有完整背景知识的情况下，独立的理解局部变化的结构。即背景是透明的，知识成为局部的。在Witrix平台中，BizFlow + DaoWebAction + StdPage 才构成完整的程序模型，BizFlow其实是对标准模型的差异描述，但是它可以被单独的理解。如果我们从接触程序开始就接受BizFlow, 就可能完全不需要了解数据库访问和前台界面渲染的知识。我们并不是通过在DaoWebAction中设定各种可预见的调用形式，而是在BizFlow中通 过类似AOP的操作方式直接对标准模型进行修正。这种修正中一个很重要的部分就是删除标准模型中缺省提供的功能。
     WebMVC之前世今生 http://canonical.javaeye.com/blog/163196
     Witrix架构分析 http://canonical.javaeye.com/blog/126467


      变化的部分构成独立于原始模型的新的模型，它的结构关系是完备的，可以独立的理解。在原始模型崩溃的情况下，它仍然可能保持有效性。
      从物理学的角度看，我们所观测到的一切物理现象，都是某种物理作用的结果，也就是物质结构相对于背景状况的一种偏离。我们只可能观测到变化的部分，因此我们对世界的认识其实只是世界的扰动模型而已，世界的本体不属于科学研究的范畴。

    软件技术的发展是一个结构化不断加深的过程，我们逐渐拥有了越来越丰富的结构识别, 表达和处理手段。在这一方向上, 组件技术最终取得了巨大的商业成功。但是区分同时也就意味着隔阂。面向对象技术最基础的概念在于 O = C(O), 对象的复合(Composition)仍然是对象.  然而在越来越复杂的软件生态环境中,这一图景实现的可能性被大大的压缩. 面对层层封装造成的形态各异的表达方式, 不同来源, 不同目标, 不同运行环境下的信息的交互变得越来越困难。我们逐渐丧失了概念上的简洁性, 也丧失了数学世界中的那种穿透一切的统一的力量. 所谓SOA（Serivce Oriented Architecture)技术试图通过补充更多的环境信息，放弃状态关联，暴露元知识等方式来突破现有的困境。 http://canonical.javaeye.com/blog/33803 这其中一项关键的技术抉择是基于文本格式进行信息表达。

      在过去10年中Web技术取得了空前的成功，它造就了互联网这一世界上最大的分布式集成应用。SOA从某种程度上说是对这一事实在技术层面上的反思。基于 文本传递的web技术所表现出来的开放性，可理解性和可观测性，与封闭的，难以直接解读的，必须拥有大量相关知识才能正确操作的二进制结构相比，这本身就 是革命性的创新。不需要特殊的工具就可以非常轻易的察看到网页程序的输入输出，所有交互过程都处在完全透明的检查下，各种不曾事先规划的文本处理手段都可 以参与到web创建的过程中。随着速度，存储不再是我们考虑的首要问题，文本化作为一种技术趋势逐渐变得明确起来。但是任何一种技术思想的成功或失败都不 可能是因为某种单一的原因所造成的，因此有必要对文本化的技术价值做更加细致的剖析。
  
   1. 文本化是一定程度上的去结构化，但是通过这种方式我们获得了对程序结构的更强的控制力。无论我们所关心的文本片断层层嵌套在大段文本的哪个部分，我们都可 以通过text.indexOf(subStr)来实现定位，通过text.replace(oldStr,newStr)实现变换。而在组件系统中，我 们只有通过某种预定的遍历方式逐步递归才有可能访问到组件内部的组成对象。如果某个组件不按照规范实现或者规范中缺少明确的设定，则这一信息关联链条将会 断裂。在一些组件系统中，甚至没有规定一种统一的遍历方式，则我们根本无法定义出通用的大范围的结构定位/变换手段。即使是在设计精良的组件框架中，受限 制于组件的封装性要求，我们也不可能访问到全部的信息。当我们以组件设计者意料之外的方式使用这些组件的时候，就会遇到重重障碍。即使所需的只是微小的局 部调整，因为无法触及到需要修改的部分，我们也可能被迫放弃整个组件。
  
   2. 文本是普适的信道。各种操作系统，各种程序语言所具有的最基本的能力就是文本处理能力，对于文本格式的约定是最容易达成共识的。虽然对于机器而言，理解基 于地址定位的二进制数字可能更加直接，但是所有的应用程序都是由人来负责编制，调试，部署，维护的，如果人可以不借助特殊的工具就可以明确了解到系统内发 生的过程，则系统的构建和维护成本就会大幅下降。
  
   3. 文本表述形式上的冗余性增强了系统的概念稳定性和局部可理解性。在二进制格式中，经常出现的是根据相对地址定位，这要求我们完整理解整个二进制结构，才能 够逐步定位到局部数据块。同时，二进制格式中也经常使用一些外部的信息，例如某个位置处的数据为整型，占用四个字节等。这样的信息可能只能在文档说明里查 到，而在数据体中没有任何的体现，这限制了独立的理解可能性。与此相反，文本格式经常是自说明式的，例如width:3.5px, 这提高了系统的可理解性，特别是局部可理解性。即使我们对系统只具有很少的知识，一般也能根据数据周围的相关信息进行局部操作。一般很容易就能够定位到特 殊的局部数据区，安全的跳过众多未知的或者不被关心的结构. 一个程序新手也可以在很短时间内靠着连蒙带猜, 实现xml格式的word文件中的书签替换功能,而要搞清楚word的二进制格式,并独立编制出正确的替换功能,显然就不是一两周的工作量可以解决的了. 这其中, 可理解性的差异是存在着数量级上的鸿沟的.
  
   4. xml这种半结构化的文本格式规范的兴起, 以通用的方式为文本描述引入了基本的形式约束, 实现了结构表达的均一性. C语言中的宏(Macro)本质上就是一种文本替换技术,它的威力在于没有预定义的语义, 因此可以超越其他语法成分, 破除现有语法无法跨越的限制. 但是它的危险性在于缺乏与其能力相适应的形式约束, 难以控制. 而在xml格式规范下, 不同语义, 不同抽象层面的节点可以共存在同一个形式体系中, 可以用通用的方式进行定位,校验, 转换等. Witrix平台在动态xml方面发展了一系列技术, 为文本处理引入了更多应用相关的规则, 增强了文本描述的抽象能力和表达能力. 
  
   5. 文本作为描述(description)而不是执行指令(execution). C语言的源代码与机器码基本上是一一对应的, 即源代码本身所表达的就是指令的执行过程. 而在Web应用领域, HTML语言仅仅是声明界面上需要展现什么, 但是如何去实现是由通用的解析引擎负责,它并不是我们关注的重点. 描述需要结合诠释(解释)才能够产生实际的运行效果, 才能对现实的物理世界产生影响.这在某种程度上实际上是延迟了执行过程. 一种描述可以对应多种诠释, 例如同样的元数据在前台可以用来生成界面,在后台可以用于生成数据库, 进行数据有效性校验等. 在特定的应用领域中,执行引擎可以是通用的, 可以独立于描述本身不断演化, 因此一种领域特定的描述,它所承载的内容并不是固化的, 而是可以随着执行引擎的升级不断增强的. 例如, 在Witrix平台中, FlowDSL本身所做出的流程描述是稳定的, 但是随着流程引擎不断改进,不断引入新的功能,所有使用DSL的已实现的应用都同步得到升级. http://canonical.javaeye.com/blog/275015
  
   6. Text = Process(Text) 这个不动点在Unix系统中得到了充分的应用: 多个小程序通过管道(Pipe)组合在一起, 可以完成相当复杂的功能. 一个更加丰富的处理模型是 XML = Process(XML). 文本描述很自然的支持多趟处理, 它使得我们可以充分利用全局知识(后续的处理过程可以使用前次处理过程收集的全局信息), 可以同时支持多个抽象层面(例如DSL的不断动态展开). Witrix平台中的编译期运行技术实际上就对应于如下简单规则: 编译期运行产生文本输出, 对输出文本再次进行编译. 通过这一递归模式, 可以简单的实现动态解析与静态描述之间的平衡. 模板(Template)技术是具有关键性作用的文本生成技术. out.write("<div>");out.write(value);out.write("</div>");这种 API拼接方式显然不如<div>${value}</div>这种模板生成方式直观且易于使用. 在Witrix平台的tpl模板语言中, xml的规范性使得在多趟编译过程中我们一直可以维持某种形式约束.
  
   7. 不是所有的情况下都应该使用文本. 普元EOS中所鼓吹的XML总线之类的技术是我所极力反对的. http://canonical.javaeye.com/blog/33794