给 OC 加些阻力，强推 swift （

@GoodRainChen #76
我再说一遍，你说的关于 kotlin 的 ! ? 限制，全是错的。我已经说了实际上 kotlin 是怎么处理 Java 方法定义的，你不愿意听不愿意看不愿意试，也行，至少结论应该是「 kotlin 对于类型安全等方面的限制更加严格，可以节省更多写 if (x == null) 的时间」。

@bumz #73
第一，外包公司也用 Java （同时外包公司不用 kotlin ）。
第二，你前一句说要展望未来来着，看今天市占有什么用，.net 开源才刚开始。
第三，我试着理解一下你的逻辑：为什么 Java 好，因为它是「程序语言设计专家」开发的，为什么「程序语言设计专家」是「程序语言设计专家」，因为他开发了 Java ；为什么说微软没有「程序语言设计专家」，因为 C# 不好，为什么 C# 不好，因为它不是「程序语言设计专家」开发的。是这样吗？

@GoodRainChen #72
你还在说 setContentView，这个方法根本没有标 NonNull，打开 IDE 看看这种 View! 的东西怎么处理的吧，别老给我挖坑了。
我反正已经复制了一个 Google 写的判断参数是 null 就抛异常的 startSupportActionMode 方法出来，你可以认为这完全是浪费时间，就算不写也是一个 NullPointerException，我只能说这是正常逻辑该有的操作。

还有，不是「没发现有什么本质上的优势，写代码最花时间的还是思考，而不是打字」吗，怎么连个 if (x == null) 都没时间写了？既然确实要这点儿时间，那 kotlin 优势不就又出来了？

@closedevice #65
本质还是 JVM 语言，编译出来 .class 再反编译回去还是 Java，不谈语法有什么好谈的

@bumz #56
那原因不问，展望一下擅长 marketing 的叫嚣着替代 Java 的 C# 未来将会如何吧，毕竟是微软做的。

@bumz #52
这个于是起什么作用？为什么不如，哪不如？大师级人物干什么都是大师级，大师级人物的 NetBeans 怎么没人用呢？

@abeholder #44
放到 IDEA 里，很多语法优化建议都会给出弱警告，比如一些变量提示可以私有的，比如 it.trim().length > 0 会提示 Replace size check with 'isNotEmpty' ，按提示会修改成 it.trim().isNotEmpty()。
还有一些无关紧要的不会提示的地方，比如 it.trim().isNotEmpty() 还可以改成 it.isNotBlank() ， .filter { it == answer[0] }.length 可以改成 .count { it == answer[0] }，这些方法都是只要看见有这个方法就知道怎么用的，我觉得没必要特别记忆，写个点想要什么就打什么，有方法就用，没方法的经常用的话也可以造个方法用，写得跟写英语一样就行了。

@GoodRainChen #38
我也再复制一个正常的不接受空参数的方法的实现供参考
@Override
public ActionMode startSupportActionMode(@NonNull final ActionMode.Callback callback) {
if (callback == null) {
throw new IllegalArgumentException("ActionMode callback can not be null.");
}
...
}

@GoodRainChen #38
常见的模式是判断了再抛异常出去，直接报空指针可不常见（要说常见倒也常见，只是这种时候可算不上模式）。
建议打开 IDE 写几行试试看，别靠猜。推荐测试方法 getMenuInflater()，kotlin 里的 menuInflater，类型 MenuInflater!，看看不加问号报不报警告。

@GoodRainChen #36
等等，你好像挖了个坑给我，标注 ! 的东西作为方法返回值类型时在 kotlin 里根本不需要判断非空也不需要加 ? 调用，作为参数重写的时候可以自己选择加不加可空，你说的不能和非空类型通用的是 savedInstanceState 这样的 Nullable 的 东西

@GoodRainChen #36
首先，你这个逻辑是错的。setContentView 是你写的，那是谁在调用 setContentView ？你自己调用你知道，团队成员调用你也知道？他们调用传个 null 进来，你是不是要崩？
而此时如果你们用 kotlin，这个方法就可以是 setContentView(view: View) ，谁也不会传 null 进来。

