为什么选择Scala

如果你是一名Java程序员，并且关注这编程语言方面的发展，比如经常去TIOBE网站了解编程语言流行度排行，那么你应该听说过Scala，如果你还没有开始学习Scala，或者打算下个礼拜开始学的话，请先看看下面这篇文章，看看能不能改变你的想法。下面的内容为Programming In Scala 这本书的节选，到目前为止，国内好像还没引进，你可以从亚马逊上面购买http://booksites.artima.com/programming_in_scala (有国内的朋友翻译了其中的前11章，真是非常感谢)， 

   Scala是为你准备的吗？你必须自己看明白并做决定。除了伸展性之外，我们发现喜欢用Scala编程实际上还有很多理由。最重要的四个将在本节讨论的方面该是：兼容性，简短，高层级抽象和高级的静态类别。

 Scala是兼容的

<!--endfragment-->

   Scala不需要你从Java平台后退两步然后跳到Java语言前面去。它允许你在现存代码中加点儿东西——在你已有的东西上建设——因为它被设计成无缝地与Java实施互操作。Scala程序会被编译为JVM的字节码。它们的执行期性能通常与Java程序一致。Scala代码可以调用Java方法，访问Java字段，继承自Java类和实现Java接口。这些都不需要特别的语法，显式接口描述，或粘接代码。实际上，几乎所有Scala代码都极度依赖于Java库，而经常无须在程序员意识到这点。

   交互式操作的另一个方面是Scala极度重用了Java类型。Scala的Int类型代表了Java的原始整数类型int，Float代表了float，Boolean代表boolean，等等。Scala的数组被映射到Java数组。Scala同样重用了许多标准Java库类型。例如，Scala里的字串文本"abc"是java.lang.String，而抛出的异常必须是java.lang.Throwable的子类。

   Scala不仅重用了Java的类型，还把它们“打扮”得更漂亮。例如，Scala的字串支持类似于toInt和toFloat的方法，可以把字串转换成整数或者浮点数。因此你可以写str.toInt替代Integer.parseInt(str)。如何在不打破互操作性的基础上做到这点呢？Java的String类当然不会有toInt方法。实际上，Scala有一个解决这种高级库设计和互操作性不相和谐的通用方案。Scala可以让你定义隐式转换：implicit conversion，这常常用在类型失配，或者选用不存在的方法时。在上面的例子里，当在字串中寻找toInt方法时，Scala编译器会发现String类里没有这种方法，但它会发现一个把Java的String转换为Scala的RichString类的一个实例的隐式转换，里面定义了这么个方法。于是在执行toInt操作之前，转换被隐式应用。

    Scala代码同样可以由Java代码调用。有时这种情况要更加微妙，因为Scala是一种比Java更丰富的语言，有些Scala更先进的特性在它们能映射到Java前需要先被编码一下。第29章说明了其中的细节。

 Scala是简洁的

<!--endfragment-->

    Scala程序一般都很短。Scala程序员曾报告说与Java比起来代码行数可以减少到1/10。这有可能是个极限的例子。较保守的估计大概标准的Scala程序应该有Java写的同样的程序一半行数左右。更少的行数不仅意味着更少的打字工作，同样意味着更少的话在阅读和理解程序上的努力及更少的出错可能。许多因素在减少代码行上起了作用。

    首先，Scala的语法避免了一些束缚Java程序的固定写法。例如，Scala里的分号是可选的，且通常不写。Scala语法里还有很多其他的地方省略了东西。比方说，比较一下你在Java和Scala里是如何写类及构造函数的。在Java里，带有构造函数的类经常看上去是这个样子：

// 在Java里
class MyClass {
    private int index;
    private String name;
    public MyClass(int index, String name) {
        this.index = index;
        this.name = name;
    }
}

   在Scala里，你会写成这样：

class MyClass(index: Int, name: String)

   根据这段代码，Scala编译器将制造有两个私有成员变量的类，一个名为index的Int类型和一个叫做name的String类型，还有一个用这些变量作为参数获得初始值的构造函数。这个构造函数还将用作为参数传入的值初始化这两个成员变量。一句话，你实际拿到了与罗嗦得多的Java版本同样的功能。Scala类写起来更快，读起来更容易，最重要的是，比Java类更不容易犯错。

