自一个人默默走

早晨吃饭的时候总结了几个事情：

• 公司使用的 CXCentaur 框架，几乎和现在市面上使用的 Java VM, .NET Framework 的架构理念是一样的；换句话说，CXCentaur 实现了一个非常快速的虚拟机环境；
  
• 原先我一直在考虑从 C/C++ 中调用脚本的方法问题，实际上那个是错误的思路——也就是说 C/C++ 通常做为脚本的下层出现，从理论上并不会去关心脚本中有什么内容；
  
• Python 是一种复杂的脚本，因为它要提供的东西太多了；而相比之下，公司内部使用的在 CXCentaur 之上的 LPC 脚本就非常的简洁——但问题在于 LPC 太过于 C 化了，以至于所有的调用都是 procedure call 的封装——不过目前没有发现有什么缺点；
  

补充：

• 刚刚想到，从 C/C++ VM 中调用脚本的方法是可能的，VM 不会;主动去关心脚本的内容，但是脚本可以在 VM 中注册方法，让 VM 进行回调；
  
• LPC 全部使用全局函数调用，在现在看来不是缺点；相比之下，C 的语法虽然不美观，但是目的非常明确；广泛地使用全局调用，在 C++ 看来是一种名称污染，但是就目前来看，这样的方法也没有产生什么问题；
  

就暂时叫做 eed 吧，晚上写了一些基本的构架，发现了一些问题，阶段总结下：

• 基于思想进行设计，尽量不依赖于某一特性，例如 c++ namespace；
  
• 当一个想法并不容易实现时，换一个角度也许会更容易；
  
• 一个合理的系统应该由思想而来；重构的大部分精力也要花费在思想上，而不是代码的某个细节上；
  
• 一个没有思想基础的软件工程，每次更新都是只是在“堆代码”；
  
• 所有“未将来扩展性”的考虑是，把现在所有必需满足的、和可以预见的需求全部写出来，然后做一个有十足“凭据”的预见性设计；
  
• 对于各种可供选择的想法，列举出它们所有的优缺点，然后进行比较选择；如果不能做出一个很好的选择的话，不妨两个都实现，用 policy-based 的方法结合，或者说干脆就换一个思路；
  
• 在整个设计完成之前，不要做任何的优化考虑——除非有非常严重的瓶颈问题；
  
• 总之，不要影响主线设计的行进；
  
• ooa/d/p, tod/p 的设计方法中，几乎都采用了 edd 来处理各种复杂逻辑，因此在思考的时候大量地向着 edd 的方向行进。
  

就先这么多吧。设想的东西很多，但是基本的功能才是最重要的，因此在整个设计中，界面和代码逻辑不是耦合的——至少在我看来 emeditor 虽然好，但是它的很多东西是粘在编辑器上的。

昨天和一个同事聊天，谈到 c++ exception，今天上网找了些资料，回想了一下——没错了，c++ exception 除了给程序本身带来过多的复杂性，并没有对错误处理非常大的贡献。

怎么会提到这个问题呢——首先，当一个 c++ exception 被 throw 时，一般情况下要临时构造一个 exception class，那么分配在 try 栈内的变量/类实例，拥有一些在 destructor 释放资源的惯用法(例如 smart_ptr)，对于没有经验的程序员，并不能准确地知道其里面做了些什么事情；且 c++ 标准中没有 finally 的关键字，很多额外的资源要怎样才能保证释放呢？

总之有很多很多的概念，我可以说 c++ 是现在市面上使用的最复杂的程序语言(我不知道要不要加上“之一”)，当然 c 语言做很多类似 c++ 的工作的话有很大的代价，所以我要先阅读些 c 代码，然后考虑是否从 c++ 转移到 c。

刚刚随意地在网上翻看 borland.com，忽然想到一个事情：商业 ide 的整合性非常好，而 open source 的东西，很难有一个完整的产品——虽然有很多人把此当作民主、自由，因为可以任意地搭配自己需要的东西，但问题是，当需要一个马上能用来做一系列事情的东西，你还有心情去搭配吗？

