我都不敢确认有没有这句了……哈哈哈 掩面而逃
【 在 sixue1999 的大作中提到: 】
: 这个nothing special happen，我还以为是路易十六的梗呢
: 但是查了一下好像不是
: 路易十六的「无事发生」似乎只是一个单词rien
--
FROM 61.185.186.*

这个说法不对吧....
只能说cpp和java的时代oop这个概念还比较时髦，算是当时的一个时代特征。就跟下一个十年的语言都喜欢整个lambda一样。

但java的普及绝对不是什么「用给c做减法的方式来实现c风格oop」带来的。java吸引人的地方从来是“一次编译，到处debug”....
java的j2se，j2me都失败了，真正让java胜出的是j2ee。而让它胜出的核心原因也是因为java是同时代不多的，没有segment fault问题的高性能语言。
oop对于java的成功我觉得贡献很小，可以忽略不计。

此外，cpp最初在「给c做加法的方式来实现‘c风格+oop’」这条路上做的也蛮好的。事实上很多初学者都会把oop=cpp，能有这样的影响力本身就说明了它的成功。说“cpp的这批初始用户反而成了cpp最大的历史包袱”，说他们是“不是很理解oop，技术栈又落后的老古董”有点太过了。oop又不是什么很复杂很难理解的概念，我觉得甚至可以说连vue都比它复杂...

【 在 sixue1999 的大作中提到: 】
: cpp最初的使命非常明确，就是给c加上oop
: 对此，cpp给出的路线是，「给c做加法的方式来实现‘c风格+oop’」
: 但是，历史证明，这条路的正确答案是java，即「用给c做减法的方式来实现‘c风格oop」
: ...................
--
修改:lvsoft FROM 49.93.80.*
FROM 49.93.80.*

java 并不是正确答案啊……我觉得上个世纪的语言里，最终交出完美答卷的是 go。虽然它是2009年才发明的语言，但 c# 都比它现代多了。

这个世纪的新语言里，除了必须保证兼容性的情况外（kotlin、swift），大多数语言都在去 oop。而 immutable、closure、pattern matching 这些在 fp 里常见的概念大行其道，从语言到各种框架，都表现出向 fp 学习的趋势。甚至连前端 component 这种看起来似乎更适合 oop 的地方也是如此，比如 react 一开始是 class 的设计，现在已经不用了

【 在 sixue1999 的大作中提到: 】
: cpp最初的使命非常明确，就是给c加上oop
: 对此，cpp给出的路线是，「给c做加法的方式来实现‘c风格+oop’」
: 但是，历史证明，这条路的正确答案是java，即「用给c做减法的方式来实现‘c风格oop」
: ...................
--
FROM 203.184.25.*

写下int后，可能是变量，可能是函数返回值

写下main：，后面是()，就可以判断是函数了；再加上->int就知道是返回值了
编译器解析时可以简单点，方便开发自动提示工具、lint工具。

这是社区/官面的说法。我个人觉得变量名放前面，可以自己控制变量名字母数一样，对齐看起来很舒服。像我这种起名大师、对齐强迫症患者来说，非常舒服。
如果是int float在前，咋也对不齐。

类似的还有构造函数初始化列表：
ctor::ctor()
: a
, b
, c
{
i}
【 在 jesce 的大作中提到: 】
: main:() -> int = 比 int main() 好在哪? 方便理解? 稍微入点门也不会对后者的理解有问题吧, 又不是需要人人都是coder, 但是论输入时间, 前者可能是后者的N倍
--
FROM 124.114.151.*

类型声明后置也是这个时代的标准了
c 的类型声明方式的确不好读……

【 在 jesce 的大作中提到: 】
: main:() -> int = 比 int main() 好在哪? 方便理解? 稍微入点门也不会对后者的理解有问题吧, 又不是需要人人都是coder, 但是论输入时间, 前者可能是后者的N倍
--
FROM 203.184.25.*