<!--endfragment-->

   有助于Scala的简洁易懂的另一个因素是它的类型推断。重复的类型信息可以被忽略，因此程序变得更有条理和易读。

   但或许减少代码最关键的是因为已经存在于你的库里而不需要写的代码。Scala给了你许多工具来定义强有力的库让你抓住并提炼出通用的行为。例如，库类的不同方面可以被分成若干特质，而这些有可以被灵活地混合在一起。或者，库方法可以用操作符参数化，从而让你有效地定义那些你自己控制的构造。这些构造组合在一起，就能够让库的定义既是高层级的又能灵活运用。

  Scala是高层级的

    程序员总是在和复杂性纠缠。为了高产出的编程，你必须明白你工作的代码。过度复杂的代码成了很多软件工程崩溃的原因。不幸的是，重要的软件往往有复杂的需求。这种复杂性不可避免；必须（由不受控）转为受控。

<!--endfragment-->

    Scala可以通过让你提升你设计和使用的接口的抽象级别来帮助你管理复杂性。例如，假设你有一个String变量name，你想弄清楚是否String包含一个大写字符。在Java里，你或许这么写：

// 在Java里
boolean nameHasUpperCase = false;
for (int i = 0; i < name.length(); ++i) {
    if (Character.isUpperCase(name.charAt(i))) {
        nameHasUpperCase = true;
        break;
    }
}

   在Scala里，你可以写成：

val nameHasUpperCase = name.exists(_.isUpperCase)

    Java代码把字串看作循环中逐字符步进的低层级实体。Scala代码把同样的字串当作能用论断：predicate查询的字符高层级序列。明显Scala代码更短并且——对训练有素的眼睛来说——比Java代码更容易懂。因此Scala代码在通盘复杂度预算上能极度地变轻。它也更少给你机会犯错。

    论断，_.isUpperCase，是一个Scala里面函数式文本的例子。它描述了带一个字符参量（用下划线字符代表）的函数，并测试其是否为大写字母。

    原则上，这种控制的抽象在Java中也是可能的。为此需要定义一个包含抽象功能的方法的接口。例如，如果你想支持对字串的查询，就应引入一个只有一个方法hasProperty的接口CharacterProperty：

// 在Java里
interface CharacterProperty {
    boolean hasProperty(char ch);
}

    然后你可以在Java里用这个接口格式一个方法exists：它带一个字串和一个CharacterProperty并返回真如果字串中有某个字符符合属性。然后你可以这样调用exists：

// 在Java里
exists(name, new CharacterProperty {
    boolean hasProperty(char ch) {
        return Character.isUpperCase(ch);
    }
});

    然而，所有这些真的感觉很重。重到实际上多数Java程序员都不会惹这个麻烦。他们会宁愿写个循环并漠视他们代码里复杂性的累加。另一方面，Scala里的函数式文本真地很轻量，于是就频繁被使用。随着对Scala的逐步了解，你会发现越来越多定义和使用你自己的控制抽象的机会。你将发现这能帮助避免代码重复并因此保持你的程序简短和清晰。

<!--endfragment-->

