目录 start

  1. JVM上的多语言使用
    1. 重新实现的语言和原生语言
    2. JVM上的多语言编程
      1. Groovy
      2. Scala
      3. Clojure
      4. 为什么非要用Java语言
      5. JVM对备选语言的支持
      6. 编译器小说

目录 end|2019-10-19 17:04|


JVM上的多语言使用

参考 Java程序员修炼之道

重新实现的语言和原生语言

一般来说,以JVM为目标的语言较重新实现的语言能将自己的类型系统和JVM的类型系统结合的更紧密

  • Java是运行时编译,静态类型的命令式语言。强调安全性,代码清晰,性能,并表现出一定程度的繁琐和死板(例如部署)

  • 重新实现已有语言的JVM语言:

    • JRuby:Ruby是一个动态类型的面向对象语言,有些函数式特性,在JVM上基本算解释型的
    • Jython:动态的面向对象语言。运行方式是先生成Python字节码再转化成JVM字节码。这使得他能以看起来像是Python的典型解释型模式下运行
    • Rhino:他在JVM上提供了一个JavaScript实现,既支持编译模式,也支持解释模式

JVM上的多语言编程

  • 非Java技术的作用可以分为三个层次 特定领域层,动态层,稳定层,多语言编程金字塔:

    p178金字塔
    p178金字塔
  • 静态类型语言更倾向于稳定层的任务,能力不是那么强,通用性较低的技术在金字塔的顶部更好用

Java 、Groovy、 Scala 的未来会怎样?
Java & Groovy & Scala & Kotlin - 16.方法,Lambda 与闭包

  1. 喜欢Ruby => 用Groovy
  2. 喜欢LISP,喜欢STM功能 => 用Clojure
  3. 喜欢C++ => 用Kotlin

Scala有两个流派:FP和Better Java。FP派喜欢scalaz,喜欢shapeless,喜欢type level programming。这一派特点是程序高度抽象但可读性奇差。
适合PL研究者验证概念,适合业余项目自嗨,也适合学习PL概念。不适合多人协作的工程项目。Better Java派以前之所以存在,单纯是因为Java语法设计太烂,烂到无法忍受。
而JVM上当时也没有其它更好的选择。
那些告诉你“写了n年Java以后,我切换到Scala,现在每天都活在幸福中”的人,基本都是这一派。但Scala as a better Java的工程性也不好,因为特性太多太复杂,除非有高手带队,否则很难只用到它“better java”的那个子集。
解决一个问题的同时,往往引入更多的问题。所以会有Java8发布以后Linkedin所有新项目全部回归Java这种事情。

Groovy是动态语言,工程性比Scala还差。但是因为有Gradle这种被广泛采用的项目,所以会存活下去。但是请记住爱因斯坦曾经说过:“任何超过两百行的新项目,都不应该采用动态语言开发,无论是Ruby,Python,Perl,Groovy还是Clojure”。
哦,对了,也不要用Clojure。因为它是动态语言,而且是Lisp系的动态语言。“Lisp系”意味着,读书的时候可以靠它开眼界。毕业工作以后,对于这一类语言,能躲多远就躲多远。

刚刚发布的Kotlin看上去靠谱。它不讲究FP有多纯,目标就一个:“a better java”。Kotlin在“到底引入多少FP特性”上面做得恰到好处。 看到Kotlin,我马上就想起了这个演讲:“Please stop polluting our imperative languages with pure concepts”。
Kotlin有以下好处:

  1. 强大的IDE。而且是JetBrains第一方支持,不是3年更新一次的第三方插件;
  2. 库多生态强。Kotlin的设计者非常重视和Java的互操作,所以Kotlin号称可以无缝衔接所有Java库。
  3. 宇宙第一运行时:JVM。
  4. Android上不能用Java8的新语法,Kotlin恰逢其时的出现,抓了一波完美的timing。如果Kotlin依靠Android开发爆发,那服务器端,大数据界,也会收益,最后多面开花,势不可挡。
    但是Kotlin刚出来,到底有没有它自称的那么好用还待观察。另外,Kotlin社区现在集中力量攻坚Android,在服务器和大数据方向没什么靠谱项目。所以还是得用Java8。
    总之,“魔镜啊魔镜,谁是JVM上最好的语言”之最后决战,将是Java10 vs Kotlin(Java9在语法特性上已经输了)。而在这场最终决战之前,C#已经靠着CoreCLR统一世界了。

最后送上人生经验两则:

1
2
3
match comment with
| "X怎么不能Y?人家Z就是这样做的。" -> reply "卡马克能用haskell移植Wolf 3D,你能?"
| _ -> reply "Thank you"

1
2
3
match location with
| Office -> use whatever your boss chose
| Home -> use F#

Groovy

James Strachan 于2003年发明,可以看作动态层语言,擅长DSL构建

Scala

Martin Odersky 于2003年意外产生,一门支持函数式编程的面向对象语言
有一个非常好的ScalaTest测试框架,比Junit更简洁,

Clojure

Rich Hickey设计的属于Lisp家族的语言,动态类型的函数式语言,编译型语言但是通常以源码发布

为什么非要用Java语言

  • Java 作为一种通用,静态类型的编译型语言,实现稳定层方便,但是放到金字塔上层就成为负担
    • 编译耗时
    • 静态类型不够灵活,重构时间长
    • 部署麻烦
    • 语法不适合生产DSL(领域专用语言 domain specific language)
p180 分类
p180 分类

JVM对备选语言的支持

  • 一种语言要在JVM上运行的两种方式:
    • 一个产生类文件的编译器
    • 一个用JVM字节码实现的解释器
      p183.jpg
      p183.jpg
  • 有一种评估语言运行时环境复杂度的简单方法,看运行实现中Jar的大小,Clojure相对较轻量,JRuby就显得重

编译器小说

语言的某些特性是由编程环境和高层语言合成的,在底层JVM中不存在,这种特性就称为编译器小说

  • Java中的编译器小说还包括检查型异常和内部类(通常内部类都会转换成带有特殊合成访问方法的顶层类),如果jar -cvf看jar包,能看到很多含$的类,这些就是被取出转换成常规类的内部类
    备选语言的编译器小说
    p184.jpg
    p184.jpg
  • 函数一等值:
    • 这个就是说可以将函数当成其他普通值一样操作,Java只能把类当做最小的代码和功能单元。解决这种差异的方法是,因为对象只是把数据和操作数据的方法绑定在一起,只要有一个没有状态只有一个方法的对象。
    • 这似乎就是Java8的lambda表达式的存在条件,单方法的实现用操作符 ->
  • 多继承:
    • 在Java和JVM中无法实现多继承,只能使用接口,但是接口又没有任何具体的方法
    • 在Scala中特性机制 trait 允许将方法的实现混合到类中,所以提供了不同的继承视图,这种行为必须由Scala编译器和运行时合成,在VM层面不提供这种特性