如何判断开发语言的复杂度?

一门语言的复杂程度,是由什么来决定的呢?Whiley网站的Dave发表了一篇博文《Language Complexity?》,文中指出,语言形式上的复杂和语言的复杂程度是两回事,手工输入代码量的减少,并不意味着语言的复杂度就会降低。

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

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

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

不管怎样,从这篇文章中,我对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中还有很多其他有趣的例子,我们可以在这里进行讨论。


  译文:CSDN

 

收藏 1 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部