从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)

programming language

这是这个系列的最后一篇,从编程范型的角度概览,前面几篇的链接在文章后半部分有汇总。

我在之前已经 介绍过编程范型的概念 ,而事实上,我们到现在为止,纠结在这四门迥异的语言上面,浅看是各种语言特性,深看就是编程范型和思维方法。

下面这张“神图”来自于 这里 ,可以说是对于范型和语言归类的概览,从左往右从更强的声明式向着更弱的声明式发展;依据状态分为 Unnamed state(串行或并发,包含逻辑式和函数式这几种分类)、Nondet. state(所谓的不确定性状态)和 Named state(包含数据流、消息传递和状态共享这几种分类),Haskell 出现在了左侧函数式语言的分支内,而 Java 出现在了右侧

[……]阅读全文

从 Java 和 JavaScript 来学习 Haskell 和 Groovy(DSL)

dsl 这是《从 Java 和 JavaScript 来学习 Haskell 和 Groovy》系列的第四篇。

首先来理解 DSL。

DSL(Domain Specific Language)指的是一定应用领域内的计算机语言,它可以不强大,它可以只能在一定的领域内生效(和 GPL 相比,GPL 是 General Purpose Language),表达仅限于该领域,但是它对于特定领域简洁、清晰,包含针对特定领域的优化。

当我们面对各种各样的特定需求的时候,一个通用的语言往往不能高效地提供解决问题的路径,相应的 DSL 并不是并非要解决所有的问题,但是它只关注于某一个小领域,以便解决那一个小领域的问题就好了。比如 HTML,只用

[……]阅读全文

从 Java 和 JavaScript 来学习 Haskell 和 Groovy(元编程)

metaProgramming

本篇文章的话题是元编程。首先来认识元编程,我在第一篇 《引子》 里面已经介绍:元编程,指的是在运行时改变“类”的定义,例如访问、增加或修改等等。一言以蔽之,就是“用程序来写程序”。在第二篇的 《类型系统》 里面已经借由继承和接口的实现,介绍了一些利用元编程特性来增加或改变子类行为的方法。回顾语言发展的长河,其实是经历了一个从“对象 -> 类 -> 元类”到“对象 -> 原型”的发展过程的。所以,无论是类,还是元类,这样的概念其实都不是非有不可的,只是因为我们思考的习惯,特别是抽象的习惯而顺其自然地产生了。这一点我在 《编程范型:工具的选择》 里面已经详细描述了,建议在往下阅读前移步。

[……]阅读全文

从 Java 和 JavaScript 来学习 Haskell 和 Groovy(类型系统)

Haskell 接上文 《从 Java 和 JavaScript 来学习 Haskell 和 Groovy(引子)》

首先搞清几个概念:

  • 动态类型(Dynamic Typing)和静态类型:区别的核心在编译期还是运行时。静态类型的语言系统在编译期就明确知道每一个变量的类型,如果发现不合法的类型赋值就在编译期报错;动态类型则直到运行时才会报错。
  • 类型推导(Type Inference),类型推断是指可以在上下文中,编译器来推导实际的类型,也就是代码使用隐式类型指定。比如一个简简单单的“var a=1”,a 就被推断成整型。
  • 弱类型(Weakly Typed)和强类型:指的是语言系统对类型检查,或者是类型之间互相转换

[……]阅读全文

从 Java 和 JavaScript 来学习 Haskell 和 Groovy(引子)

compare 我记得刚接触计算机的时候,我就受到了两个非常巨大的错误观念的影响,这个观念最初是来自于老师的传授还是学长的教诲已经记不清了,但是直到我工作几年以后,才慢慢有了实际的体会:

  1. 学习和使用什么编程语言不重要,重要的是算法和设计;
  2. 程序员学习的精髓是面向对象的设计模式,掌握以后,一通百通。

简直就是是胡扯啊。也许在某个极其狭隘的上下文中还能这样说,但是泛泛而谈,这样的态度无疑是误人子弟的。

就说第一条,编程语言不但重要,而且太重要了。换句话说,学习一门新的编程语言,可能学习的是背后的范型和思考问题的方式。如果这个部分能带来新的东西,那就是值得花时间投入的。

可能很多人和我的背景一样,熟悉 Java 和

[……]阅读全文

编程范型:工具的选择

programming language 这是我写的关于编程范型的文章中最后一篇。

《编程的未来》 里面提到过,很多时候脑子里的算法还是不容易转变成代码,大部分情况下这不是你编码技巧的问题,而是编程语言的问题,或者更严格地说,是编程语言选择的问题。除了复杂性这个软件唯一的敌人,其它真正的困难,早就被数学家们解决了,如果问题和它的解决能够用数学轻松地表述出来,那计算机只是工具而已。极端地说,如果有合适的工具,那么就选择一个;如果没有,那么可以创造一个。仅此而已。

工程师的乐趣,大抵在解决实际问题上,既有解决问题的成就感,也有解决问题的过程。而为了解决问题,又需要分析问题,选择合适的工具,再来使用工具解决问题这几部分。我们对于各种设计模

[……]阅读全文

Groovy on Grails 交流活动

2008 年 InfoQ 交流活动的胶片:

http://cid-5b1e02933669f469.skydrive.live.com/redir.aspx?page=browse&resid=5B1E02933669F469!105&type=5

 

活动宣传页:
 
 
2008 年上半年,一次活动中的翻译稿。Groovy on Grails 一些文章的翻译:
 
10 个对于 Grails 的误解
 

[……]阅读全文

back to top