我到底是在干嘛？
此文是针对《【修订】为什么OO方法是有本质缺陷的？》一文中，winter-cn兄弟的回复。一方面，不小心又写的太长了，一方面这个回复也提到了一些我关注的问题。而且我知道好多路过的兄弟和winter-cn兄弟有相似的看法，所以一并说说我为什么钻这个牛角尖。
说实话，这个话题太宽广，我没法从头到尾白活一遍，让每个人都知道我说的那些污七八糟的东西的来龙去脉。
其实我Update的那段话，虽然基本上干瘪、缺乏内容，不过正是针对24楼第三段话的。我针对的绝非OO在带类型、不带类型、静态、不静态等等某种特定范围内的问题。而是我认为在不同范围内，OO这个范型，甚至作为OO基础的一些更根本的理念，体现出来的问题截然不同罢了。
说一个具体问题比较好理解，对于JS那种形式的、运行时动态的对对象所具有的各种性质进行改变，有成本低廉的方式进行静态检查吗？可毕竟，很多东西运行之前我们就是知道的不是。这个问题从某个角度来看，和那些编译期检查固定接口的语言（比如C#），或许出自于相同的根源，虽然它们看起来正好相反。在这里可千万不要较真，举出某个肯定不能静态检查的例子，而是说（对于那些动态修改对象的情况而言），让那些本来能够检查的变得可行，而且不断扩大这个“本来能够检查”的范围。
至于在这方面，我把JS这类语言放在C#前面，仅仅只是限于某些兄弟所针对的特殊范围的需求罢了（而这类需求变得比过去广泛，从而成就了Ruby等），其实不代表我个人真实的喜好。虽然我对函数式、模板、元编程等一些其它编程范型的掌握也还说的过去，实际上我认为我在带类型的OO系统上的设计及实现能力其实是可能是我所有能力中最强悍的。
Speak问题（在这里是签名损失了内涵意义、使得本来能提供的一些支持丧失了的问题），这个文章发的比较早，当时是有特定的语境的。确实，反过来看C，Speak(xx)，也照样存在这个问题（顺便提个脑袋卡我的问题：C或者C++是强类型语言吗？:）。再来看，JavaScript就一定不存在这一类问题吗？其实根据设计思路的不同，答案也是不一而足的。
就像winter-cn兄弟说的，无论在使用什么样的语言时，解决方法很多（比如就某种需要在C#中给Speak加上Attribute），但是这些方法存在着各种各样的缺陷，我们只能被动选择缺陷对我们的影响最可以忽略的那个；而这些缺陷其中一些并不是非承受不可的。在我看来，这都是因为一直以来，不是你我，而是那些语言、方法的作者，忽视了一些东西、或者重视程度还不够的缘故。
我对这一问题的解决办法是，我自己打算成为一个语言及其周边辅助设施的设计者，或者说，真正的把组织这件事提高到一个新高度，成为一套组织系统（就像关系系统之于数据那样）的设计者。
为什么大家总能就具体问题给出反面的意见从而带有反对我的尝试的意味，这是因为我的思路还不清楚，更别提表达的真真切切；所以我的一些话，总是被映射为别人脑海里很具体的一些东西。但是我确实看到一些模糊的影子，我也还在继续努力，就等花开蒂落的那一天了。话说回来，也许限于能力，永远得不到，但我可以很自信的说，即使那样我的想法也是有几分道理的。
对于24楼第二段，比如代码效率的问题。这里有一个可以接受的边界。对于我自己正在构思（或者说臆想更确切些）的语言，我确实可以预测的，它很难健康的运行在比如，只有几M内存或者很少的存储空间的环境下。但是在其它情况下，它能获得不错的抽象和表达能力，在一些方面，恐怕要大大强于现有的类似于C#这样的“静态语言”，并且不会像大多数动态语言一样，损失掉效率或者可能的运行前检查。
如果我的工作成功了，就可以做出一个证明，就是某些不同语言或范式、看似不同的缺憾，其根本原因却是一致的，还是因为对“如何描述”考虑不足；而这一部分，我们可以有一些新的思路来改进。
一般会来跟我讨论这个问题的同志，我想都知道OO或者其它范式的很多特点和好处，其中一些朋友对它们的能力限度也有一定认识。我相信各位也读了很多其他的东西，对所讨论的这些有足够的了解（我也希望大家能相信，这些东西其中大部分也在我的知识和理解能力的覆盖面之内）。
但我确信其实大多数人不知道我所描述的、或者我理想中的，到底是个什么玩意 :P。这不是因为任何一个读者自己的缘故。遗憾的是我目前确实无法有条理的给出一个成型的理论，因为如果我已经能那样，我的工作也就差最后那一点点代码了。
winter-cn兄弟说的很对，我所谓的组织方法，实际上和编程范型这种说法，有很大相似性。像“没有银弹”这样的说法我也认可。但是真的现存的范型和方法、或者它们的某种结合，已经成熟到了每个都在自己的领域内达到了极限的地步吗？如果说你我都认可现在还停留在“铁蛋”、或者“木蛋”的水平，那么咱们的讨论就会集中在现有范型的改进或者创造新范型上。
说到这里，其实我和大伙之间，如果说有什么分歧，其实是对现存方法所达到的高度的认可度之间的差异。也许我是错的，但是我会试下去，也没有啥可以重新考虑的，因为我已经反复了很多遍啦。
回顾了这段话（甚至这一时期就这些问题瞎掰的所有话），除了对于我自己而言，大多数都是废话。可是展开来说，一是不可能，二是我也不见得就能完整的表述。但是有一点我希望大家能够看出来的，就是我是有明确的目的的。如果说我不能解释清楚其内涵，但至少的还有这些：
1. 尽量多的得到可能好处（而不是全部），比如Ruby或者JS里的灵活性，C#、Java的可检查性，泛型或Template带来的通用性，元编程带来的更多的有效描述。
2. 这不能通过的粘合各种范型得到，首先是可能根本达不到1所说的目标，其次是这种方案的复杂性和限制，已经被C++表露的非常多了。所以应该尝试一些新的路子。
3. 关键概念的表达可以自然的在各种横切、纵切甚至外部环境间，在写作时、编译计算期和运行时流动，且尽量减少当前繁复的mapping、adpating工作。
它的更一般的目标，可以为实现更广泛、更彻底、可定制性更强的自动化（比如用推导代替一部分人工）铺平道路、降低成本，提高相似过程的通用性，并降低复用和装配的代价。我认为，抛弃一部分当前的组织形式，结合一些关系型系统的概念和产生式系统的做法，这一目标还是有望实现的，至少最低限度来讲，可以部分的实现。
想要图灵完备，并不是什么难事，这也绝不是任何现代语言作者真正关心的内容。平衡是一个问题，问题还有不少；但即使在保证这种种条件的大前提下，我认为我们也还远没有走到极限，仅此而已。
说实话，这个话题太宽广，我没法从头到尾白活一遍，让每个人都知道我说的那些污七八糟的东西的来龙去脉。
其实我Update的那段话，虽然基本上干瘪、缺乏内容，不过正是针对24楼第三段话的。我针对的绝非OO在带类型、不带类型、静态、不静态等等某种特定范围内的问题。而是我认为在不同范围内，OO这个范型，甚至作为OO基础的一些更根本的理念，体现出来的问题截然不同罢了。
说一个具体问题比较好理解，对于JS那种形式的、运行时动态的对对象所具有的各种性质进行改变，有成本低廉的方式进行静态检查吗？可毕竟，很多东西运行之前我们就是知道的不是。这个问题从某个角度来看，和那些编译期检查固定接口的语言（比如C#），或许出自于相同的根源，虽然它们看起来正好相反。在这里可千万不要较真，举出某个肯定不能静态检查的例子，而是说（对于那些动态修改对象的情况而言），让那些本来能够检查的变得可行，而且不断扩大这个“本来能够检查”的范围。
至于在这方面，我把JS这类语言放在C#前面，仅仅只是限于某些兄弟所针对的特殊范围的需求罢了（而这类需求变得比过去广泛，从而成就了Ruby等），其实不代表我个人真实的喜好。虽然我对函数式、模板、元编程等一些其它编程范型的掌握也还说的过去，实际上我认为我在带类型的OO系统上的设计及实现能力其实是可能是我所有能力中最强悍的。
Speak问题（在这里是签名损失了内涵意义、使得本来能提供的一些支持丧失了的问题），这个文章发的比较早，当时是有特定的语境的。确实，反过来看C，Speak(xx)，也照样存在这个问题（顺便提个脑袋卡我的问题：C或者C++是强类型语言吗？:）。再来看，JavaScript就一定不存在这一类问题吗？其实根据设计思路的不同，答案也是不一而足的。
就像winter-cn兄弟说的，无论在使用什么样的语言时，解决方法很多（比如就某种需要在C#中给Speak加上Attribute），但是这些方法存在着各种各样的缺陷，我们只能被动选择缺陷对我们的影响最可以忽略的那个；而这些缺陷其中一些并不是非承受不可的。在我看来，这都是因为一直以来，不是你我，而是那些语言、方法的作者，忽视了一些东西、或者重视程度还不够的缘故。
我对这一问题的解决办法是，我自己打算成为一个语言及其周边辅助设施的设计者，或者说，真正的把组织这件事提高到一个新高度，成为一套组织系统（就像关系系统之于数据那样）的设计者。
为什么大家总能就具体问题给出反面的意见从而带有反对我的尝试的意味，这是因为我的思路还不清楚，更别提表达的真真切切；所以我的一些话，总是被映射为别人脑海里很具体的一些东西。但是我确实看到一些模糊的影子，我也还在继续努力，就等花开蒂落的那一天了。话说回来，也许限于能力，永远得不到，但我可以很自信的说，即使那样我的想法也是有几分道理的。
对于24楼第二段，比如代码效率的问题。这里有一个可以接受的边界。对于我自己正在构思（或者说臆想更确切些）的语言，我确实可以预测的，它很难健康的运行在比如，只有几M内存或者很少的存储空间的环境下。但是在其它情况下，它能获得不错的抽象和表达能力，在一些方面，恐怕要大大强于现有的类似于C#这样的“静态语言”，并且不会像大多数动态语言一样，损失掉效率或者可能的运行前检查。
如果我的工作成功了，就可以做出一个证明，就是某些不同语言或范式、看似不同的缺憾，其根本原因却是一致的，还是因为对“如何描述”考虑不足；而这一部分，我们可以有一些新的思路来改进。
一般会来跟我讨论这个问题的同志，我想都知道OO或者其它范式的很多特点和好处，其中一些朋友对它们的能力限度也有一定认识。我相信各位也读了很多其他的东西，对所讨论的这些有足够的了解（我也希望大家能相信，这些东西其中大部分也在我的知识和理解能力的覆盖面之内）。
但我确信其实大多数人不知道我所描述的、或者我理想中的，到底是个什么玩意 :P。这不是因为任何一个读者自己的缘故。遗憾的是我目前确实无法有条理的给出一个成型的理论，因为如果我已经能那样，我的工作也就差最后那一点点代码了。
winter-cn兄弟说的很对，我所谓的组织方法，实际上和编程范型这种说法，有很大相似性。像“没有银弹”这样的说法我也认可。但是真的现存的范型和方法、或者它们的某种结合，已经成熟到了每个都在自己的领域内达到了极限的地步吗？如果说你我都认可现在还停留在“铁蛋”、或者“木蛋”的水平，那么咱们的讨论就会集中在现有范型的改进或者创造新范型上。
说到这里，其实我和大伙之间，如果说有什么分歧，其实是对现存方法所达到的高度的认可度之间的差异。也许我是错的，但是我会试下去，也没有啥可以重新考虑的，因为我已经反复了很多遍啦。
回顾了这段话（甚至这一时期就这些问题瞎掰的所有话），除了对于我自己而言，大多数都是废话。可是展开来说，一是不可能，二是我也不见得就能完整的表述。但是有一点我希望大家能够看出来的，就是我是有明确的目的的。如果说我不能解释清楚其内涵，但至少的还有这些：
1. 尽量多的得到可能好处（而不是全部），比如Ruby或者JS里的灵活性，C#、Java的可检查性，泛型或Template带来的通用性，元编程带来的更多的有效描述。
2. 这不能通过的粘合各种范型得到，首先是可能根本达不到1所说的目标，其次是这种方案的复杂性和限制，已经被C++表露的非常多了。所以应该尝试一些新的路子。
3. 关键概念的表达可以自然的在各种横切、纵切甚至外部环境间，在写作时、编译计算期和运行时流动，且尽量减少当前繁复的mapping、adpating工作。
它的更一般的目标，可以为实现更广泛、更彻底、可定制性更强的自动化（比如用推导代替一部分人工）铺平道路、降低成本，提高相似过程的通用性，并降低复用和装配的代价。我认为，抛弃一部分当前的组织形式，结合一些关系型系统的概念和产生式系统的做法，这一目标还是有望实现的，至少最低限度来讲，可以部分的实现。
想要图灵完备，并不是什么难事，这也绝不是任何现代语言作者真正关心的内容。平衡是一个问题，问题还有不少；但即使在保证这种种条件的大前提下，我认为我们也还远没有走到极限，仅此而已。
