如何评价Clojure

1.Clojure能够吸引人的很重要一点是它是JVM之上的语言,这个决定非常关键

首先,因为根植于JVM之上,并且做到了跟Java语言的相互调用,它能吸引很多成熟的Java开发者。其次,它可以使用Java社区丰富的开源软件,不需要从头去构建一个社区,你可以看到很多Clojure开源代码都是简单地包装Java的开源包,但是通过Clojure高度抽象简单的语法提供更便利的使用的方式;
第三,由于JVM平台本身的高度成熟和优化,clojure的编译器生成的byte code跟Java编译器生成的byte code并无二致(不完全是),它的性能和稳定性也能马上得到保证,这比从头构建一个新平台成本低得多。

构建于JVM之上,Clojure就是一门“严肃”的语言,而非很多人眼中的Lisp“玩具”语言,你学习后可以马上使用并且实践。但是Clojure又是Lisp方言,Lisp的神奇能力它还都保留,这样兼具美学和实用的语言如何让人不爱?我相信很多熟悉Scheme之类方言的童鞋,并且有Java背景的,都会对Clojure有相见恨晚的感觉。

2.Clojure的设计原则可以概括成5个词汇:简单、专注、实用、一致和清晰。这不是我概括的,而是《The joy of clojure》概括的。

(1)简单: 鼓励纯函数,极简的语法(少数special form),个人也认为clojure不能算是多范式的语言(有部分OO特性),为了支持多范式引入的复杂度,我们在C++和Scala身上都看到了。
(2)专注:前缀运算符不需要去考虑优先级,也没有什么菱形继承的问题,动态类型系统(有利有弊),REPL提供的探索式编程方法(告别修改/编译/运行的死循环,所见即所得)。
(3)实用:前面提到,构建在JVM之上,跟Java语言的互操作非常容易。直接调用Java方法,不去发明一套新的调用语法,努力规避Java语言中繁琐的地方(doto,箭头宏等等)。
(4)清晰:纯函数(前面提到),immutable var,immutable数据结构,STM避免锁问题。不可变减少了心智的负担,降低了多线程编程的难度,纯函数也更利于测试和调试。
(5)一致:语法的一致性:例如doseq和for宏类似,都支持destructring,支持相同的guard语句(when,while)。数据结构的一致性:sequence抽象之上的各种高阶函数。

具体到STM,我个人认为这个特性在日常编程中,其实你用到的机会不多。在web编程里,你的并发模型Web Container已经帮你处理(tomcat,jetty),事务也是数据库帮你处理,几乎找不到场合去使用STM。这个特性在做一些中间件或者底层framework的时候才可能用到。这个特性的设计上面已经提到,跟clojure的设计目标是紧密相关的,跟immutable数据结构也是密不可分,同时它也不是没有代价,事务历史记录和慢事务频繁回滚的代价,有时候你还是需要退回去使用Java那套锁机制,庆幸的是Clojure不阻止你去使用,并且提供了类似locking这样的宏来方便你使用。

3.Scheme我对它的了解也就是做过SICP的习题。

粗粗看过《Programming Scheme》,两者对比的优缺点似乎谈不上来。需要对Scheme更熟悉的专家来做个对比。

Clojure的设计缺陷不能说是缺陷,这是由于它设计的目标决定的,有得必有失

首先还是JVM,基于JVM有种种好处,但是JVM的启动速度实在悲剧,因此用Clojure写一些小的script处理日常事务,显得还是不够得心应手,这样的工作我还是用Ruby,Python的脚本语言来搞定更便捷。不过目前Clojure有一些其他语言之上的实现,比如rouge-lang/rouge · GitHubhalgari/clojure-py 路 GitHub 这些实现应该会比JVM的启动快很多(抱歉,我没测试过)。

不仅如此,因为Clojure跟JVM平台的绑定如此之深,并且为了真正发挥Clojure的威力,你还需要去熟悉Java平台的东西,熟悉Java语言、类库、内存模型、GC优化、多线程和网络编程、开源类库等等。可以这样认为:想成为一个好的Clojure程序员,首先需要是一名好的Java程序员。这也一定程度上阻碍了Clojure的推广,提高了学习成本。

其次,Clojure的API设计上,有时候不符合你的直觉,而是符合Clojure的哲学,比如contains?函数对vector等数组型集合的调用上。关于这一点,Rich的回答是“Elegance and familiarity are orthogonal.”,也就是优雅和熟悉是正交关系的。保持API内在的一致性,比直觉的“熟悉”更重要。Clojure不妥协于你的“直觉”。

第三,弱类型的好处足够多,灵活,减少声明代码,适合探索式编程;同样,坏处也不是没有,没有类型保障,错误可能要等到运行时才能发现,静态代码检查工具也没有办法帮你发现,这就需要你一定程度的测试代码来保证运行时行为。

第四,性能上,虽然clojure生成的字节码已经很高效,也有type hint这样的技术来帮助提升性能,但是会有不少的转型(checkcast)、装箱和拆箱(boxing and unboxing)以及类型判断分支跳转的多余指令,这在一些性能敏感的应用里可能会暴露出来。尽管我认为大多数网站型的应用瓶颈都会落在IO上。

扫一扫,分享到微信

微信分享二维码
  • Copyrights © 2020-2022 Henry
  • Visitors: | Views:

请我喝杯咖啡吧~

支付宝
微信