@aheadlead 这个相当不错，我用了之后已经推荐好几个同事买了

5 年以上都要高级或者资深了，没有公司愿意招一个 5 年的 CRUD 选手

@issues 你那是 python2，module 名字不同

Java 反序列化 JSON 得到的 object，不能调用它的方法吗？

@Miy4mori 之前需要被 aop 操控的 class 需要写 open，除此之外还有哪些拧巴?

用了半年了，日 PV 过亿的项目

@silva C++这样也能算最灵活？估计你没玩过 lisp 吧。一个语言流行不流行，有很多因素在里面，灵活不灵活只是很小的一个因素之一。你觉得死板是优点，你高兴就好。不喜欢死板的 Javaer，已经用上 Lombok 了。

@silva 对你来说是语义混淆，对我来说那是增强，它不会给我造成任何不清晰或者不明确，相反会节约我时间。

数量跟正确性无关，但是一大波主流语言的设计者们的共同选择，正确的可能性还是蛮高的。

从根本上说，是否加入 XX 特性可能无关正确性，而是各人根据自身经验和喜好，做的一个决定罢了。

ps: 从某种程度上讲，interface 和多态，是同类型同签名方法的不同语义，也是一种你眼中的混淆，只不过你没法回避这种混淆，只能认命。

@mko0okmko0 Koltin 性能 >= Java，得益于 inline 方法

@silva 你当然有权认为这是混淆，但是 C#,Swift,Python,Ruby,PHP,JS,VB 等等都是这么做的，这已经是比较 common 的 sense 了，也许 Java10 或者 Java11 也会引入这样的特性，你接受不了可以不用。哦，顺便说一下，即使是 Java6，用了注解，也会有一些改变语义的 magic 发生，是不是也是种混淆？还有==运算符，有时候比的是引用，有时候比的是值，你也别用了。

@msg7086 Python 现在也经常有人写 list/dict/set comprehension 了，偶尔还会有两层甚至三层的 comprehension，Java 不这么写，只是因为长期以来一直语法罗嗦不方便这么写，Java8 稍稍改进了一点但还是不够简洁。

我举个例子试着对比一下可读性和罗嗦之间有没有关联，先来个 Java 版的
https://gist.github.com/anonymous/b7361b54a68afe154f9a4eb01ad0e228
71 行代码，原汁原味的 getter 和 setter，sortByAgeA 和 sortByAgeB 分别用了 Java7 和 Java8 的 style，更罗嗦的 Java7 可读性更高吗？我不觉得。

再看一下 Kotlin 的写法，
https://gist.github.com/anonymous/ba398be974f1861256a5770eb33b009c
只有 13 行代码，没有 getter/setter，连 toString 都自动合成了比较理想的形式，sort 的方法太简短，以至于专门定义个方法都显得多余。

more verbose 并不能得到 more readable，两者相关，但没有因果关系，再举个例子
a = a * b 和 assign a * b to a 比，后者更 verbose，而且不会让初学者对等号产生疑惑，但它可读性如何呢？

@af463419014 去年恰好接手了一个两年的项目，我先把 Java6 升级到 Java8，再把 spring3 升级到 spring4，然后把 maven 迁移到 gradle，最后引入 Kotlin 混合开发，除了新增文件都是 Kotlin 以外，偶尔得闲了还不忘挑一两个 Java 文件转换成 Kotlin，夹带在版本中一起测试发布，迁移还是比较平稳的。

Java 不是语法糖不足的问题，它是落后现代语言太多，不跟别的比，就跟 C#比，它的语法也显得有些老态龙中了。如果我同事 low 到连一点儿最基本的语法糖都成为障碍，我会考虑换同事，或者换工作，不会迁就培训班水平的同事。

@silva 你不需要看上下文，你可以当作它就是调用了 setter，赋值只是它的优化，优化时省略了自动合成的 setter 而已。即便是 Java 写了 setter，你不看代码，仍然不知道它是不是只做了赋值，还是做了别的事情。你创建的对象，JVM 也会做优化，有的在堆上，有的在栈上，通过逃逸分析和 JIT 等优化手段，它有很多种可能性，你在 Java 里写的 getter/setter，JVM 仍然存在帮你把方法调用优化掉的可能性，所以你关心是真的赋值还是 set 方法，毫无意义。

