@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 代码，有时行行都懂，就是看不明白原理。

@WispZhan C++的范型一样是语法糖，C 语言没有范型，就要复制粘贴代码了？ C++的确定性析构，在 C 里一样可以用 goto 实现啊，也算是语法糖。高级语言本身可不就是低级语言的语法糖么？

Kotlin 是属于 00 后的语言，70 后已经老到不能学了，80 后也不大能接受新语言了，90 后还在路上，00 后拿这个当主力的应该不会少

@zgqq 后台用 Kotlin 不会像 Android 那样宣传，所以感觉是少了，其实也不少。Java8 的 stream 也能这么写，但是要罗嗦的多，我之前就是用 Java8 的写法，看到 Kotlin 的简洁，马上就尝试了，然后就一发不可收拾。

@tlday 范型不过是编译器通过类型擦除加了点糖，所以不要用，Java 7 的 try-with-resource 也不要用，它也是语法糖，还是手动写 finally 释放资源吧。很多新加入的库，也是通过老库自己就能实现的，原则上算是库的糖，干脆也不要用。

所以我放弃 Java 了，转投了 Kotlin，花了不到一个星期时间，开发效率就超过写了 5 年的 Java。
map-filter-reduce 行云流水般的写法，太舒适了，不过读代码的人如果没有函数式思维，要头大了。

只是 open+read/write，100 万个即使不分级，也不会影响太大。但是有些 SB 语言的 SB 库，会读整个目录的文件列表，100 万个就悲剧了，1000 个比较合理。

同样是 CRUD，为何有人 5K，有人 50K

@wildcat007 其实你可以先办个居住证，用处很多的，而且两到三周也就办好了

没居住证可能不行，我办的时候要居住证的