分享 如何掌握程序语言 王垠写的比较不错的文章

zhenjunluo · 2012年09月10日 · 最后由 DouO 回复于 2012年09月21日 · 17666 次阅读

学习程序语言是每个程序员的必经之路。可是这个世界上有太多的程序语言,每一种都号称具有最新的“特性”。所以程序员的苦恼就在于总是需要学习各种稀奇古怪的语言,而且必须紧跟“潮流”,否则就怕被时代所淘汰。

作为一个程序语言的研究者,我深深的知道这种心理产生的根源。程序语言里面其实有着非常简单,永恒不变的原理。看到了它们,就可以在很短的时间之内就能学会并且开始使用任何新的语言,而不是花费很多功夫去学习一个又一个的语言。

对程序语言的各种误解

学习程序语言的人,经常会出现以下几种心理,以至于他们会觉得有学不完的东西,或者走上错误的道路。以下我把这些心理简要分析一下。

  1. 程序语言无用论。这是国内大学计算机系的教育常见的错误。教授们常常对学生灌输:“用什么程序语言不重要,重要的是算法。”而其实,程序语言却是比算法更加精髓的东西。任何算法以及它的复杂度分析,都是相对于某种计算模型,而程序语言就是描述这种计算模型的符号系统。算法必须用某种语言表述出来,通常算法设计者使用伪码,这其实是不严谨的,容易出现推理漏洞。算法设计再好,如果不懂得程序语言的原理,也不可能高效的实现。即使实现了,也可能会在模块化和可扩展性上面有很大问题。某些算法专家或者数学家写出来的程序极其幼稚,就是因为他们忽视了程序语言的重要性。

  2. 追求“新语言”。基本的哲学告诉我们,新出现的事物并不一定是“新事物”,它们有可能是历史的倒退。事实证明,新出现的语言,可能还不如早就存在的。其 实,现代语言的多少“新概念”不存在于最老的一些语言里呢?程序语言就像商品,每一家都为了拉拢程序员作广告,而它们绝大多数的设计都可能是肤浅而短命 的。如果你看不透这些东西的设计,就会被它们蒙蔽住。很多语言设计者其实并不真的懂得程序语言设计的原理,所以常常在设计中重复前人的错误。但是为了推销 自己的语言和系统,他们必须夸夸其谈,进行宗教式的宣传。

  3. “存在即是合理”。记得某人说过:“不能带来新的思维方式的语言,是没有必要存在的。”他说的是相当正确的。世界上有这么多的语言,有哪些带来了新的思维 方式呢?其实非常少。绝大部分的语言给世界带来的其实是混乱。有人可能反驳说:“你怎么能说 A 语言没必要存在?我要用的那个库 L,别的语言不支持,只能用 A。”但是注意,他说的是存在的“必要性”。如果你把存在的“事实”作为存在的“必要性”,那就逻辑错乱了。就像如果二战时我们没能打败希特勒,现在都做 了他的奴隶,然后你就说:“希特勒应该存在,因为他养活了我们。”你的逻辑显然有问题,因为如果历史走了另外一条路(即希特勒不存在),我们会过上自由幸 福的生活,所以希特勒不应该存在。对比一个东西存在与不存在的两种可能的后果,然后做出判断,这才是正确的逻辑。按照这样的推理,如果设计糟糕的 A 语言不存在,那么设计更好的 B 语言很有可能就会得到更多的支持,从而实现甚至超越 L 库的功能。

  4. 追求“新特性”。程序语言的设计者总是喜欢“发明”新的名词,喜欢炒作。普通程序员往往看不到,大部分这些“新概念”其实徒有高深而时髦的外表,却没有实 质的内涵。常常是刚学会一个语言 A,又来了另一个语言 B,说它有一个叫 XYZ 的新特性。于是你又开始学习 B,如此继续。在内行人看来,这些所谓的“新特性”绝大部分都是新瓶装老酒。很多人写论文喜欢起这样的标题:《XYZ:A Novel Method for ...》。这造成了概念的爆炸,却没有实质的进步。

  5. 追求“小窍门”。很多编程书喜欢卖弄一些小窍门,教你如何让程序显得“短小”。比如它们会跟你讲 "(i++) - (++i)" 应该得到什么结果;或者追究运算符的优先级,说这样可以少打括号;要不就是告诉你“if 后面如果只有一行代码就可以不加花括号”,等等。殊不知这些小窍门,其实大部分都是程序语言设计的败笔。它们带来的不是清晰的思路,而是是逻辑的混乱和认 知的负担。比如 C 语言的 ++ 运算符,它的出现是因为 C 语言设计者们当初用的计算机内存小的可怜,而 "i++" 显然比 "i=i+1" 少 2 个字符,所以他们觉得可以节省一些空间。现在我们再也不缺那点内存,可是 ++ 运算符带来的混乱和迷惑,却流传了下来。现在最新的一些语言,也喜欢耍这种语法上的小把戏。如果你追求这些小窍门,往往就抓不住精髓。

  6. 针对“专门领域”。很多语言没有新的东西,为了占据一方土地,就号称自己适合某种特定的任务,比如文本处理,数据库查询,WEB 编程,游戏设计,并行计算。但是我们真的需要不同的语言来干这些事情吗?其实绝大部分这些事情都能用同一种通用语言来解决,或者在已有语言的基础上做很小的改动。只不过由于各种政治和商业原因,不同的语言被设计用来占领市场。就学习而言,它们其实是无关紧要的,而它们带来的“学习负担”,其实差不多掩盖了它们带来的好处。其实从一些设计良好的通用语言,你可以学会所有这些“专用语言”的精髓,而不用专门去学它们。

  7. 宗教信仰。很多人对程序语言有宗教信仰。这跟人们对操作系统有宗教信仰很类似。其实如果你了解程序语言的本质,就会发现其实完全没必要跟人争论一些事情。某个语言有缺点,应该可以直接说出来,却被很多人忌讳,因为指出缺点总是招来争论和憎恨。这原因也许在于程序语言的设计不是科学,它类似于圣经,它没法被“证伪”。没有任何实验可以一下子断定那种语言是对的,那种是错的。所以虽然你觉得自己有理,却很难让人信服。没有人会去争论哪家的汉堡更好,却有很多人争论那种语言更好。因为很多人把程序语言当成自己的神,如果你批评我的语言,你就是亵渎我的神。解决的办法也许是,不要把自己正在用的语言看得太重要。你现在认为是对的东西,也许不久就会被你认为是错的,反之亦然。

