MultipleLanguageInJVM
目录 start
目录 end|2020-04-27 23:42|
参考 Java程序员修炼之道
一般来说，以JVM为目标的语言较重新实现的语言能将自己的类型系统和JVM的类型系统结合的更紧密
-
Java是运行时编译，静态类型的命令式语言。强调安全性，代码清晰，性能，并表现出一定程度的繁琐和死板（例如部署）
-
重新实现已有语言的JVM语言：
- JRuby：Ruby是一个动态类型的面向对象语言，有些函数式特性，在JVM上基本算解释型的
- Jython：动态的面向对象语言。运行方式是先生成Python字节码再转化成JVM字节码。这使得他能以看起来像是Python的典型解释型模式下运行
- Rhino：他在JVM上提供了一个JavaScript实现，既支持编译模式，也支持解释模式
-
非Java技术的作用可以分为三个层次 特定领域层，动态层，稳定层，多语言编程金字塔：
-
静态类型语言更倾向于稳定层的任务，能力不是那么强，通用性较低的技术在金字塔的顶部更好用
Java 、Groovy、 Scala 的未来会怎样？
Java & Groovy & Scala & Kotlin - 16.方法，Lambda 与闭包
- 喜欢Ruby => 用Groovy
- 喜欢LISP，喜欢STM功能 => 用Clojure
- 喜欢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有以下好处：
- 强大的IDE。而且是JetBrains第一方支持，不是3年更新一次的第三方插件；
- 库多生态强。Kotlin的设计者非常重视和Java的互操作，所以Kotlin号称可以无缝衔接所有Java库。
- 宇宙第一运行时：JVM。
- Android上不能用Java8的新语法，Kotlin恰逢其时的出现，抓了一波完美的timing。如果Kotlin依靠Android开发爆发，那服务器端，大数据界，也会收益，最后多面开花，势不可挡。 但是Kotlin刚出来，到底有没有它自称的那么好用还待观察。另外，Kotlin社区现在集中力量攻坚Android，在服务器和大数据方向没什么靠谱项目。所以还是得用Java8。 总之，“魔镜啊魔镜，谁是JVM上最好的语言”之最后决战，将是Java10 vs Kotlin（Java9在语法特性上已经输了）。而在这场最终决战之前，C#已经靠着CoreCLR统一世界了。
最后送上人生经验两则：
match comment with
| "X怎么不能Y？人家Z就是这样做的。" -> reply "卡马克能用haskell移植Wolf 3D，你能？"
| _ -> reply "Thank you"
match location with
| Office -> use whatever your boss chose
| Home -> use F#
James Strachan 于2003年发明，可以看作动态层语言，擅长DSL构建
Martin Odersky 于2003年意外产生，一门支持函数式编程的面向对象语言
有一个非常好的ScalaTest测试框架，比Junit更简洁，
Rich Hickey设计的属于Lisp家族的语言，动态类型的函数式语言，编译型语言但是通常以源码发布
- Java 作为一种通用，静态类型的编译型语言，实现稳定层方便，但是放到金字塔上层就成为负担
- 编译耗时
- 静态类型不够灵活，重构时间长
- 部署麻烦
- 语法不适合生产DSL（领域专用语言 domain specific language）
- 一种语言要在JVM上运行的两种方式：
- 一个产生类文件的编译器
- 一个用JVM字节码实现的解释器
- 有一种评估语言运行时环境复杂度的简单方法，看运行实现中Jar的大小，Clojure相对较轻量，JRuby就显得重
语言的某些特性是由编程环境和高层语言合成的，在底层JVM中不存在，这种特性就称为编译器小说
- Java中的编译器小说还包括检查型异常和内部类（通常内部类都会转换成带有特殊合成访问方法的顶层类），如果jar -cvf看jar包，能看到很多含
$的类，这些就是被取出转换成常规类的内部类备选语言的编译器小说
- 函数一等值：
- 这个就是说可以将函数当成其他普通值一样操作，Java只能把类当做最小的代码和功能单元。解决这种差异的方法是，因为对象只是把数据和操作数据的方法绑定在一起，只要有一个没有状态只有一个方法的对象。
- 这似乎就是Java8的lambda表达式的存在条件，单方法的实现用操作符
->
- 多继承：
- 在Java和JVM中无法实现多继承，只能使用接口，但是接口又没有任何具体的方法
- 在Scala中特性机制 trait 允许将方法的实现混合到类中，所以提供了不同的继承视图，这种行为必须由Scala编译器和运行时合成，在VM层面不提供这种特性