【观点】如何判断开发语言的复杂度？

 

一门语言的复杂程度，是由什么来决定的呢？外网Whiley发表了一篇博文《Language Complexity?》，文中指出，语言形式上的复杂和语言的复杂程度是两回事，手工输入代码量的减少，并不意味着语言的复杂度就会降低。CSDN对此文进行了编译，全文如下:

有些开发语言很复杂，有些则比较简单……对吗？C++与其他任何语言相比就是一个很好的例子。但是，是什么决定了语言的复杂度呢？

我正在读 Bruce Eckel的关于Scala的文章。它确实是一篇很精彩的文章，我很喜欢它。但有件事却困扰着我，下面这段引用可以很好的概括这件事：

通过上面的代码，你可以看出学习Scala比学习Java简单得多。在输出“Hello, world!”时，不必再写那令人讨厌的Java形式语句，在Scala中，只需一行语句即可：

println("Hello, world!")

不管怎样，从这篇文章中，我对Scala并没有获得同样的感觉。它似乎在说明去掉“public static void”就可以使一门语言变得简单。然而我不认为一门语言复杂与否与形式语句有多大关系。当然，它减少了“用手打字”劳动量，但这和语言复杂度是完全不同的事情。

依我的看法，如果在一门语言背后有一个清晰的思想模型，那么这门语言就会很容易使用。开发者可以利用它来理解某些结构的产生原因及适用于什么时候。请看下面Bruce对Traits的描述：

我们在使用Traits时也容易产生混淆。Trait和接口很像，不同之处在于Trait可以包含方法的定义，创建新类时可以成为该类的一部分。

上面描述并不能帮助我理解Traits到底是什么。问题是：我为什么要用它们？什么时候该用它们？什么时候不该用它们？现在，我不想讨论Traits是（或不是）一个复杂的属性。关键点是：上面的解释并不能让我得出“Traits是简单的”的结论，原因就是它并没有让我了解Traits背后的思维模型。

教学生如何编程，是理解那些难懂概念的好办法。为了让学生确实了解某事，你需要创建一个思维模型。例如，在解释参考/指针时，由方框和箭头组成图可以起到很大的作用。不过，在Java中，也确实有很多棘手的问题：

Subtyping。掌握Subtyping什么时候适用什么时候不适用，确实是一个难点。当然，学生起初可以通过记忆来记住子类型关系，你可以这样解释“如果A继承了B，那么A就是B的子类型”等等。但这并不能帮助构建展示子类型及它所起的作用的思维模型。对于基元，我们有一个很好的经验法则：一个数字类型T1转换为另一数字类型T2，其在精度上没有任何损失（当然，并不是总会这样的）。但是，此时的思维模型是什么呢？好，第一个问题就产生了：为什么不同的类型（比如short类型和int类型）会有不同的范围呢？只有已经理解了数字的二进制表示的同学才能理解这个问题。对于对象而言，你可以通过对比静态模型和动态（换言之：运行时）类型开始讲起，大部分时候，这样比较容易理解的。

动态调度。在一个给定的继承层次结构中，理清在特定的环境中调用了哪个方法，对很多人来说都是一种挑战。这一切都是因为对此很难给出一个精准的规则所造成的（换句话说，你最近有读过关于这个主题的《The Java™ Language Specification》一书吗？）。为了构建一个思维模型，你需要考虑方法签名，静态类型及动态类型等等。在某一点，情况不会太遭。但是，随后考虑到Generics 和Erasure时，思维模型就开始变得越发复杂了。

接口VS抽象类。这又是别外一个经典。至少也有一个简单的经验法则：使用接口和抽象类仅仅是为了代码重用。但是，这背后的思维模型是什么呢？好，学生通常都会以这个问题开始：为什么只能继承一个类呢？下一步，当你解释多继承会带来很多易犯的错误时，事情就会变得难以掌控了。

我确信，在Java中还有很多其他有趣的例子，我们可以在这里进行讨论。