如何掌握程序语言

看到了一些常见的错误心理,那么我们来谈一下什么样的思维方式会更加容易的掌握程序语言。

  1. 专注于“精华”和“原理”。就像所有的科学一样,程序语言最精华的原理其实只有很少数几个,它们却可以被用来构造出许许多多纷繁复杂的概念。但是人们往往 忽视了简单原理的重要性,匆匆看过之后就去追求最新的,复杂的概念。他们却没有注意到,绝大部分最新的概念其实都可以用最简单的那些概念组合而成。而对基 本概念的一知半解,导致了他们看不清那些复杂概念的实质。比如这些概念里面很重要的一个就是递归。国内很多学生对递归的理解只停留于汉诺塔这样的程序,而 对递归的效率也有很大的误解,认为递归没有循环来得高效。而其实递归比循环表达能力强很多,而且效率几乎一样。有些程序比如解释器,不用递归的话基本没法完成。

  2. 实现一个程序语言。学习使用一个工具的最好的方式就是制造它,所以学习程序语言的最好方式就是实现一个程序语言。这并不需要一个完整的编译器,而只需要写 一些简单的解释器,实现最基本的功能。之后你就会发现,所有语言的新特性你都大概知道可以如何实现,而不只停留在使用者的水平。实现程序语言最迅速的方式就是使用一种像 Scheme 这样代码可以被作为数据的语言。它能让你很快的写出新的语言的解释器。我的 GitHub 里面有一些我写的解释器的例子(比如这个短小的代码实现了 Haskell 的 lazy 语义)。

