2018/10/25 10:44

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.

引用来自“joymufeng”的评论

Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/

引用来自“dwingo”的评论

Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.

引用来自“joymufeng”的评论

Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄

引用来自“dwingo”的评论

不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.

引用来自“joymufeng”的评论

你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。

引用来自“dwingo”的评论

相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).

引用来自“joymufeng”的评论

目前 Java 的企业级开发地位是任何语言都无法撼动的,所以建议新手还是老老实实学 Java。但是作为经验丰富的老手或是公司技术领导者应该把眼光放远一点,毕竟都进入微服务时代了,不同的语言应该各领风骚。很多场景 Scala 更适合,比如说高并发,流处理,完全异步非阻塞系统的构建。

引用来自“dwingo”的评论

流处理不清楚, 但高并发和异步非阻塞Java也完全支持的很好. Java也有协程库.

引用来自“joymufeng”的评论

其实没必要陷入语言之争,这个话题无解。更不要把Java和Scala摆在对立的位置上,Scala完全拥抱现有的Java生态,并且提供了更多解决问题的工具,比如Macro,DSL,隐式转换,以及完整的函数式支持,这些都是Java不具备的,可以认为Scala是Java的一个有力补充,而不是竞争对手,大家其实是一家人,共同壮大JVM生态才是正道。

引用来自“dwingo”的评论

是你先发文挑起, 我只是摆事实, 说明一下文章回避的Java优势而已. 怎么选择让读者自己分辨. Java所选的特性都是优点明显大于缺点的. 而Macro等特性都是争议性很大的, 大多数语言不支持宏都是有道理的, C都支持的特性并不说明这个特性不好加, 而是说明怕这些特性被滥用宁愿不加而已. 提高开发效率的方式并不是加特性一种途径, 而利于阅读理解,利于查出bug,利于协作统一也是非常重要的环节. 优点不多的特性Java都很谨慎加入, 函数式也是挑重要的支持, Scala的一些写法都能换一种不太麻烦的Java写法实现.
额~,此宏非彼宏,不可同日而语。其实全文的主题都在围绕Scala的"简洁性"展开,如果你阅读了全文,我想你应该能发现 Scala 并没有追求极致短码而导致不可读,而是在简洁和可读之间权衡的很好。所以本文的观点也非常明确,如果希望书写的代码更加简洁并且富有表达力,那么可以尝试下 Scala。Scala的很多设计都是为了改良Java,所以学习Scala的过程其实是对Java的一种深度回顾。真心希望大家可以浏览下《快学Scala》这本书,作者是Java语言大师,全文围绕Java与Scala展开,翻译也很棒,读完一定会大有收获。
2018/10/24 22:06

引用来自“海淀游民”的评论

智商不够,用不了 Scala (逃)

引用来自“漂浪天下”的评论

同感

引用来自“joymufeng”的评论

可以先玩玩试试,也许你会有新发现

引用来自“烟波”的评论

感觉有些特性和Common Lisp有点像,类似函数式编程那套理论,最近接触的几个新语言好像都有这个趋势
嗯,Scala 生态比较成熟。
2018/10/24 22:02

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.

引用来自“joymufeng”的评论

Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/

引用来自“dwingo”的评论

Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.

引用来自“joymufeng”的评论

Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄

引用来自“dwingo”的评论

不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.

引用来自“joymufeng”的评论

你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。

引用来自“dwingo”的评论

相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).

引用来自“joymufeng”的评论

目前 Java 的企业级开发地位是任何语言都无法撼动的,所以建议新手还是老老实实学 Java。但是作为经验丰富的老手或是公司技术领导者应该把眼光放远一点,毕竟都进入微服务时代了,不同的语言应该各领风骚。很多场景 Scala 更适合,比如说高并发,流处理,完全异步非阻塞系统的构建。

引用来自“dwingo”的评论

流处理不清楚, 但高并发和异步非阻塞Java也完全支持的很好. Java也有协程库.
其实没必要陷入语言之争,这个话题无解。更不要把Java和Scala摆在对立的位置上,Scala完全拥抱现有的Java生态,并且提供了更多解决问题的工具,比如Macro,DSL,隐式转换,以及完整的函数式支持,这些都是Java不具备的,可以认为Scala是Java的一个有力补充,而不是竞争对手,大家其实是一家人,共同壮大JVM生态才是正道。
2018/10/24 19:21

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.

引用来自“joymufeng”的评论

Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/

引用来自“dwingo”的评论

Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.

引用来自“joymufeng”的评论

Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄

引用来自“dwingo”的评论

不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.

引用来自“joymufeng”的评论

你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。

引用来自“dwingo”的评论

相比之下还是Java更容易进阶一些, 而且同样也很适用于大工程, 上手也相对简单, 又不像C/Go这样精简的语言虽然语法简单但做大工程就捉襟见肘了(抽象能力低). 我承认Kotlin,Scala确实能把代码写的少些, 但写代码的时间我觉得只占整个工程很小的一部分, 而且有IDE的辅助Java也不会多用多少时间, 过分精简代码容易导致阅读困难, 代码检查也因为代码冗余度低而难于发现代码中的bug. 语法特性过多也容易导致不同的人写法风格迥异, 做大工程难于调和(Python比Ruby流行的一大因素).
目前 Java 的企业级开发地位是任何语言都无法撼动的,所以建议新手还是老老实实学 Java。但是作为经验丰富的老手或是公司技术领导者应该把眼光放远一点,毕竟都进入微服务时代了,不同的语言应该各领风骚。很多场景 Scala 更适合,比如说高并发,流处理,完全异步非阻塞系统的构建。
2018/10/24 17:16

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.