Scala是静态类型的

    静态类型系统认定变量和表达式与它们持有和计算的值的种类有关。Scala坚持作为一种具有非常先进的静态类型系统的语言。从Java那样的内嵌类型系统起步，能够让你使用泛型：generics参数化类型，用交集：intersection联合类型和用抽象类型：abstract type隐藏类型的细节。这些为建造和组织你自己的类型打下了坚实的基础，从而能够设计出即安全又能灵活使用的接口。<!--endfragment-->

    如果你喜欢动态语言如Perl，Python，Ruby或Groovy，你或许发现Scala把它的静态类型系统列为其优点之一有些奇怪。毕竟，没有静态类型系统已被引为动态语言的某些主要长处。绝大多数普遍的针对静态类型的论断都认为它们使得程序过度冗长，阻止程序员用他们希望的方式表达自己，并使软件系统动态改变的某些模式成为不可能。然而，这些论断经常针对的不是静态类型的思想，而是指责特定的那些被意识到太冗长或太不灵活的类型系统。例如，Alan Kay，Smalltalk语言的发明者，有一次评论：“我不是针对类型，而是不知道有哪个没有完痛的类型系统，所以我还是喜欢动态类型。”

    我们希望能在书里说服你，Scala的类型系统是远谈不上会变成“完痛”。实际上，它漂亮地说明了两个关于静态类型通常考虑的事情（的解决方案）：通过类型推断避免了赘言和通过模式匹配及一些新的编写和组织类型的办法获得了灵活性。把这些绊脚石搬掉后，静态类型系统的经典优越性将更被赏识。其中最重要的包括程序抽象的可检验属性，安全的重构，以及更好的文档。

可检验属性。静态类型系统可以保证消除某些运行时的错误。例如，可以保证这样的属性：布尔型不会与整数型相加；私有变量不会从类的外部被访问；函数带了正确个数的参数；只有字串可以被加到字串集之中。

    不过当前的静态类型系统还不能查到其他类型的错误。比方说，通常查不到无法终结的函数，数组越界，或除零错误。同样也查不到你的程序不符合式样书（假设有这么一份式样书）。静态类型系统因此被认为不很有用而被忽视。舆论认为既然这种类型系统只能发现简单错误，而单元测试能提供更广泛的覆盖，又为何自寻烦恼呢？我们认为这种论调不对头。尽管静态类型系统确实不能替代单元测试，但是却能减少用来照顾那些确需测试的属性的单元测试的数量。同样，单元测试也不能替代静态类型。总而言之，如Edsger Dijkstra所说，测试只能证明存在错误，而非不存在。因此，静态类型能给的保证或许很简单，但它们是无论多少测试都不能给的真正的保证。

安全的重构。静态类型系统提供了让你具有高度信心改动代码基础的安全网。试想一个对方法加入额外的参数的重构实例。在静态类型语言中，你可以完成修改，重编译你的系统并容易修改所有引起类型错误的代码行。一旦你完成了这些，你确信已经发现了所有需要修改的地方。对其他的简单重构，如改变方法名或把方法从一个类移到另一个，这种确信都有效。所有例子中静态类型检查会提供足够的确认，表明新系统和旧系统可以一样的工作。

文档。静态类型是被编译器检查过正确性的程序文档。不像普通的注释，类型标注永远都不会过期（至少如果包含它的源文件近期刚刚通过编译就不会）。更进一步说，编译器和集成开发环境可以利用类型标注提供更好的上下文帮助。举例来说，集成开发环境可以通过判定选中表达式的静态类型，找到类型的所有成员，并全部显示出来。

    虽然静态类型对程序文档来说通常很有用，当它们弄乱程序时，也会显得很讨厌。标准意义上来说，有用的文档是那些程序的读者不可能很容易地从程序中自己想出来的。在如下的方

 

           def f(x: String) = ...

    知道f的变量应该是String是有用的。另一方面，以下例子中两个标注至少有一个是讨厌的：

           val x: HashMap[Int, String] = new HashMap[Int, String]()

    很明显，x是以Int为键，String为值的HashMap这句话说一遍就够了；没必要同样的句子重复两遍。

    Scala有非常精于此道的类型推断系统，能让你省略几乎所有的通常被认为是讨厌的类型信息。在上例中，以下两个不太讨厌的替代品也能一样工作：

          val x = new HashMap[Int, String]()

          val x: Map[Int, String] = new HashMap()

     Scala里的类型推断可以走的很远。实际上，就算用户代码丝毫没有显式类型也不稀奇。因此，Scala编程经常看上去有点像是动态类型脚本语言写出来的程序。尤其显著表现在作为粘接已写完的库控件的客户应用代码上。而对库控件来说不是这么回事，因为它们常常用到相当精妙的类型去使其适于灵活使用的模式。这很自然。综上，构成可重用控件接口的成员的类型符号应该是显式给出的，因为它们构成了控件和它的使用者间契约的重要部分。

   不过，目前对于Scala来说，最大的问题是缺少一个优秀的IDE，真希望Eclipse 基金会能出手拯救这个局面！

 

 