几种常见风格的语言

下面我简要的说一下几种常见风格的语言以及它们的问题。

  1. 面向对象语言

事实说明,“面向对象”这整个概念基本是错误的。它的风靡是因为当初的“软件危机”(天知道是不是真的存在这危机)。设计的初衷是让“界面”和“实现”分离,从而使得下层实现的改动不影响上层的功能。可是大部分面向对象语言的设计都遵循一个根本错误的原则:“所有的东西 都是对象(Everything is an object)。”以至于所有的函数都必须放在所谓的“对象”里面,而不能直接被作为参数或者变量传递。这导致很多时候需要使用繁琐的设计模式 (design patterns) 来达到甚至对于 C 语言都直接了当的事情。而其实“界面”和“实现”的分离,并不需要把所有函数都放进对象里。另外的一些概念,比如继承,重载,其实带来的问题比它们解决的 还要多。

“面向对象方法”的过度使用,已经开始引起对整个业界的负面作用。很多公司里的程序员喜欢生搬硬套一些不必要的设计模式,其实什么好事情也没干,只是使得程序冗长难懂。

那 么如何看待具备高阶函数的面向对象语言,比如 Python, JavaScript, Ruby, Scala? 当然有了高阶函数,你可以直截了当的表示很多东西,而不需要使用设计模式。但是由于设计模式思想的流毒,一些程序员居然在这些不需要设计模式的语言里也采用繁琐的设计模式,让人哭笑不得。所以在学习的时候,最好不要用这些语言,以免受到不必要的干扰。到时候必要的时候再回来使用它们,就可以取其精华,去其糟粕。

  1. 低级过程式语言

那么是否 C 这样的“低级语言”就会好一些呢?其实也不是。很多人推崇 C,因为它可以让人接近“底层”,也就是接近机器的表示,这样就意味着它速度快。这里其实有三个问题:

1) 接近“底层”是否是好事? 2)“速度快的语言”是什么意思? 3) 接近底层的语言是否一定速度快?

对于第一个问题,答案是否定的。其实编程最重要的思想是高层的语义 (semantics)。语义构成了人关心的问题以及解决它们的算法。而具体的实现 (implementation),比如一个整数用几个字节表示,虽然还是重要,但却不是至关重要的。如果把实现作为学习的主要目标,就本末倒置了。因为 实现是可以改变的,而它们所表达的本质却不会变。所以很多人发现自己学会的东西,过不了多久就“过时”了。那就是因为他们学习的不是本质,而只是具体的实 现。

其次,谈语言的“速度”,其实是一句空话。语言只负责描述一个程序,而程序运行的速度,其实绝大部分不取决于语言。它主要取决于 1) 算法 和 2) 编译器的质量。编译器和语言基本是两码事。同一个语言可以有很多不同的编译器实现,每个编译器生成的代码质量都可能不同,所以你没法说“A 语言比 B 语言快”。你只能说“A 语言的 X 编译器生成的代码,比 B 语言的 Y 编译器生成的代码高效”。这几乎等于什么也没说,因为 B 语言可能会有别的编译器,使得它生成更快的代码。

我举个例子吧。在历史上,Lisp 语言享有“龟速”的美名。有人说“Lisp 程序员知道每个东西的值,却不知道任何事情的代价”,讲的就是这个事情。但这已经是很久远的事情了,现代的 Lisp 系统能编译出非常高效的代码。比如商业的 Chez Scheme 编译器,能在 5 秒钟之内编译它自己,编译生成的目标代码非常高效。它可以直接把 Scheme 程序编译到多种处理器的机器指令,而不通过任何第三方软件。它内部的一些算法,其实比开源的 LLVM 之类的先进很多。