说这个例子的原因是，我在看 bcb 的产品线，想：既然 c++ gui 的设计比较困难，那么为什么不能有一些像 bcb 那样搭配好的产品呢？绝大部分 open source c++ ide 的 gui 往往都没有一个比较统一的标准，或有着各种参差不齐的特点，例如：kdevelop 只能运行在 kde 上，anjuta 也只能运行在 gnome 上；code::blocks 虽然可以跨平台，但非常不幸的是它至今没有 release，商业产品根本不敢用它来开发，当然也有很多人不喜欢 wxwidgets 那样的保守风格。

这里要提到 java 是一个特例，java 的 ide 几乎都有完整的 gui, debug, refact, ... 功能，这和 java 本身有一定的专治色彩是分不开的。

我现在想寻找一个完整的，用于 python 开发的 ide，无论从 gui, debug, refact, ... 到完整的解释等等都有的成品——我不想花费自己太多的精力去考虑从 vim, emacs 等“强大”的编辑器中去组合一个 ide 了。

templates 实在是 c++ 中最优秀的思想了，不，应该说 templates 是程序设计中产生的最优美的思想了。

于是就有人想把 c 中安插上 templates，于是就诞生了用 c++ 编译器来编译 c 代码的方法，也产生了 gp。实际在我理解中，扣除 class 等一些特性的话，gp 就是 c 的 pb + templates。

早晨上了 cto 的一堂课，感触颇深——用过程式的语言来实现各种 oop 的设计技法——这也可以理解为什么公司里不过多地使用 c++ boost library 等 template features。

想起我在 n 年前去面试时，我跟一个公司的 cto 说：“用 c 可以实现几乎所有 c++ 的事情”——最后被骂了一顿——现在的 cto 告诉我：“这完全是可行的”。

话题回到 templates 的问题上。cto 早晨说过：“lpc 中的 mixed 类型是非常优秀的，相比之下，c 就没有完善的实现”。所谓的 mixed 就是一种可以放置下所有类型的类型，在 c 中的 void * 我不知道有些什么样的副作用，等春节期间好好地研究下 c。

我现在居然为了自己该使用哪种 programming paradigm 而犯愁。

只能说我选择的两大语言都具有 multi-paradigm programming 的特点，所以在选择上，还是有问题的：“太多的选择往往不是好事”。

有时候回想起来 java 的专治性也有一些好处，例如它强制 programmer 使用 oop；强制使用 camel 来为类方法命名等等；强制默认的成员方法为 virtual；强制语言中的所有东西都是 object……

而我现在使用的 c++ 和 python 就没有那么强烈的限制：在我的学生时代，这些看起来是非常民主的措施，但在工作的时候，这种民主则变成一个非常糟糕的选择题。java 的纯 oo 思想，可以让我们集中精力在用 oop 来解决问题上，然后使用其它的诸如 gp 等方法来改进代码的设计；而 c++ 则在一开始就要我们做出一个选择——是优先使用 oop 来解决问题呢，还是使用 gp。

绕了一圈，又回来了，非常讽刺的是，我把学习 Emacs 的经验，用在重新审视 Vim 上。