评论

53 楼 alanwu 2009-08-24  

Scala有很多新特性，请大家多多关注

52 楼 白发红颜 2009-08-19  

看过一本书（不记得是哪本）说,　数组下标从０开始是因为这样对编译器的编写更方便一些.　后来就一直继承下来了.
[找到了,C专家编程第一章]

51 楼 iaimstar 2009-08-19  

徐风子说的不错

从自己来看，编程本身就是出于自己的兴趣，使用java工作也是生活所迫

一门语言的学习和个人兴趣有关，你对他感兴趣，就会琢磨和体会出更多

而这种学习和钻研会帮助在编程上面走的更远，谁敢保证学习一门看起来有趣的东西不会在更多的地方帮助你呢，或许可以你让你更有趣，好吧这是题外话

如果不停的有新的语言出现，并且向你推销他 的好处，即使不一定真的如此，但是足以体现人们不满足现状并尝试改善现有语言的信念和决心，如果精力不允许，选择个把感兴趣的学习，比较，不是可以更好了解作者的意图，更好的了解一门语言的优点和缺憾，还有什么比了解自己的爱人更甜美的事情呢？你不仅可以获得更多的思考，更好的体会矛盾的所在从而规避或者尝试解决，即使从工作这种枯燥的角度，也是有意义的。
何况，你在学习的是作者对语言的体会，计算机是可以解释世界的科学，学习语言，也可以更宽阔的看待世界。

因为电影每天都有新的而不看电影，那大可不必

50 楼 kraft 2009-08-19  

懒惰是程序员的特质，每个人对在哪儿懒惰的理解不一样，呵呵

49 楼 徐风子 2009-08-11  

关于TIOBE上scala和groovy的趋势我整理了一下。不会贴图，就发链接了。
http://iswind.iteye.com/admin/blogs/440083

48 楼 vwpolo 2009-08-11  

学一个新语言之前，了解为什么要学它，很重要。

47 楼 vwpolo 2009-08-11  

徐风子 写道

看看TIOBE现在世上有多少种语言，你就会发现以java语言的观点去看待一门新语言有多么狭隘了。
C++是一门伟大的语言，他扩充了C并完全兼容C语言，但也正因为完全兼容C语言，让他背上了很大的包袱。所以才有java语言的出现，而且java语言也不是横空出现的，其实他吸收的C++的很多成果，比如异常的概念，是从一篇关于C++的论文里出来的。总而言之，正因为java摆脱了C的束缚才能有如此的成就。
现在，如果语言要做突破性的进步，你还希望他和java最大程度的类似吗？如果完全相同，又何来进步，如果就像groovy那样，那是一门新语言还是一个javaPlus？（没有贬低groovy的意思，不过两种语言定位不同。）

程序员是个充满挑战的职业，你必须保有激情，你必须得学习，终生的学习（其实任何职业都是一样的）。如果一门新技术出来以后，你的第一念头是“靠！又有东西要学了。”而不是“看看东西又给我带了了什么突破性的进步？”。
无论如何，没有激情的工作是苦行，对公司是苦行，对你自己也是……

说的实在是太对了！！！  

46 楼 徐风子 2009-08-11  

cscript 写道

文章花了很大的篇幅说明静态类型的好处，但是静态类型的好处并不是scala独有的，效率、可检验属性、安全重构等等特性，哪家静态类型语言没有啊？都21世纪了，还把这些当成自己的特色。至于类型推理、匿名函数，新版的C#、C++都有这些特性，又不是scala的专利。

有人对scala的评价如下，我觉的很有道理：
C# 3.0 has a lot of the features that Scala has and they are much more palatable than the way Scala implements them. Why come up with a non-mainstream syntax for existing feature?