另外一些 函数式语言也能生成高效的代码,比如 OCaml。在一次程序语言暑期班上,Cornell 的 Robert Constable 教授讲了一个故事,说是他们用 OCaml 重新实现了一个系统,结果发现 OCaml 的实现比原来的 C 语言实现快了 50 倍。经过 C 语言的那个小组对算法多次的优化,OCaml 的版本还是快好几倍。这里的原因其实在于两方面。第一是因为函数式语言把程序员从底层细节中解脱出来,让他们能够迅速的实现和修改自己的想法,所以他们能 够迅速的找到更好的算法。第二是因为 OCaml 有高效的编译器实现,使得它能生成很好的代码。

从上面的例子,你也许已经可以看出,其实接近底层的语言不一定速度就快。因为编译器这种东西其实可以有很高级的“智能”,甚至可以超越任何人能做到的底层优化。但是编译器还没有发展到可以代替人来制造算法的地步。所以现在人需要做的,其实只是设计和优化自己的高层算法。

  1. 高级过程式语言

很早的时候,国内计算机系学生的第一门编程课都是 Pascal。Pascal 是很不错的语言,可是很多人当时都没有意识到。上大学的时候,我的 Pascal 老师对我们说:“我们学校的教学太落后了。别的学校都开始教 C 或者 C++ 了,我们还在教 Pascal。”现在真正理解了程序语言的设计原理以后我才真正的感觉到,原来 Pascal 是比 C 和 C++ 设计更好的语言。它不但把人从底层细节里解脱出来,没有面向对象的思维枷锁,而且有一些很好的设计,比如强类型检查,嵌套函数定义等等。可是计算机的世界 真是谬论横行,有些人批评 Pascal,把优点都说成是缺点。比如 Brain Kernighan 的这篇《Why Pascal is Not My Favorite Programming Language》,现在看来真是谬误百出。Pascal 现在已经几乎没有人用了。这并不很可惜,因为它被错怪的“缺点”其实已经被正名,并且出现在当今最流行的一些语言里:Java, Python, C#, ……

  1. 函数式语言

函数式语言相对来说是当今最好的设计,因为它们不但让人专注于算法和对问题的解决,而且没有面向对象语言那些思维的限制。但是需要注意的是并不是每个函数式语言的特性都是好东西。它们的支持者们经常把缺点也说成是优点,结果你其实还是被挂上一些不必要的枷锁。比如 OCaml 和 SML,因为它们的类型系统里面有很多不成熟的设计,导致你需要记住太多不必要的规则。

  1. 逻辑式语言

逻辑式语言(比如 Prolog)是一种超越函数式语言的新的思想,所以需要一些特殊的训练。逻辑式语言写的程序,是能“反向运行”的。普通程序语言写的程序,如果你给它一个输入,它会给你一个输出。但是逻辑式语言很特别,如果你给它一个输出,它可以反过来给你所有可能的输入。其实通过很简单的方法,可以不费力气的把程序从函数式转换成逻辑式的。但是逻辑式语言一般要在“pure”的情况下(也就是没有复杂的赋值操作)才能反向运行。所以学习逻辑式语言最好是从函数式语言开始,在理解了递归,模式匹配等基本的函数式编程技巧之后再来看 Prolog,就会发现逻辑式编程简单了很多。

从何开始

可是学习编程总要从某种语言开始。那么哪种语言呢?就我的观点,首先可以从 Scheme 入门,然后学习一些 Haskell (但不是全部),之后其它的也就触类旁通了。你并不需要学习它们的所有细枝末节,而只需要学习最精华的部分。所有剩余的细节,会在实际使用中很容易的被填补上。现在我推荐几本比较好的书。

《The Little Schemer》(TLS):我觉得 Dan Friedman 的 The Little Schemer 是目前最好,最精华的编程入门教材。这本书很薄,很精辟。它的前身叫《The Little Lisper》。很多资深的程序语言专家都是从这本书学会了 Lisp。虽然它叫“The Little Schemer”,但它并不使用 Scheme 所有的功能,而是忽略了 Scheme 的一些毛病,直接进入最关键的主题:递归和它的基本原则。

