在Code is Configuration这篇文章中，说到了我对Ruby on Rails优点的理解，那就是RoR的代码相当于是配置，所以能做到习惯优于配置。有人说，这是动态语言的优点，然后把动态语言和静态语言区分开来讨论各自的优劣，然而我觉得这是不能绝对划分的，语言的动态与静态是一个过渡。
举个例子，virtual函数的override也算是一种动态，因为程序是运行时查表寻找最顶层的override函数然后执行的，和所有的动态特性一样，这需要牺牲一些效率。然而我们没有把C#称之为动态语言，因为它还是要经过静态编译才能执行，但这不妨碍它拥有部分的动态特性。因此，语言不能简单的话分为动态与静态两类，这之间是可以平滑过渡的。
既然语言没有动态与静态的绝对划分，那么代码就是配置的概念也应该没有绝对的划分，我们只能讨论怎么样的代码更像是配置。为了说明为什么代码可以说是“更像配置的”，这里就再举一个例子。同样是创建一个复杂的Toolbar，在MFC里面大部分的代码都是用来“实现”这个Toolbar的，虽然MFC已经对Win32API进行了封装，但使用起来还是很像调用API的风格。而在WinForm创建复杂Toolbar的话，大部分代码都是创建控件然后设置属性，这样看起来就更像是“配置”。所以使用WinForm的代码比调用MFC的代码更像是配置。注意我这里说的是“更”，既然存在B比A更好，那就还可能存在C比B更好。比WinForm更好的是什么呢？WPF和C# 3.0，前者能够隐藏更多的实现细节，后者能够让属性设置代码更简洁，让代码看起来更像是在配置控件。
如果抛开执行效率不说，给你设计一门全新的语言，应该如何做到Code is Configuration呢？这先要看看单纯的Configuration是怎样的，例如XML，抛开背后的实现细节，单纯用XML来写程序，或者说是“配置程序”，你又愿意吗？肯定不愿意，因为虽然它的层次结构好，然而写起来很麻烦，和自然语言的差距太大了。因此，理想中的语言应该尽可能贴近自然语言的情况下，同时也能够尽量隐藏实现细节提供高度抽象的可配置性，而后者通常越是动态语言就越容易做好。说到这两点特性，你是否突然想起一门正走向消亡的语言呢？贴近自然语言一直是BASIC所强调的，而同时又是动态语言的，那就是VBScript了。然而最大量使用VBScript的应该就是ASP了，而ASP正在逐步被ASP.NET取代。或许将来有一天，VB.NET能够重新加入动态语言的特性，配合非编译的ASP.NET，能够打造一个好像ASP那样适合RAD的ASP.NET。