简单的说，这些语法糖大家都能想到，干嘛故意搞的和主流语法不一样？

文章花了很大时间介绍“静态语言”的好处，他确实是介绍静态语言的好处，没有说是scala独有的。至于为什么要介绍他，那是因为在很长时间里静态语言被误解了，总以为动态语言是未来的趋势，不知道你有没有，反正我在未学习scala之前是这样的。
一种新语言语法当然要和旧语言有所不同，不然何来提升？所谓的“主流”语法也不是一开始就这样的，也是在不断进化的。至于改进得对不对，我认为绝大多数都是对的，业界的很多大佬也都认可。你的看法呢，你可以学习了再说。

maddogfyg 写道

但他有些地方过头了,比如元组tuple(就是可以放不同类型的元素的list),下标居然从1开始,而且是_1,_2这样,他们的解释是:"因为对于拥有静态类型元组的其他语言，如Haskell和ML，从1开始是传统的设定。"我狂吐血!tnnd你总的和list的访问方式一致吧,起始下标一个是0,一个是1,还让不让人活了

tuple下标从1开始我感觉没啥问题，倒是array为什么不从1开始？估计还是为了和java兼容吧。不然java里面a[0]，变成scala里面的a(1)不让人奔溃才怪。

maddogfyg 写道

就我而言,以后如果编程时遇到这两种列表中特定位置取值,肯定要多想一想下标的问题,这就超出了语法的问题了,是真正让人感觉无法接受的.

会遇到吗？tuple不是数组，你把他看成一个临时对象更合理一点。_1、_2看成他的属性，你把tuple当成数组才让人无法接受。

45 楼 徐风子 2009-08-11  

看看TIOBE现在世上有多少种语言，你就会发现以java语言的观点去看待一门新语言有多么狭隘了。
C++是一门伟大的语言，他扩充了C并完全兼容C语言，但也正因为完全兼容C语言，让他背上了很大的包袱。所以才有java语言的出现，而且java语言也不是横空出现的，其实他吸收的C++的很多成果，比如异常的概念，是从一篇关于C++的论文里出来的。总而言之，正因为java摆脱了C的束缚才能有如此的成就。
现在，如果语言要做突破性的进步，你还希望他和java最大程度的类似吗？如果完全相同，又何来进步，如果就像groovy那样，那是一门新语言还是一个javaPlus？（没有贬低groovy的意思，不过两种语言定位不同。）

程序员是个充满挑战的职业，你必须保有激情，你必须得学习，终生的学习（其实任何职业都是一样的）。如果一门新技术出来以后，你的第一念头是“靠！又有东西要学了。”而不是“看看东西又给我带了了什么突破性的进步？”。
无论如何，没有激情的工作是苦行，对公司是苦行，对你自己也是……

44 楼 徐风子 2009-08-11  

chenlb 写道

这篇文章不知那里看过.

楼主的文章是从《programing in scala》 里面翻译出来的。

43 楼 chenlb 2009-08-09  

这篇文章不知那里看过.

42 楼 bneliao 2009-08-08  

顶楼上，scala在与Java的相似的语法上并没有很大的不同，

scala引进fp，促使oo和函数式编程做合适的融合，新引进fp的语法，和mixin的与Java不同的继承初始化顺序才比较难理解。

41 楼 ravenex 2009-08-08  

cscript 写道

引用

对于不愿学习新东西的人来说，所有新特性都是“生僻”的，任何转向都是不容易的。

这句话的前提是错误的，因为scala的很多特性根本就不是新东西。C#、Scala都有数组、模板，但是C#采用的语法和大部分已有的编程语言是相同的，所以我觉得C#比scala简单，scala的数组、模板有什么本质提高的地方吗？

引用

举个例子来说，拿C# 3.0和C# 1.0比较，也可以套用同样的说辞。

这个例子举的不准，新版本C#有模板、类型推理等C# 1.0没有的特性，相对于C# 1.0来说是有意义的创新。但是，C#1.0相对于Java来说，把synchornized改为lock、super改为base的行为就是属于典型的“为了不同而不同”。