其次，这个方法不是你写的，它本来就可以给个 null，如果你重写方法并不处理 null，总有第三方库会让它出错。

@GoodRainChen #33
第二点我觉得我已经说清楚了，我再试着解释解释。注解 Nullable 的，具体举例
protected void onCreate(@Nullable Bundle savedInstanceState)，
它在 kotlin 里调用的时候提示是
onCreate(savedInstanceState: Bundle?) ，
注解了 NonNull 的
public void onSupportActionModeStarted(@NonNull ActionMode mode)，
它在 kotlin 里调用的时候提示是
onSupportActionModeFinished(mode: ActionMode)，
没注解的，具体举例
public void setContentView(View view) ，
它在 kotlin 里提示是
setContentView(view: View!)，
无论哪一种，正常逻辑都跟 Java 里调用是一样的流程（ Java 用的 if 逻辑 kotlin 也能用，kotlin 的 ? 逻辑 Java 不能用，这一条显然是 Java 更麻烦 ），非正常逻辑下区别是调用 onSupportActionModeFinished(null) 在 Java 里可以正常编译等运行时报空指针，Java 里的 onCreate 里面可以直接用 savedInstanceState 而不需要判断非空等第一次打开 Activity 报空指针。我觉得这个能力真是毫无用处。

第一点，就按你的需求来，在 Java 中，如果你要看 setXXX 内部逻辑，你要看到一个 setXXX 就点进去看看；在 kotlin 中，同样的需求，你可以看到一个等号就点进去看看；如果 Java 里这个 setXXX 是 Lombok 生成的，甚至点进去看的时候都同样跳转到声明处。我没感觉出来区别。

@GoodRainChen #25
从下往上说。
首先 getter setter 也不是 kotlin 首创，你可以观察观察 C# 程序员对 Java 的 set 方法什么评价。同时，方法调用者不需要也不应该关心方法内部逻辑。如果看一个 x.a = 1 你不知道里面有没有计算逻辑，那么如何知道 x.setA(1); 里面有没有计算逻辑？如果一样不知道，这一项打平没毛病吧？
那么便捷的语法对代码阅读需要的思考量会增多吗？我觉得会减少。对于语句 x.toJson() 和语句 objectMapper.writeValueAsString(x) ，哪一个能一眼看出在做什么？
再往上，类型安全限制，就是非空呗？首先自己写的 kotlin 方法和属性能不能空完全自己控制，Java 代码没有明确注解的都是 String! 类型，做不做检查都不会报错，Java 代码标注 Nullable 的你写 Java 不也得写一块儿检查？如果区别是 kotlin 必须检查而 Java 可以不检查让它运行时空指针，那我是只看出来好处。

但看起来楼主是来喷人的，在这讨论这些意义不大。

推荐几行代码
inline fun View.gone() { visibility = View.GONE }
inline fun View.visible() { visibility = View.VISIBLE }
inline fun View.invisible() { visibility = View.INVISIBLE }
inline fun View.visibleOrGone(visible: Boolean) { if (visible) visible() else gone() }
inline fun View.visibleOrInvisible(visible: Boolean) { if (visible) visible() else invisible() }

就可以 rcv_today_cars.gone()
这样再用回 Java 写 setVisibility 的时候就会难受了。

@GoodRainChen #8
那么用 Java 对思考有什么样的好处，使用 kotlin 对思考有什么样的坏处呢？
如果没有，简单的算数，kotlin 还是快

someFunc()
.then(somePromiseFunc)
.catch(e => {

})

减少辐射，环保健康，少接电话，心情偷税，建议入手

JHipster is a fully Open Source, widely used application generator. Easily create high-quality Spring Boot + Angular/React projects!

我看是你不待见 React 在先，至少在我看来 ng 比 react 写着难受又没有什么优势