静态信息的确是不完全的，但是有些东西最好还是让程序员自己来说明。比如说栈，你可以根据代码进行静态分析，让程序自己得出结论某个变量有明确的作用域。可是那只是一种结果，却不能反应程序员的意图。如果像C这样显式地说明栈，那么说明的就是程序员的意图：我不想让栈里的这些变量的作用域泄露到栈外。栈相当于微观上的模块边界，如果这些都要让程序去检测、去猜测，那么显然就是让程序去决定微观模块边界了。如果需求不变，那么代码形成的事实上边界就是程序检测出的，以这个边界来组织目标代码是没问题的。但是如果需求会变呢？当代码写完之后过了一段不长不短的时间后，当人不记得程序的细节之后，一段代码里如果没有程序员给出的显式边界，那么如何理解程序中各种变量的意图？即使读代码的人能够看出代码里事实上的边界，但是按照原先的设计，设计意图中的边界却得不到体现，于是就只知道这个变量目前的生存期可以压缩到某个范围，却不知道在这个范围之外对它的使用是否符合原先的设计，而且如果使用了某个超出了设计中的边界的变量，那么这时编译器是无法检测出来的，于是编译器本来能够检测的错误就无法检测出来了。如果代码里不能承载设计信息，那么也许一时之间没有问题，但是当一段时间之后，人遗忘了设计信息之后，这段代码就变得难以维护了。任何程序，也许能够了解这段代码目前的情况，也许能用各种技术进行扫描和推断，但是这些技术无法从根本上理解需求，所以它们获得的信息同样是不完全的。也许人对代码的了解不如这些分析程序多，但是人对需求的了解绝对多于这些程序，其实我认为这些程序无法理解需求。一段代码，如果要复用它，那么就要知道使用它的前提条件，以及使用它时要为它提供什么样的环境，所以一段代码自身附带的设计信息越多，越容易让人理解它，那么就越容易复用。

而关于隐藏，仍然有个维护性问题。人对一个东西了解的越少，那么就越难以理解、维护、修改和复用它。乱序执行CPU指令给多线程程序的编写所带来的麻烦已经是个事实了，已经影响了语言标准的修订。
另外，各种技术本身是有结构成本的，要用gc来隐藏内存管理问题，那么人就要学会使用gc，就要理解gc，可是由于gc的行为和具体的runtime有关，所以理解它的机制不难，但是要理解某次应用程序崩溃过程中gc的行为那就难了。gc本身是靠不确定性来应对不确定性的，所以我觉得gc能力的增强往往会带来更高的不确定性。gc这样的技术，在隐藏了内存管理之后又引入了新的问题，引入的就是gc自身的不确定性。


我并不是要完全否定gc，我也说过，当栈、内存池和智能指针都不能满足需要时，我会选择gc。所以我并不是呼吁丢弃gc技术。我要呼吁的是，gc始终是无可选择时的选择。我认为现在最需要的是完善确定性的管理办法。用各种不同的方法来互相填补表达能力的空白。在我的理解之中，某些情况下栈的效果不好，这时由内存池来弥补这一空白，如果内存池也不行，就靠智能指针……就像cat说的，智能指针自身也不怎么样。所以我这些帖子的重点是，要在栈和内存池之外设计更多的高确定性机制，来填补内存池和智能指针之间的空白。按照确定性由高到底排序：
栈 > 内存池 > ？ > 智能指针 > gc
现在需要设计处于？位置的机制。