《Structure and Interpretation of Computer Programs》(SICP):The Little Schemer 其实是比较难的读物,所以我建议把它作为下一步精通的读物。SICP 比较适合作为第一本教材。但是我需要提醒的是,你最多只需要看完前三章。因为从第四章开始,作者开始实现一个 Scheme 解释器,但是作者的实现并不是最好的方式。你可以从别的地方更好的学到这些东西。不过也许你可以看完 SICP 第一章之后就可以开始看 TLS。

《A Gentle Introduction to Haskell》:对于 Haskell,我最开头看的是 A Gentle Introduction to Haskell,因为它特别短小。当时我已经会了 Scheme,所以不需要再学习基本的函数式语言的东西。我从这个文档学到的只不过是 Haskell 对于类型和模式匹配的概念。

过度到面向对象语言

那么如果从函数式语言入门,如何过渡到面向对象语言呢?毕竟大部分的公司用的是面向对象语言。如果你真的学会了函数式语言,就会发现面向对象语言已经易如反掌。函数式语言的设计比面向对象语言简单和强大很多,而且几乎所有的函数式语言教材(比如 SICP)都会教你如何实现一个面向对象系统。你会深刻的看到面向对象的本质以及它存在的问题,所以你会很容易的搞清楚怎么写面向对象的程序,并且会发现 一些窍门来避开它们的局限。你会发现,即使在实际的工作中必须使用面向对象语言,也可以避免面向对象的思维方式,因为面向对象的思想带来的大部分是混乱和冗余。

深入本质和底层

那么是不是完全不需要学习底层呢?当然不是。但是一开头就学习底层硬件,就会被纷繁复杂的硬件设计蒙蔽头脑,看不清楚本质上简单的原理。在学会高层的语言之后,可以进行“语义学”和“编译原理”的学习。

简言之,语义学 (semantics) 就是研究程序的符号表示如何对机器产生“意义”,通常语义学的学习包含 lambda calculus 和各种解释器的实现。编译原理 (compilation) 就是研究如何把高级语言翻译成低级的机器指令。编译原理其实包含了计算机的组成原理,比如二进制的构造和算术,处理器的结构,内存寻址等等。但是结合了语义学和编译原理来学习这些东西,会事半功倍。因为你会直观的看到为什么现在的计算机系统会设计成这个样子:为什么处理器里面有寄存器 (register),为什么需要堆栈 (stack),为什么需要堆 (heap),它们的本质是什么。这些甚至是很多硬件设计者都不明白的问题,所以它们的硬件里经常含有一些没必要的东西。因为他们不理解语义,所以经常不明白他们的硬件到底需要哪些部件和指令。但是从高层语义来解释它们,就会揭示出它们的本质,从而可以让你明白如何设计出更加优雅和高效的硬件。

这就是为什么一些程序语言专家后来也开始设计硬件。比如 Haskell 的创始人之一 Lennart Augustsson 后来设计了 BlueSpec,一种高级的硬件描述语言,可以 100% 的合成 (synthesis) 为硬件电路。Scheme 也被广泛的使用在硬件设计中,比如 Motorola, Cisco 和曾经的 Transmeta,它们的芯片设计里面含有很多 Scheme 程序。

这基本上就是我对学习程序语言的初步建议。以后可能会就其中一些内容进行更加详细的阐述。

原文连接 http://blog.sina.com.cn/s/blog_5d90e82f01015271.html

对简单的东西多加思考,取其精髓,很受启发

这里鼓励全文转载吗?@huacnlee

#1 楼 @zhenjunluo

讲的很好,但是感觉过于学术些。真正做起项目来开发的效率是非常重要的,而这里语言,框架以及其周边的生态系统是非常重要的考虑。