在选择一个良好的编辑器时，我主要看重这几个方面：
1. 良好的文字编辑：当然，这是编辑器最基本的，也非常必要的；
2. 有强大的搜索能力：我使用过 EmEditor 其依赖的 regex++ 所具备的搜索、替换、全文搜索、批量替换、正则等等的支持，是我使用过的在这方面最强大的编辑器；然而 EmEditor 在代码补全文件排版等等方面也有不足，因此，使用其它的编辑器也是要考虑的问题；我本来没有找到 Vim 的文件搜索功能，就在我卸载掉 Vim 的时候，却阴差阳错地找到一个 Vim 的用户组——了可以使用 vimgrep 进行文件搜索；
3. 有非常强大的自定义能力：在这点上，我非常欣赏 Vim 和 Emacs，它们提供了非常强大的脚本语言，几乎可以做任意的修改；
4. 灵活的扩展性：我试用了 SciTE，但这最终造成了我不得不放弃使用它——其基于 C++ 编码的，不支持脚本进行动态扩展，每做一个改动都要修改 C++ 源码，然后重新 make；
5. 编译、调试支持：SciTE 虽然可以很好地捕捉到编译器的错误输出，但我不知道如何更改其编译参数、也不知道如何将其结合 GDB 进行调试；其虽然可以调用 python 解释器，但是我不知道如何结合 PDB 进行调试；在这个方面上支持的提供集成支持的只有 Vim, Emacs 和 Visual Studio；
6. 最好是免费的：上面提到的 Visual Studio 就被排除在外了，我不想让自己的开发事业建立在某种要钱的产品上，所以只能使用 Vim, Emacs, SciTE 等等；
7. 功能细腻：这点我本来不是非常在意的，但是用了 Emacs，发现其很多的功能相对于 Vim 来说比较粗糙——比如说显示行号，一个非常简单的功能，但是 Emacs 居然要使用插件来实现，并且使用的时候有诸多的限制——也许是我对 Emacs 的了解还不够吧；

回想起两年前，我还在思考使用单纯的 c++ 进行开发工作的事情，现在想起来都
觉得好笑。

今天下午在书店看书，看到有些脚本语言的——在前一个公司——他们使用 mfc 开发
界面——由此而引发我开始思考使用脚本来编写 GUI 的路看来是正确的。

现在的公司中，我从事着用 cegui 开发 game gui 的任务，在现在看来，界面与
逻辑分离的实现也是合理的——在某种程度上 vcl 比 mfc 方便，但很少有公司把
vcl 用在商业开发上。

于是现在的开发思想非常简单：用 python 做几乎所有的事情；在 python 力所
不能及的时候，才使用 c++ 开发底层扩展供 python 调用。

原本这个是要写入我的一个《》手册，但是公司对代码控制很严格，我也懒得把文档拷贝来拷贝去的，所以就先写在这里了。

KISS - Keep It Simple, Stupid.
相信很多人都知道，特别是程序员，但是我现在要讲的不仅仅停留在 KISS 上。
在实际的编码中，我发现了 KIISS 的重要性——
KIISS - Keep Its Interface Simple, Stupid.
这里不仅仅是强调简单，而是要强调被暴露的接口简单。我原来觉得如果 C++ template 不能实现接口文件和实现文件分离的话，那还不如所有的成员方法都写成隐式 inline 的形式——但结果证明，那种写法中接口和实现混合，非常混乱。
于是我就开始探讨一种极其简化接口的方法，最终的总结还在不断进行中，但是有一些已经在实际编码中使用的方法，如：使用 pImpl；使用 GP Interface 方法等等。

当然这只是初稿，还要整理。

前些天自己在思考设计一种 GP 脚本的问题，还有昨天在网上看 D Programming Languare 和 DMDScript 的资料，昨天晚上睡觉前突然有所感触，今天早晨上班赶快笔记下来。
首先，我认为前些天的那些想法是错误的。因为创造一种自己的语言，代价不只是写的成本高，在与他人交流、融合别的设计等等方面也是比较困难的；
第二，D 和 DMDScript 试图创造一个完全属于其自己的世界——可能在其设计者眼中，D 和 DMDScript 语言本身是完美的，其组合也是完美的——但有一个事实不得不看到——D 的应用面非常狭窄，换句话说，几乎没有企业把 D 用在直接的项目开发；
最后，说一点自己的打算：我不准备创造一种自己的脚本语言(它本来叫做 CZS - Concept Z Script)；也不准备去学 D 或 DMDScript；也许会去学一种与 C++ 结合非常好的脚本语言，也许会做些修改；但是有一个原则——去接受融合别人的设计，而不是试图去创造一个世界。