longshanks

    根据观察，我发现有两类程序员。一类程序员喜欢技术，会认认真真地学习一种语言，设法掌握语言的使用要领和方法。他们关心的是语言的功能，以及功能的运用。对于语言的缺陷有相当的容忍度，并且也乐意接受语言的缺陷，只要语言能够提供足够强大的功能。
    另一类程序员则相反，他们更侧重于用语言实现某些具体的业务。对于他们而言，语言的功能强大与否没什么关系，只要别妨碍他们在软件中实现业务。
对于前者，语言的功能至关重要。他们需要一种语言帮助他们最大限度地发挥智慧和创造力，更快、更好、更高效地构造稳定、可靠、快速、可扩展、可复用的软件。
而对于后者，语言的简单至关重要。他们需要一种语言帮助他们最大限度地发挥智慧和创造力，更快、更好、更高效地将业务转变成软件的功能。
    如果认同一类程序员，而贬损另一类，那就太狭隘了。这两种程序员对于软件开发而言，都有各自重要的地位。更重要的是，这两类程序员是互补的。前者的能力适合开发可扩展的基础服务和组件，他们是技术专家。而后者则恰好符合业务实现专家的特征。
    然而，我们传统的组织形式却将这两类程序员压缩在一个共同的空间中执行开发工作。也就是让他们使用同一种（或同一层次的）语言和技术开发软件。
    现在的麻烦是，没有哪一种语言既简单、方便，又功能强大。如果选用功能强大的语言，比如C++，那么技术专家满意了，他们构造出漂亮优雅的软件。但对业务 专家是个灾难。他们发现自己已经不知不觉地陷入了语言复杂性的泥潭，而艰难地试图抓住业务功能的枝干。而反之，选用使用方便，但功能弱小的语言，对于业专 家是个福音，他们可以专注于业务实现，心满意足地完成工作。但技术专家却无法按他们的想法达到诸多技术性和软件工程性的要求，比如性能、可维护性、扩展性 等等。
   最终，多数企业会选择一种“中性”的语言，功能基本完备，但不很强大，学习和使用相对简单，但又不是最简单的。这样的折中一般会基本“摆平”这两类程序 员，但也有很多时候让两类程序员都不满意。大多数情况下，即便两类程序员都满意了，却在客观上使得两类程序员都无法发挥最大的工作效率，从而无法使开发效 率最大化、最优化。

   解决这类问题最直接的方法就是让这两类程序员使用各自适合的语言，在各自擅长的领域开发软件。技术专家使用C++之类功能强大，却不易掌握的语言，而业务 专家则使用简单易用的语言，比如脚本语言、宏语言，甚至是某种特定用途的专用语言（DSL）。技术专家开发基础服务平台和组件，业务专家则运用简易的语言 使用基础服务和功能，构建业务系统。这种优化组合往往会产生1+1>2的效果。

    对于语言的选择，技术专家无外乎C++、Ada之类的“全能”通用语言，新兴的D也可能成为更加适合的候选人。业务专家，可以使用脚本语言，如 python、ruby、javascript等等“粘合剂”语言。目前尚有一种新的发展方向，是运用专门的专用领域语言（DSL）。这类语言可以非常贴 近业务领域的逻辑概念，语法不一定完备，但足以完成特定的业务工作。比如某种“记账”语言，就可以用来构造财务软件的业务逻辑，直接使用财务术语和概念， 最大可能地消除与业务无关的语言要素，达到最简化的目的。

    这两类程序员的差异不一定是先天造成的，但这种差异足以对传统的软件开发组织形式提出挑战。因此，当我们在抱怨一门语言如何如何功能不济，或者如何如何复杂难用，那么请审视一下开发体系，或许一种语言已经被用在不适合的程序员，以及不该用的地方了。

vc2008中，mfc将大幅度地更新。我猜测更新mfc的原因，很可能mfc中的一些代码阻碍了vc的进一步发展，不得不加以更新。
我以前曾经提起过，mfc有一个严重违背c++标准的地方：
class   H;
class   S
{
public:
        x()   {
                H*   pThis=this-offsetof(m_s,   H);
                ...
        }
};
class   H
{
        S   m_s;
};
H里包含S的对象，在S里，为了获得宿主类H的指针，用自身的this指针减去m_s在H中的偏移量。这就要求一个类中的子对象必须同宿主对象放在一起 （连续分布），并且固定（偏移量永远不变）。为了在对象布局上给予编译器充分的自由，标准规定offsetof只能用于pod。mfc仅考虑在   vc上使用，所以为了方便而仅仅面向vc编译器编码。这带来了移植性的问题。不过，编译器间的移植性还是小事。现在我们就可以看到mfc的这种做法是搬起 石头砸自己的脚。
sutter和lippman都不止一次地提到将来vc要能够不区分托管和本地的内存管理。也就是说托管的类型可以在native堆上分配，而   native的类型可以在托管堆上分配。问题来了，由于托管堆上，子对象和宿主对象的存放不是连续的，子对象可能同宿主对象隔着十万八千里，和成千上万的 对象。而且子对象可能会在宿主对象的前面。offset也是不确定的。在这种情况下，使用上面的这种代码无异于自杀。所以，为了实现托管和本地内存管理的 统一，必须放弃offsetof这类畸形代码。由此导致了mfc的大幅更新。
另一方面，vc越来越符合标准，而mfc中一些遗留的其他不符合标准的地方，使得编译器不得不同时应付两种情况：标准的和非标的。对编译器着实是个负担，消除这些非标的东西，反而能够使得编译器更加简单高效。
以上这些都是猜测，实际如何，还需具体看2008的mfc库代码。不管怎么样，如果你想要使自己的代码依赖于非标准的特性的话，请三思而后行。

     摘要: 编程 是艺术，这无可否认。不信的去看看高大爷的书就明白了。艺术对于我们这些成天挤压脑浆的程序员而言，是一味滋补的良药。所以，在这个系列中，每一篇我打算 以艺术的形式开头。啊？什么形式？当然是最综合的艺术形式。好吧好吧，就是歌剧。当然，我没办法在一篇技术文章的开头演出一整部歌剧，所以决定用一段咏叹 调来作为开始。而且，还会尽量使咏叹调同文章有那么一点关联，不管这关联是不是牵强。 噢，我亲爱的...  阅读全文