Java在改造C++的时候把惯用的base class改称super class，C#只是更多的跟随了C++的“传统”。Java把protected的语义改得跟C++不同就是典型的“为了不同而不同”。
C的祖先之一，BCPL，里面还是用$(和$)而不是花括号来界定块的，后来的B语言怎么就“为不同而不同”用了花括号呢？还顺带影响了C、C++、Java、C#、JavaScript、ActionScript……在这问题上较真本来就很难有多少收获

另外C#的泛型不是模板，至少不是C++意义上的模板。

cscript 写道

引用

人家几十年前 Lisp 里面就用 fst 和 snd 了，源远流长，给你改成 0 才不妥呢。

源远流长又咋样，能说明一个下标从1开始一个下标从0开始是合理的吗, MIT源远流长的6.001不是被Python取代了吗？再说C语言的历史不比lisp短多少。

计算机科学的历史本身就不长，从这点出发说C的历史没比LISP短多少也没错。但LISP（1958）可是跟FORTRAN（1957）一档的老语言，跟C（1972）这么年轻的语言比……
大大们要是学Eiffel（1985）的话肯定会觉得它的设计者太蛋疼了，用语跟现在常用的OOP用语几乎完全不同。但那可是OOP语言的先驱之一，跟后来成为主流的C++（1983）同辈。它没能成为所谓“主流语言”，从现在的角度看反而是另类了。但要说到契约编程、CQS（command-query separation）那都是Eiffel的特征。如果知道command和query是Eiffel里feature两个类别，而feature就是Eiffel里“方法”的叫法，CQS这个名词就好理解了。

Scala最创新的地方是OO与FP在类型系统层次上的融合。还没有什么别的语言能做到这么深度的融合（例如Fan的作者就宁可不做这么彻底）。Odersky在设计Scala的时候已经是尽量少跟Java不同了……

反正语法再怎么不同，只要概念相似就不难学习。语法差异就忍忍吧。连从C迁移到C++都要痛苦很久，还跑出POD类型之类的概念，何况从Java到Scala呢。

40 楼 jonathan_zz 2009-08-08  

cscript 写道

引用

人家几十年前 Lisp 里面就用 fst 和 snd 了，源远流长，给你改成 0 才不妥呢。

源远流长又咋样，能说明一个下标从1开始一个下标从0开始是合理的吗, MIT源远流长的6.001不是被Python取代了吗？再说C语言的历史不比lisp短多少。

取代？去查查清楚再说

39 楼 night_stalker 2009-08-07  

cscript 写道

引用

人家几十年前 Lisp 里面就用 fst 和 snd 了，源远流长，给你改成 0 才不妥呢。

源远流长又咋样，能说明一个下标从1开始一个下标从0开始是合理的吗, MIT源远流长的6.001不是被Python取代了吗？再说C语言的历史不比lisp短多少。

tuple 取元素不是下标 …… tuple 还作为函数的参数而存在，如：

def f (param1: Int, param2: Int) = ...

这时如果取第 1 个参数 …… 硬要说成取第 0 个参数？

而数组、list 下标从 0 开始有多根深蒂固就不提了，如果从 1 开始世界要大乱了 ……

不过你这么有想法，可以创建一个 scala 的 branch，把它们全部统一：
将 Tuple1 到 Tuple22，改成 Tuple0 到 Tuple21，把 Product1 到 Product22 全部改成 Product0 到 Product21，提取元素的方法通通从 _0 开始 ……

如果赞同的人一大堆，很快就能 merge 进去了，祝您成功！

==============

ps1： 其实 ._1 ._2 用得很少 …… 用模式匹配，从 0 或者 1 开始算都没关系。

val t = (2, 3)
val (a, b) = t      // a=2, b=3
val l = List(1,2)
val List(c, d) = l  // c=1, d=2

ps2：有些不同的东西是受商业因素影响的：要宣传自己多牛，就得多造些名词，以免一下就被人发现这个东西几十年前就在 lisp 和 smalltalk 中出现过了。

ps3：类型推断不是静态语言的专利。Netbeans 的 ruby 插件已经可以利用类型推断来找 bug 了。