引用来自“joymufeng”的评论

Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/

引用来自“dwingo”的评论

Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.

引用来自“孤独的探索号”的评论

同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang

引用来自“dwingo”的评论

简单看了一下, 类似groovy的特性, 不知道比groovy好在哪, 后来者只有优势非常大才可能超越.
语法更接近JSON,尤其是 { key : value } 和 [ key: value ]。
更简单的数据类型,数字只分整数Number和小数Decimal。
https://github.com/TommyLemon/Axis-Lang
2018/10/24 16:43

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.

引用来自“joymufeng”的评论

Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/

引用来自“dwingo”的评论

Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.

引用来自“joymufeng”的评论

Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄

引用来自“dwingo”的评论

不关心这些的结果就是你永远处于初级水平, 高手必须要弄通所用技术栈各层次原理, 遇到bug很快就能清楚哪里出问题, 遇到性能也能轻松找到瓶颈点. 如果只为了搬砖那就无视我说的吧, 不过想招些搬Scala砖的也不容易. Scala这么搞只会让用Go语言的极简敏捷主义者们更加鄙视,更被误解成Java环境很笨重,对新手不友好.
你说的是通用的性能调优问题,无论是选择哪种语言,进阶时是不可避免的。
2018/10/24 16:37

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.

引用来自“joymufeng”的评论

Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/

引用来自“dwingo”的评论

Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.

引用来自“孤独的探索号”的评论

同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang

引用来自“dwingo”的评论

简单看了一下, 类似groovy的特性, 不知道比groovy好在哪, 后来者只有优势非常大才可能超越.
二者还是有比较大区别的。groovy 是动态类型语言,意味着如果你用它编写大型项目,重构将会是一场灾难;而 Scala 虽然使用了动态类型语法,但其实它是静态类型语言。
2018/10/24 16:07

引用来自“Shazi199”的评论

diamond应该是菱形的意思,翻译成钻石有问题
感觉译为钻石比较好,菱形会让人联想到菱形继承。
2018/10/24 16:01

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.

引用来自“joymufeng”的评论

Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/

引用来自“dwingo”的评论

Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
2018/10/24 14:51

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.

引用来自“joymufeng”的评论

Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/

引用来自“dwingo”的评论

Scala是可以写出性能很高的程序, 但这是在已经为Scala投入很多时间精力才能换来的, 需要对每个语法都有很透彻的理解, 如何编译成什么样的字节码, 需要多少内存分配, 有什么副作用, 最佳实践是什么, 这些东西都写清楚一千页的大部头都不够用, Java/JVM都要学很多东西才深入理解, Scala至少得用翻倍的时间精力. 而且复杂的语法带来的编译时间开销, 把Java对比C++这一大优势给抵消了. 最后运行时还得带一大坨jar.
Scala 并不像你描述的那个样子,真正编码的时候没有人会关心字节码这种底层操作,那些应该是编译器和运行时该关心的事情。动手尝试一下可能会打消你很多的疑虑😄
2018/10/24 12:38

引用来自“孤独的探索号”的评论

引用来自“zqq90”的评论

很多时候,都是在 「灵活」和「可控」之间找个平衡
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang

我的是
https://github.com/febit/wit
2018/10/24 11:48

引用来自“zqq90”的评论

很多时候,都是在 「灵活」和「可控」之间找个平衡
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
2018/10/24 11:48

引用来自“巴林的狗尾草”的评论

Java之后几乎所有的语言都沿着Java定的方向添添补补,除了python略微不同。没有思想上的突破,这种东西颠覆不了Java
同样基于 JVM 的 Axis 语言,目标是 强大、灵活、安全、简单,可以探讨交流下
https://github.com/TommyLemon/Axis-Lang
2018/10/24 10:57

引用来自“hsl727261250”的评论

除了语法级别的特性, 我觉得其他特性可以自己魔改一下java也能实现😂😂
Scala 的很多特性是通过编译器实现的,魔改不可行哦! Java 原始的的泛型系统和编译器就是马丁老爹设计的,所以编译器是Scala的强项。
2018/10/24 10:52

引用来自“dwingo”的评论

写法是简单了, 但上手还是加大了不少难度, 而且隐藏的坑只多不少, 另外更难以分析了解这些花式写法对性能的影响.
Scala 的很多特性是在编译时完成的,不会影响运行时性能。Scala 2.13 的集合性能有了显著的提升,具体参考:https://www.scala-lang.org/blog/2018/02/09/collections-performance.html。另外Scala 2.13 之前的性能评测请参考:https://colobu.com/2016/11/17/Benchmarking-Scala-Collections/
2018/10/24 10:27

引用来自“海淀游民”的评论

智商不够,用不了 Scala (逃)

引用来自“漂浪天下”的评论

同感
可以先玩玩试试,也许你会有新发现
2018/10/24 10:25

引用来自“zqq90”的评论

很多时候,都是在 「灵活」和「可控」之间找个平衡
👍
2018/10/24 09:21
Scala需要聪明的人理解语言的每个特性,但是更聪明的人就不会用它们。
2018/10/23 17:56
Java之后几乎所有的语言都沿着Java定的方向添添补补,除了python略微不同。没有思想上的突破,这种东西颠覆不了Java
2018/10/23 17:42
真好,所以我用kt。
2018/10/23 13:53
很好。但是我们用 kotlin。#DuiC#
2018/10/23 13:23
很多时候,都是在 「灵活」和「可控」之间找个平衡
回复 @
{{emojiItem.symbol}}
返回顶部
顶部