检讨和一些对C的新看法

我不应该在这个博客里说无关的事情，其实我真正的动机是保证发文章的频率。我对技术以外的事情，除了一些愚蠢的人类的欲望和心里反应还在，其实理智上是早已放弃的。

最近研发工作很不顺利，就越发关注不相干的事情；结果效率就越低。这真是太堕落了。随着年龄的变大，未来精力肯定会衰退，以我的目标而言，在这么耽误时间是绝对要不得的。

即便以这个博客本来可以对其他人的价值而言，我也太浪费了。没得说就不发文章就好了，何必去提那些根本不值得关心的事情。大家来和我交流也不是为了这些垃圾事情。

以后基本上只写我自己技术上的总结。我应该变成一个纯纯粹粹的技术人，最多再加上对技术修炼如何提升自身社会价值的思考。包括自身状态上，抛弃掉无用的东西，轻装上阵。

--------

最近一个实践的小技巧是：几行代码的实现了一个利用C++ lambda的资源管理对象（省得写free/delete的同时，防止异常带来的资源泄漏），比老的方法又少了些繁文缛节；推荐。另一个感受是C/C++还是不够灵活，即便是只看纯C其语言本身的假设也太多。

从这个角度看，原来被灌输的“C不是高级语言”的看法就不那么成立了。它并不像想象中那样贴近机器/系统本身的模型，而只是自动化管理的机制和其它东西较少，多放了一些权罢了。内存分配的方式是一个例子。一个问题是选择限制为两个：函数签名中暴露外部不关心的细节以利用栈（说穿了是已经开好的并由运行时管理的一块内存），或者开在堆里给外部一个指针（抽象的说就是引用了）。

这表面上看起来是个取舍问题：提供机制越多越方便，同时承受代价。但深层次的看事情未必这么简单。我觉得这些语言自动化机制本身是不可定制的，这才是根源所在。比如上面他提到的资源管理的小技巧，它本身是一些语言提供特性的组合，这是一种可配置性；但更根本的，这些语言特性本身却是死的。这个有用加这个、那个有用加那个，一个机制中正面负面还都得照单全收，什么时候才是个头呢？

元编程的概念还应该继续深化，并且如果提供元编程的特性，它应该至少在一些关键性的地方可以自我配置，且它的工作层面应该完全贴合在更底层的硬件/系统模型之上，更好的是只表达底层模型的知识和它们形成的限制与模式。编程应该变成纯粹的新知识表达、已有知识重复利用的过程而尽量减少其它限制。比如现有自动化机制给的，是“已有知识重复利用”；如果这个现有的不是最贴切的，应该可以让程序员自行安排并被其它人利用。

产生这些想法的根源在于，我个人工作中总是存在着选择上的摇摆。A也是鸡肋、B也是鸡肋；两个鸡肋中选择最好的一个，需要的各种考虑其量却是巨大的。相比让用户自己创造（虽然也要花费大量时间），这是完完全全的浪费。

说白了继承我原来的思路，不但面向对象一类的高层次方法论映射到语言具体设计中是毫无必要的、过程抽象的当前这种具体实现也是（当然函数式也跑不了）。这些软件构建方法的甜头归根结蒂在于提供各种模子，在不存在物理限制的领域这太落后了（都这样是reasonable的，但未必仍旧是合理的）。

其实现代软件开发的这种瓶颈，观察C++的话是再明显不过的。从语言设计的所谓“演进”、到STL库的各种设计，复杂性成快速增长；但这种增长却并未很好的切合用户需求。比如我曾考虑结合allocator定制和placement new解决std::vector安放在内存什么地方的问题，可是这个方案也太蹩脚了一些，也还存在种种限制。

真正的程序员（不考虑单纯用现有技术完成需求的开发人员）必须从这种种桎梏中解放出来，软件质量的提高才有指望。看看这些垃圾的软件吧，从操作系统到外壳到应用软件，本来一切都该更好的。更不要提那该死的火星探测器了。