38 楼 hax 2009-08-07  

cscript 写道

引用

对于不愿学习新东西的人来说，所有新特性都是“生僻”的，任何转向都是不容易的。

这句话的前提是错误的，因为scala的很多特性根本就不是新东西。C#、Scala都有数组、模板，但是C#采用的语法和大部分已有的编程语言是相同的，所以我觉得C#比scala简单，scala的数组、模板有什么本质提高的地方吗？

引用

举个例子来说，拿C# 3.0和C# 1.0比较，也可以套用同样的说辞。

这个例子举的不准，新版本C#有模板、类型推理等C# 1.0没有的特性，相对于C# 1.0来说是有意义的创新。但是，C#1.0相对于Java来说，把synchornized改为lock、super改为base的行为就是属于典型的“为了不同而不同”。

你还是没搞清楚要点。

新东西？哪个语言是完全的新东西？C#那些东西还不是跟别人学的嘛。
我针对的是那些固守java的人。你拿C#来搅合，根本就是牛头不对马嘴。

“C#采用的语法和大部分已有的编程语言是相同的”，拜托，什么是“大部分已有的编程语言”？难道C#比scala更接近java？还是更接近ruby、python、groovy、lisp、haskell、javascript？你要是说C# 3.0比scala更接近C# 1.0，那就算了。。。

最后，其实我挺喜欢C#把synchornized改为lock，因为前者又臭又长我老是要拼错。对于我，这就是一个改进。

37 楼 icefishc 2009-08-07  

cscript 写道

引用

人家几十年前 Lisp 里面就用 fst 和 snd 了，源远流长，给你改成 0 才不妥呢。

源远流长又咋样，能说明一个下标从1开始一个下标从0开始是合理的吗, MIT源远流长的6.001不是被Python取代了吗？再说C语言的历史不比lisp短多少。

不要太激动了。：）   很难说从0开始和从1开始哪个更合理， 我想设计成这样主要也是考虑程序员的习惯。在大多数主流语言中list都是从0开始。 而支持tupe的语言基本tupe都是从1开始。  这个是符合习惯的。

至于ＭＩＴ的例子并不合适。　　MIT用python代替scheme 不纯在是否符合习惯的问题。　python优于scheme的地方主要是python被使用的更多　不管是在别的课程中还是在现实世界中都是这样。

36 楼 key232323 2009-08-07  

哎，感叹下……
文档文章看了不少，研究编码做得不多

很多情况下都人云亦云了——

闭关一段时间，牢固下基础。尝试学习研究下这些新技术。

35 楼 mysyche 2009-08-07  

飘过，看过，留言过。

34 楼 maddogfyg 2009-08-07  

yiding_he 写道

我觉得我们可以以更积极的眼光去看 Scala：

1、语法问题。如果你舍得花时间学 Python、Ruby，那你也可以舍得花时间学 Scala，而且时间肯定比这两个要少，因为有现成的你已经非常熟悉的类库可用；

2、Scala 和 Groovy，一个是静态的，一个是动态的，二者都是 Java 很好的补充。

3、我觉得类型推断是亮点。

我也是非常喜欢类型推断，scala到底能不能流行不好说，但我想它起码能让很多人思索，到底动态类型真有那么好吗？安德尔斯的一句话对我影响很大：“你告诉编译器的越多，编译器能为你做的就越多”，我一直近于固执的认为，静态语言是做基础架构的必然选择，看看c#和scala，其实静态语言的效率可以提升到相当高的水平。

还有个问题就是框架的应用，现在大多数程序员都是骑在别人的轮子上，自己写的代码数量已经比以前少的多了，用动态语言的优势已经没有以前那么大了，而且静态语言的框架性能可以(我不是说一定，是说可以)做的比动态的好不少。

现在都推崇ruby、python，很大程度上不是java语言本身的问题，而是业界把java这个体系搞得很高端很复杂，随着java渐渐轻量化以及c#、scala这些语言越来越流行，静态语言的优点慢慢会被重新发现的。