比如,做 Web 相关的项目,Rails 就是非常好的 DSL 而且有成熟的生态系统。函数式的 Clojure 也可以做而且有很多强大的功能,但是成熟性相对差些。Haskell 就更是这样。可以用 Rails 迅速 build prototypes 并加功能。而当项目趋向成熟的时候可以考虑加入其他语言为特定的功能服务。

还有,与其纠结与语言,其实更重要的是编程的模式。面向对象,函数式这些并不是语言的特性,而是编程的模式。最近的多模式编程语言比如 Clojure, Scala 的兴起就是这个的体现。Ruby 也可以用做函数式语言来用,只是没有 Ocaml 那么自如和方便

转载贴链接就好了。

#3 楼 @knwang 与其纠结与语言,其实更重要的是编程的模式。面向对象,函数式这些并不是语言的特性,而是编程的模式。最近的多模式编程语言比如 Clojure, Scala 的兴起就是这个的体现。

你这句话前后正好矛盾。 王垠说得好啊,语言还是很重要的

#5 楼 @jjym

不矛盾。编程模式比语言重要。我不一定要改变语言来改变编程模式,Ruby, C, Java 甚至 BASIC 都可以做函数式的编程,只是越新的语言越是鼓励这一点。

作者确实说的很好,语言是很重要。但是开发效率,工具,生态系统,平台完备,团队技能等等都很重要,开发一个项目的时候多要考虑。比如 Web 项目的开发,Ruby 系统有很大的优势,而我完全可以在实现上放弃面向对象而用函数式的开发模式来实现 immutability 和复杂的数据类型来鼓励行为至上。

软件工程的一个重要原则是推迟大风险的决定,所以在实践项目中非主流语言的引入很少出现在项目初期 -非主流数据库的选择也往往是这样。

又是王垠,在我刚开始用 Emacs 那会儿,搜索中文 Emacs 资料,时常会看到这个名字。

#6 楼 @knwang

软件工程的一个重要原则是推迟大风险的决定

难道软件工程是你发明的?为啥从没有人这么说过...

我觉得 rails 中,尤其是 大把的 gem 中,很多都是 新瓶装老酒, 这是一个很严重的问题。屁大点功能,就是一个 gem, 这对于 Rails 初学者很不利。

来来回回 gem 之间的依赖,组合,再加上彼此之间的冲突,所花的时间,其实有时候远比自己来实现花的功夫多。当然,我指的是那些 小gem, 当然有很多很不错的 gem, 功能强大,经过严格测试,不过不太少了。

#9 楼 @zw963 做的越小其实越容易避免冲突,这样更能组件化(当然不是太极端的那种小)

靠,有关递归的描述,我前几天刚发过一个贴,讨论。

很明显,我之前就属于那种:

对递归的效率也有很大的误解,认为递归没有循环来得高效。

#10 楼 @jjym

耐不住数量大,写个博客,你用上 100 个 gem, 我不信你不冲突。

#12 楼 @zw963 首先实际来看不会用到 100 个,做的这么小的 gem 基本也没啥用。 作为一个组件就是要功能上尽量独立,然后把东西集成在一起。比如 rails 的哪些,要替换也很方便。 所以我写个博客用 20,或 30 个 gem。首先我基本不会选择功能一样的 gem,其次功能不一样的 gem 基本不会有冲突,即使有冲突的我可以把他去掉

#6 楼 @knwang

说得太好了,认可~

#4 楼 @Rei 嗯,下面有连接!但只是一个连接的话,总感觉缺少点什么,呵呵

#3 楼 @knwang 的却开发效率和完成项目很重要,很赞同你讲的!但很多新的技术的出现,使得我们总在后面追赶,刚学会一样东西,又要学另外一样东西,而且新技术的出现,总会出现一些新的术语和新的描绘,本来有些说的就是同一个东西,也花费了很多时间去想去理解它到底是说回什么事,总体来说就是会,但是运用不那么自如,要跟得上时代,我觉得要脱离那种总是处在学习的阶段,而后才会有所作为。不知楼主在学习和掌握一门新的技术时,有什么心得体会?

