• why clojure?


    why clojure?

    作者: xumingming | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
    网址: http://xumingming.sinaapp.com/294/why-clojure/

    本文翻译自: http://clojure.org/rationale 转载请注明出处

    一方面客户以及董事们对于工业级别的标准平台如JVM投入了大量的资金,并且对于它的性能,安全性,稳定性都很满意。另一方面java工程师也很羡 慕动态语言的简洁,灵活以及开发效率,他们也希望这些动态语言能运行在客户/董事们所期望的平台上,可以访问那些已经很成熟的java类库,并且性能还应 该不错;他们要用原始的线程、锁来编写多线程程序。clojure就是一个为了满足这些需求的一个尝试: 一个运行在JVM上的动态语言。它可以被使用在java适合的那些场合,它描绘了一个并发编程的前景: 那种到处都是的,没有经过协调的,对资源的并发修改已经过时了

    为了实现clojure的目标:它使用工业级别、开放的平台: JVM;现代化一个传奇性的语言: LISP;使用不可更改的(immutable)的数据结构来进行函数式编程;通过software transactional memory以及asynchronous agents来内在地支持并发编程。其结果就是一个健壮的、实用的、快速的语言clojure的诞生。

    why clojure?

    为什么我要编写一种新的语言?简单来说,我希望找到一种具有如下特征的语言:

    1. 它是Lisp的一种方言
    2. 用它能进行函数式编程
    3. 它运行在一个已有的、成功的平台上
    4. 它内置地支持并发编程

    但是我发现已有的语言没有一个满足这些条件。下面列举了clojure背后的一些设计动机:

    Lisp是个好东西

    1. 一直被模仿,重未被超越
    2. lamda表达式使得核心可以很小
    3. 几乎没有语法
    4. 核心优势还是代码即数据(code-as-data)以及句法抽象
    5. 现有的传统Lisp(Common Lisp和Scheme)怎么样呢?
      1. 在标准化之后几乎没有再改进了
      2. 核心数据结构可修改,不可扩展
      3. 语言规范里面没有包括并发编程支持
      4. JVM上面已经有不错的实现(ABCL, Kawa, SISC)
      5. 标准Lisp都是用的他们自己的平台
    6. Clojure是一个不用考虑向后兼容性的Lisp实现
      1. 把code-as-data的概念扩展到了map和vector
      2. 数据默认不可修改
      3. 核心数据结构可以扩展
      4. 利用已有平台(JVM)

    函数式编程是个好东西

    1. 不可修改数据 + 高阶函数
    2. 通过约定编程(convention over configuration)上面两点Lisp都可以做到
      1. 但是如果一个数据是可以修改的,你假定它不会被修改是很危险的
      2. 在传统Lisp里面,只有list是结构可递归的
    3. 纯函数式语言一般都会是强静态类型的
      1. 不是对于每个人,每个任务都合适
    4. Clojure是一个带有动态特征的函数式语言
      1. 所有数据结构是不可修改的、持久的并且支持递归
      2. 多种集合,返回类型
      3. 动态多态

    语言以及平台

    1. 我说的平台是指虚拟机,而不是操作系统,是未来平台的趋势,它提供:
      1. 类型系统
        1. 动态强制以及安全性
      2. 类库
        1. 通过抽象使得我们不用关心不同的操作系统
        2. 一堆现成的工具类
        3. 内置以及第三方的库
      3. 内存以及其它资源管理
        1. 垃圾回收器是平台级别的(JVM),而不是语言级别的(Java)
      4. 字节码(Bytecode)  + 即时编译(JIT compilation)
        1. 使得我们不用关心硬件
    2. 语言作为平台  vs  语言 + 平台
      1. 旧的方式:每种语言自己建立平台
        1. GC, bytecode, 类型系统,类库等等
      2. 新的方式(JVM, .NET)
        1. 平台和语言是独立的
    3. 平台内置的语言   vs  移植到平台上的语言
      1. 很多新的语言还是走“语言就是平台”的老路
      2. 当移植的时候就会有“平台到平台”的一些问题
        1. 内存管理,类型系统,线程问题
        2. 重复的类库
        3. 如果这个语言一开始是基于C的话, 一些C的扩展类库可能不好移植过来
    4. 客户们会认定一些平台
      1. “必须要运行在JVM/.NET上”   VS  “必须要运行在Unix/Windows上”
      2. JVM已经树立了一定品牌
        1. 现在还开源了
      3. 与其他语言的互操作
        1. 同坐C的linkage来做现在已经不是很高效了
    5. Java/JVM是语言  + 平台
      1. 一开始设计不是为了这个,但是现在JVM上已经有别的语言了,并且被Oracle接受
      2. Java是沉闷的、缺乏表达力的
        1. 没有高阶函数,没有类型推导等等
      3. 具有调用Java代码的能力是重要的
    6. Clojure作为语言,JVM作为平台

    面向对象被高估了

    1. 设计的时候是用来仿真的,现在被用在任何地方 — 即使是不恰当的
      1. 被Java/C#鼓励用在任何地方 — 其实是因为他们除了面向对象也没什么别的东西了
    2. 可修改状态的对象是新的“臭代码”
      1. 很难理解,测试
      2. 对并发编程是个灾难
    3. 继承并不是实现多态的唯一办法
    4. “用100个方法来操作一个数据结构比用10方法来操作10个数据结构要好” – Alan J. Perlis
    5. Clojure把它的数据结构建模成由接口表示的不可变的对象
    6. 和java的不同就是数据结构很少(seq, map, vector, set),但是每个数据结构的方法很多
    7. 用java来写java类,在clojure里面使用java的类

    多态是个好东西

    1. 通过switch,if-else“实现的”多态是很脆弱的
    2. 多态使得我们的系统更可扩展,更灵活
    3. clojure的multimethods使得多态和面向对象,类型解耦
      1. 支持多种分类
      2. 通过静态,动态甚至外部属性,元数据来分派方法(多态)

    并发以及多核未来

    1. 不可更改性可以使得许多并发问题不攻自破
      1. 对象可以自由的在线程间共享
    2. 但是对于数据的修改对于仿真来说是必要的
    3. 锁的机制是很难弄得100%正确的(太难了,我们又太菜)
    4. Clojure的software transactional memory以及agent系统把所有难点都做掉了(所以我们轻松了)

    简单来说,我觉得clojure是JVM上面具有多线程支持的Lisp, 有关它的更多特性看这里

  • 相关阅读:
    对 HTTP 304 的理解(转-并增加自己的测试)
    山寨云主机充斥市场 教您辨别真假云主机
    JavaScript判断字符串是否含有中文(实用)
    ThinkPHP CURD返回结果参考
    Linux下修改网卡的mac地址
    Asterisk重要App
    Validation(3)--全局参数异常校验捕获及返回XML解决
    Validation(2)
    Validation(1)
    Mybatis分页中遇到的坑2
  • 原文地址:https://www.cnblogs.com/lexus/p/2356625.html
Copyright © 2020-2023  润新知