语言的一些思考

近几年来，我越来越多地思考语言问题。或者换句话说，表达方式问题。当然，我认为维特根斯坦后期的哲学是对的，虽然还不够精细。也就是说，我认为语言寄生在要表达的问题中，并强烈依赖于“生活方式”。
让我们把焦点聚拢一下，对准计算机程序设计语言这种人工语言，好使的我们的讨论可以落到实处。上面说到，语言与问题密切相关，那么我们看看计算机程序设计语言关联的问题是什么。
计算机程序设计语言泛泛的说，是要解决各种可计算问题。对于可计算问题，图灵机清晰的捕获了这个概念，谁想深入请自己去看相关论文。具体的说，计算机程序设计语言就是用计算机解空间元素表达问题领域的问题的。更直白的说，计算机程序设计语言就是要表达出问题领域的问题的一个抽象（或者叫做模型）。由于问题领域元素无限丰富，逻辑上讲，研究问题领域元素无助于我们对于计算机程序设计语言的认识。所以我们聚焦在计算机解空间。它的元素相对清晰和有限，我们可以有一个坚实的基础讨论计算机程序设计语言。
计算机空间涉及到的，直觉可以捕获的就是数据和算法。往下落实就成了数据及指令，在往下就是存储了，所以往下没有什么价值，往上呢？往上就散焦了，就跟领域模型贴近了。所以，我们就关注数据和算法。
我认为一个合格的计算机程序设计语言应该能够比较好的支持数据抽象和算法（函数）抽象。好，现在已经到了我们的立足点了，我们要以此为基础，探讨计算机程序设计语言应该有的几种基本构造。
对于数据抽象，其实从COBOL提出来记录以后，再也没有什么特别值得惊奇的发展。也就是说，对于数据抽象，记录（熟悉C语言的可以想想struct）作为数据抽象是完善的。后来的Object其实也没有脱离了记录这个基本的概念。只不过把可以操作这个记录的那些操作绑定在记录上了而已。
算法抽象则复杂的多，最初抽象为routine，表示一个操作序列，后来抽象为lambda（abstract），表示一个对应（转换、操作）法则。 Eiffel还特地的区分出query和command，我们意识到，这个区分对于表达契约必不可少。后来发展出来closure，也不过就是 lambda加上该操作施加的对象（数据）而已。
但是，很快的，人们发现操作序列本身没有多少好讨论的东西，反倒是操作序列所生存的环境跟操作序列之间，操作序列们之间有各种各样的可能性。很快，人们发展出来最稳定的caller和callee；以及非常常见的coroutine和yeild，另外，另一个角度出发又出现了thread和 concurrent。最后，我们的主角登场了，它的名字是aspect，按照发明者的解释，它是横切关注点。也就是说，它是横跨多个模块的，与模块本身的业务逻辑关系不大但是与整体的系统要求密切的那种东西，比如事务，安全，性能统计，日志等等方面的东西。显然，它发现和关注所有算法抽象的共性，也就是所有算法不太关注的，对自己来说非本质的东西。显然，这种东西非常有用。这个东西最基本的实现方式是：Intercepte。也就是需要在算法抽象的执行序列中的某一点插入一个别的执行序列，以完成共性的东西。
据我的理解，一旦一个问题能够有一个清晰而高效的数据抽象来表达，那么这个问题就算是解决了。对于算法抽象，它们之间的各种关系，都可以用栈做一个清晰的表达。但是，我们还有一个更通用的方式，那就是：Continuation，它可以高效的表达上面所有的算法抽象关系构造。
另外，我们不能忽略现阶段计算机编程语言所发展的概念，比如：泛型、静态类型安全、元数据、契约、类型推导、MOP等等。原因是这是“生活习惯”，这是大家都接受的一种状态。
这样我们就可以以这些基本构造创建一个新型的通用目的的语言，对它的扩充可以方便的进行，不需要对语言本身进行大幅度的修改，而只是提供各种各样的组合这些语言构造的库就可以了。
用它跟发展中的C#3比较的话，我可以非常自豪地说，这个语言比C#3简单易学，同时比C#3优雅强大：）。因为我们只需要面对非常少的非常流行或者通用的概念，就可以构造出来非常强大的抽象。当然了，这儿我没有提到BETA，它其实跟我构想的语言是最接近的了，不过，它用了一个不太流行的概念叫做 pattern，这恐怕是阻碍它流行的一大原因。因为语言毕竟是一种“生活方式”，无论从哪个角度来说。