#11 楼 @zw963 递归程序很不容易写对,以前也写过一些递归的算法,但时间长了,感觉又忘记了!我遇到最多的麻烦就是递归终止条件的判断,很容易出错。

#9 楼 @zw963

Gem 不需要用太多。很多的 Gem 写出来后作者会考虑照顾到各种各样的 use case 导致 Gem 本身复杂庞大,对于自己的应用很多都还不如自己写

#11 楼 @zw963

递归的高效是对程序员脑的高效 而除非是非常独特的项目,针对人脑的优化》针对系统的优化

系统资源不够了可以向云扔钱 程序员不够了或者做不下去了。。看看论坛里的招人贴就知道了

#16 楼 @zhenjunluo

首先要看你学技术的动机是什么?是从学习中本身得到快乐,还是技术只是你能进行创造的手段?你是对成为顶级程序员/技术高手无比向往,还是希望来学会技术作项目,创业?

如果你对技术本身非常热爱,那么建议好好搭好基础,多读一些经典的文献。很多看上去是新的技术,其实都早就存在了。大的看比如 Erlang, Prolog 这些早就出现了,Lisp 更是历史久远的不行,只是近期 Internet,并行计算和 big data 兴起让 Erlang, Prolog 这些技术再次受关注。小的看 Web 和 Rails 社区近期的变化 - 客户端到服务器到客户端,J2EE 到 Rails 的精简框架到 Object Design 再次受关注,都已经在软件历史上来来回回几次了。如果你去读些老文献,会发现我们只不过在从新解决前人解决过的问题而已

如果你的目的是创找和创业,那么答案更简单,立刻开始搭建你的产品。精通 能让你快速开发的工具,速度决定一切因为你的前十个产品估计九个或更多会失败的。迅速找到有前景的项目压倒一切。一旦市场被证明而你的应用开始成长,你自然会面对一个一个的技术挑战,那时候在有的放矢会提升更快,或者扔钱砸向技术狂。硅谷的互联网小公司里面十有八九个是 Ruby/Rails, 就是这个原因。

说来有趣,说到融合进一些函数式的东西来做 Ruby,今天就有人博客了这个

http://weblog.therealadam.com/2012/09/10/designing-for-concurrency/

#19 楼 @knwang

你的回复我必看,每次都让我学到很多很多东西 !!

👍

#9 楼 @zw963 gem 的冗杂产生于不经审核就上线公开,良莠不齐,但是有一个好处就是大家都可以尝试自己想写的东西,大量冲击下自然有优秀的 gem 脱颖而出,好东西自然用户多,开源的话测试员就多。初学者自然要跟主流走,学习好基本知识后再应用特殊环境和优化 gem 选择。

#11 楼 @zw963 很多语言的编译结果的确是递归慢而且慢很多,这个主要是编译器的问题。其实递归这个操作本身就是复制参数的过程,代价不应该很大,但是有些编译器为了一些语言特性搞的这个过程沉重无比。以前写 Pascal 生怕自己递归太多,一不小心就崩了。

#17 楼 @zhenjunluo 不容易写对其实是思维方式问题,还不习惯罢了。其实递归大多可以写成简单的数学等式的表达,过程式的多数就要使用流程图来表达。

符合应用环境的就是最好的选择,比如 Web 开发选择 Ruby 有很大优势

25 楼 已删除

原文:而 "i++" 显然比 "i=i+1" 少 2 个字符,所以他们觉得可以节省一些空间。 说得有问题吧? 并不是因为代码中"少 2 个字符",所以才节省一些内存空间,而是因为,编译之后的目标代码中,前者比后者节省一个临时变量,所以可以节省一些内存空间。

王是比较 academic 的人,适合在大的学术机构或者研发中心。

@void

前者比后者节省一个临时变量

编译器会这么傻?表示怀疑,可有经过验证?

需要 登录 后方可回复, 如果你还没有账号请 注册新账号