@af463419014 不熟悉 kotlin，熟悉 Python 或者 C#也行，即便 JS 也有这个功能，property 是很多现代语言的共性，并不会增加多少理解上的困难。Kotlin property 能做的事情远非 getter/setter 这么简单，它还能很方便的实现 lazy 求值。事实上很多 Javaer 已经开始用 Lombok 去自动合成 getter/setter，IDE 的确能比手写省事不少，但是一个 300 行的文件，跟一个 100 多行的文件，每次读到多出来的 100 多行代码会占用大脑几个 cycle，有时还要多拖动两下，降低效率。

@CRVV 语义是一样的，只是性能不同，qsort 也能用 macro 封装，https://github.com/ahmadsalim/qsort-inline，这样就没有函数调用开销了，多态也可以通过函数指针模拟，内核 VFS 不就这么干的么。

明年租约到期了我也准备涨个 500

你没 get 到
https://kotlinlang.org/docs/reference/properties.html

Java 定义成了 public，就绕过 getter/setter 了，如果有 100 个地方写了 foo.bar = xxx，你把 field 改成 private 再加上 getter/setter 的时候，已经晚了，你要 100 个地方一个个改过来，如果你发布的是个库，所有使用这个库的代码都要一一改过来。

Kotlin 的 property，你写 foo.bar=xxx 的时候，它会检查有没有 setter，有 setter 就会调用 setter，没有就直接赋值。因为 property 定义的时候，是可以有可选的 getter/setter 的。当你给一个 property 增加 setter 的时候，调用它的地方，是不需要修改代码的。C#或者 Python 都有这样的特性，只有万年不变的 Java 一直原地踏步。

@CRVV C 不是自带了一个 qsort 吗？

@msg7086 我不懂 ruby，但是不到一分钟就 get 到原理了，Java 版的更好懂更好维护吗？
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class Print {
private static <T> List<List<T>> tr(List<List<T>> m) {
if (m.isEmpty()) {
return Collections.emptyList();
}

List<List<T>> n = Stream.generate(ArrayList<T>::new).limit(m.get(0).size() - 1).collect(Collectors.toList());
n.forEach(ts -> m.forEach(t -> ts.add(null)));

for (int i = 1; i < m.get(0).size(); i++) {
for (int j = 0; j < m.size(); j++) {
n.get(i - 1).set(m.size() - j - 1, m.get(j).get(i));
}
}
return n;
}

private static <T> String spiral_print(List<List<T>> m) {
if (m.isEmpty()) return "";
StringBuilder b = new StringBuilder();
m.stream().map(chars -> chars.get(0).toString()).forEachOrdered(b::append);
return b.append(spiral_print(tr(m))).toString();
}

public static void main(String[] args) {
{
List<List<Character>> m = new ArrayList<>();
m.add(Arrays.asList('a', 'b', 'c', 'd'));
m.add(Arrays.asList('e', 'f', 'g', 'h'));
m.add(Arrays.asList('i', 'j', 'k', 'l'));

System.out.println(spiral_print(m));
}

{
List<List<Character>> m = new ArrayList<>();
m.add(Arrays.asList('a', 'b', 'c', 'd'));

System.out.println(spiral_print(m));
}
}
}


@tlday 我始终觉得语法糖这事情，因团队而异，一个人的团队，想怎么写都行。两个人或者人更多的时候，最简单的办法就是看这个团队的中位数工资，8K 的团队，跟 30K 的团队，对语言的要求是完全不同的，8K 眼里的难懂的奇淫技巧，在 30K 眼里可能只是稀松平常。都用 Java，8K 的人看 30K 写的代码，很容易看不懂，30K 看 8K 的很容易心情烦躁，都不利于维护。

做久了，自然没那么大的兴趣了

@msg7086 代码可读性强弱是因为语法吗？我觉得不是，宏观的架构，和微观的算法，加上对业务的理解，才是可读性的关键。用 Java 大家都写出一样的代码？不一定。

四种不同的循环的写法，对可读性的影响，远不如一个简单的算法，不信去看 ACM 解题的 Java 代码，有时行行都懂，就是看不明白原理。