s**********l
发帖数: 8966 | 1 他说得也有一定道理，AK47虽然简单但是是好枪(C++)，Sten就是粗制滥造的典型了，
虽然确实用的人多。(JavaScript)
当然最好是mp5那种设计又好，使用也方便，而且还不贵的(php)... |
|
w********m
发帖数: 1137 | 2 银神写东西真好，随便就是上万字。
这篇卖三刀，一点没问题。
中国的书商太没眼光，不找他写书。 |
|
|
y*j
发帖数: 3139 | 4 C++ 可以说是最复杂的语言，里面充满了各种语言的异常，一个R-value reference 就
可以让你搞半天才能明白。
实际上java的出现就是对C/C++的一个精简，去掉了指针和内存管理。
：C++可不简单，这货是非常复杂隐患无数的东西 |
|
y*j
发帖数: 3139 | 5 也不完全是精英的问题，如果处处都有异常的话，那么到一定的规模之后，里面的异常
有可能会泛滥成灾，反而搞不清重点。一个真正的精英应该会知道在什么地方加什么地
方不需要。希望通过checked exception 来解决问题，至少现在这种机制不是一个好的
选择。
：这篇文章很典型的反映了王垠的哲学：
：1. 编程是精英劳动；
：2. 精英设计出来的程序要完美；
：3. 编程工具要能让精英最大限度发挥潜能。
：王垠没有意识到的一点是，根本没有那么多的精英。大部分的商业程序都必须靠大量
的庸才蠢材通力合作才能支撑起来。
：而且，商业软件也不需要有多么完美的设计。大型项目都是靠大规模不停的测试，发
现问题了修修补补，达到要求就可以了。
：对于庸才蠢材来讲，工具只要简单好用使用就好了。就比如checked exception，加个
：try catch log比一条一条异常慢慢处理简单多了。严重的异常毕竟是小概率事件。 |
|
s********k
发帖数: 6180 | 6 你说的对，但是那是从技术角度来说，但是如上面别的所说，没那么多精英，不只是IT
，什么行业都是，但是为什么IT能爆发发展，就是这些CE之类让一个项目先从零到一
run起来，等到真正开始广泛应用了，code越来越大是会有泛滥成灾可能，但是那时候
再找高人解决，不能因为那个时候看到code乱七八糟否认开始时候能让code和产品快速
起来这些方便。正所谓好的系统演化，而不是设计，意思就是好的系统其实确是有不少
现在看起来糟糕，但是当时正确无比决定 |
|
Y**G
发帖数: 1089 | 7 还是语言直接支持CE的好，这东西是语言的核心部份，100个IDE可能有100个做法，项
目怎么维护 |
|
Y**G
发帖数: 1089 | 8 就是，infosys一年搬几万a3过来，一年可以码出上亿行代码，回头看，大部分是shit |
|
|
y*j
发帖数: 3139 | 10 Java相对于c/c++是一个进步，它把指针隐藏起来，简化了编程；但是这个checked
exception 似乎把异常处理层层的堆积起来，让程序变得复杂，觉得不是一个很好的处
理方式。
：你说的对，但是那是从技术角度来说，但是如上面别的所说，没那么多精英，不只是
IT，什么行业都是，但是为什么IT能爆发发展，就是这些CE之类让一个项目先从零到一
：run起来，等到真正开始广泛应用了，code越来越大是会有泛滥成灾可能，但是那时候
：再找高人解决，不能因为那个时候看到code乱七八糟否认开始时候能让code和产品快
速起来这些方便。正所谓好的系统演化，而不是设计，意思就是好的系统其实确是有不
少现在看起来糟糕，但是当时正确无比决定 |
|
w****e
发帖数: 1883 | 11 为啥会层层堆积？除非所有code catch之后啥都不干就rethrow
：Java相对于c/c++是一个进步，它把指针隐藏起来，简化了编程；但是这个checked
：exception 似乎把异常处理层层的堆积起来，让程序变得复杂，觉得不是一个很好的
处理方式。 |
|
x****u
发帖数: 44466 | 12 除了emacs和vim这两个不是ide的没办法，全球其他ide处理方法都一样 |
|
n*w
发帖数: 3393 | 13 即使很复杂的系统，type inference 可以做到。为什么CE做不到？ |
|
g****t
发帖数: 31659 | 14 我印象里。
Type inference本身可以嵌入图灵停机问题。
所以只能做到一部分。静态分析都是这样。
但我觉得自动化这些肯定是趋势。因为可以要求人不写
静态分析搞不定的代码，不然就punish.
: 即使很复杂的系统，type inference 可以做到。为什么CE做不到？
|
|
发帖数: 1 | 15 看了喷王垠的,基本都是一个腔调, 这厮没有这个经验,没有那个经验,不懂的真正的系
统,不知道实际的大系统就应该这样,就应该那样.反正各种不合理只要存在就是合理的,
从来不能给出一个相同量级的反驳. 总之, 别人谈智慧,他就用小聪明来反驳, 别人谈
思想谈方法,他就用自己的那点垃圾经验来举反例,各种插科打诨, 自己都说服不了自己.
其实, 王垠这种人的神奇之处, 就是没有太多的经验,但是总能得到宝贵的结论.
反观喷子, 搞了一辈子, 攒了无数的经验, 没有归纳, 没有总结, 更不舍的做取舍, 永
远就是那个层次. 对他们来说世界是高不可攀的,是不可质疑的,自己的这些经验是自己
装逼和求生的本钱,好不容易攒到了,哪能说不值钱就不值钱了.
想到了韩寒在早年间被采访的视频, 台下一群喷子, 问他,你18岁,你有这个经验吗, 你
有那个经验吗, 你凭什么说这个, 你凭什么说那个. 这一幕何其相似... |
|
x****u
发帖数: 44466 | 16 你这不只是骂王垠，韩寒得罪你什么了。。。
的,
己. |
|
T*******x
发帖数: 8565 | 17 犀利啊。
这就是悟性。悟性高的人从一两次经验中就可以总结出规律。但是也经常错。
的,
己. |
|
g****t
发帖数: 31659 | 18 我不认为老王有多少悟性。一来他数理逻辑，计算理论不过硬。二来他的经验积累很快就
会过时的。没有足够的business case和项目经验则
无法走经验实用的道路谈语言。
你觉得他思考的角度不同，那是因为他会不断的执着否定
所有的东西。另外之前很多他写的东西其实是几个教授的notes.美国怀才不遇的人太多
了。
: 犀利啊。
: 这就是悟性。悟性高的人从一两次经验中就可以总结出规律。但是也经常
错。
: 的,
: 己.
|
|
i******l
发帖数: 270 | 19 没什么进步不进步，这两的哲学不同
C++ 永远追求 run on metal 的性能
时候 |
|
k****i
发帖数: 101 | 20 垠神能写善悟，这你也怨韩寒。
只有wdong 那些挖坑水文撇去油末，才有几分可比性。
：你这不只是骂王垠，韩寒得罪你什么了。。。
： |
|
k****i
发帖数: 101 | 21 花开两枝，各表一朵。
灵性与悟性，可遇不可求。
众人皆醒垠独醉。。。
：犀利啊。
： |
|
s********k
发帖数: 6180 | 22 java下降估计是因为服务器端很多用go？android用kotlin？ |
|
发帖数: 1 | 23 除了kotlin还有其他jvm language比如scala， clojure， groovy 也分了流 |
|
d*******r
发帖数: 3299 | 24 zhaoce还在坚持推广vert.x, 执着啊, 是觉得 kotlin对vert.x有帮助? |
|
z****e
发帖数: 54598 | 25 java的coroutine 阿里的jvm已经做出来了
不过这也不是什么黑科技，能做出来的大把
而且不配合actor model的话
lock还是很多，性能还是上不去
只有配合了actor model，把线程数降下来
这样lock数量才会减少，而且引入immutable才会变得合理起来
否则满天飞的immutable，性能也还是上不去
但是这样要求不能写blocking code
这个只要有coroutine，书写难度就降下来很多
要不然一大堆高阶函数，哪有办法
map来map去的，很多人搞不定
coroutine之后，fp这一波热潮也差不多该到头了
最早是用来解决callback hell的方式
现在不用了，那高阶函数存在感会大幅下降
monad这些估计根本就没啥市场了
基本上跟之前预测的很像
就是知道什么是immutable，什么是1st class citizen这些
然后懂得用lambda，可以了
足够了，coroutine会接管剩下的部分
有了coroutine，就可以调用异步api，如同同步api一样
而且kotlin会在idea里面，给你加上一个绿色的小箭头
非常好玩 |
|
z****e
发帖数: 54598 | 26
ml那个东西到底怎么赚钱，business model至今无法验证
ng又跑回去开课赚钱了，这个风险太大
但是这种性能提升对于客户价值来说意义甚大
开支马上降下来，效果立竿见影
这些年异步(lambda)，callback(node.js)，coroutine(go)都在摸索
到现在这个阶段，算是一个大成了，总算是解决了这个问题
不管是性能上的提升，保证可读性这些，各方面都有了一个能够接受的答案
这是我在vert.x上用kotlin的感受，那下面就是推广了 |
|
z****e
发帖数: 54598 | 27 import io.vertx.core.Context
import kotlinx.coroutines.experimental.CoroutineDispatcher
import kotlin.coroutines.experimental.CoroutineContext
open class VertxContextDispatcher(val vertxContext: Context, val vertxThread
:Thread) : CoroutineDispatcher() {
override fun dispatch(context: CoroutineContext, block: Runnable) {
if (Thread.currentThread() !== vertxThread) vertxContext.
runOnContext { _ -> block.run() }
else block.run()
}
}
关键的一个类，确保coroutine在vertx thread上运行
3.5中这... 阅读全帖 |
|
z****e
发帖数: 54598 | 28
immutable还是有用的，verticle之间需要immutable，用cglib做immutable object
type无所谓，用verticle封死就无所谓到底是static还是dynamic，就那点代码，随便玩
然后coroutine/async/await
实践中，对于java程序猿，没有接触过其他环境的java程序猿，纯后端出身的程序猿
我们一般建议先从groovy开始接触其他环境，一般半个小时后就能开始写了
动态类型并没有什么问题，前提是写verticle，然后元数据编程很好用
一个@immutable就能作出immutable了，都不需要自己倒腾cglib了，虽然cglib也不难
如果是以前做安卓的，则建议从kotlin开始接触其他环境
最近idea社区版支持scala啦，开始逐步接触尝试尝试
同时建议写点ruby啊什么的，来锻炼一下脚本的语法糖，蛮好玩的
目标成就：vert.x上全语言制霸 |
|
z****e
发帖数: 54598 | 29
其实这个东西很容易回答
我们只要它作出20分的成绩，至于它的目标是60分还是100分
不重要，重要的是20分就够用了，因为其他的40分有加成
考20分就过线了，但对于go来说，可能要60分才能过线
因为go没有加成，而我和其他看得懂的人说的就是有了这40分的加成之后，20分轻松过线
而你或者wdong说的，都是没有这个加成时候该怎么办
两回事，两回事，所以都是鸡同鸭讲
还在思考怎样从0出发去考及格，你们已经落后了
你们在用10年前的思考方式在思考这个问题
最后就变成了，别人说可以做到
你们不理解，就说，怎么可能？牛得不得了的人都没做到
blablabla，哎，vert.x+kotlin，你不服你自己去看看它是怎么做的咯
你不信你自己可以跑一下benchmark嘛，vert.x常年在techempower上排行靠前
你就没想过去看看为什么？去做这事比你在这里放空头炮要强很多吧？
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json
我觉得嘛
我老是教育你，一来你也不爽，就算教育了你
你也不感激我... 阅读全帖 |
|
z****e
发帖数: 54598 | 30
给你看一下对比
当前暂没有coroutine的java的高阶函数的写法
Future.>future(f ->
vertx.eventBus().send("address1", "message", f)
).compose((msg) ->
Future.>future(f ->
vertx.eventBus().send("address2", msg.body(), f)
)
).compose((msg) ->
Future.>future(f ->
vertx.eventBus().send("address3", msg.body(), f)
)
).setHandler((res) -> {
if (res.failed()) {
//deal with exception
return;
}
//deal with the result
});
嗯，不是太好看懂，这里有几个语法糖和简写，当前没有corouti... 阅读全帖 |
|
z****e
发帖数: 54598 | 31
java 9出来了
clojure升级了么？
没发现用不了么？
clojure还在用sun的那些不安全的包
jigsaw影响比较大的jvm语言就是clojure，其他都还好
kotlin已经升级到9了，最快的一个，不算java和js(nashorn)的话
这两个是oracle官方支持的，这不能算
其他的估计clojure会成为最慢的一个，就看jython是不是会更慢
用一个东西呢，是有前提的
以前用高阶函数，是没有办法
现在有了coroutine，选择多了一个
就不需要高阶函数来帮忙解决callback问题了
那自然就挑容易的搞了
应该这么说，coroutine提供了高阶函数以外的一种选择
让我们可以不需要用高阶函数了
偶尔用一用，比如
button.action = lambda{|now|
canvas.clear()
canvas.image(image, 0, 0)
}
这种可以接受，但是大量出现高阶函数
那个写起来，呵呵 |
|
z****e
发帖数: 54598 | 32 你要看什么？
不用等5年
现在已经有了
早就有了
http://vertx.io/docs/vertx-sync/java/
https://github.com/puniverse/quasar
你说java做不出来？现有的东西出不来？
现在一大票语言都开始async／await，coroutine什么都出来了
你想等5年之后？等什么？等这些语言一个个做出来嘛？
现在已经有好几个了，比如kotlin，你是说这个东西不存在？
说了，不是你想的那种coroutine，你被wdong绕进去了
wdong说的那种coroutine不是我们需要的coroutine或者说不是那么复杂的东西
我们只需要其中一小部分，就能满足要求了
用工具的目的是用来解决问题的，不是用来探索真理的
你要探索宇宙的真相，大可以去物理学上咕哝上半天
反正买买提每次讨论物理都很热闹
我们要处理的是怎么榨取机器性能，同时保证可读性不要下降 |
|
|
z****e
发帖数: 54598 | 34
我试了啊，9出来我就升级了一大堆东西
发现kotlin可以过啊，其他都过不了
包括native compiling这些
你试了吗？你试试不就知道我说的对不对咯？ |
|
z****e
发帖数: 54598 | 35
Function0
停停停
你没有用过vert.x
所以鸡同鸭讲
我给你一个建议，去看看vert.x的设计
然后再来谈
死锁？
都lock free了，死锁什么哟？
都用这么久，遇到过搞不定高阶函数的
还真没遇到过死锁的
vert.x一直就是reactive programming
正是在实践中遇到了问题
所以我们才会寻找答案
而现在说的coroutine
正是我们找到的答案
之前搞reactive programming
最大的麻烦就是普通程序猿掌握不了高阶函数的使用
map, flatmap，副作用，绕晕了，搞不定我去
后来情愿换成kotlin，coroutine白菜化异步api
然后就ok啦
还是那句话，你们没有经验，看不懂
我当然知道高阶函数，reactive是一种解决方案
但是很麻烦，一般程序猿搞不定
思维上的改造不是那么容易的
这就是为什么一大堆语言都在搞coroutine/async/await的主因
fp那些，主流不感兴趣，因为搞不懂嘛
没有coroutine之前，我们推广reactive，多恶心你知道嘛？
一说副作用，无状态函数，fp下面一大堆人在睡觉，哈欠连天
这... 阅读全帖 |
|
x***4
发帖数: 1815 | 36 新语言都在后面了。go,Scala,Kotlin,Swift |
|
c******n
发帖数: 16666 | 37 嗯 java还是走kotlin吧
我知道c++转rust的都在夸他好 |
|
|
s********k
发帖数: 6180 | 39 其实说蚕食不对，两边都在高速增长，Android对于做过native 的JAVA，尤其最近做过
kotlin的人需要还是非常大 |
|
|
|
|
|
n******7
发帖数: 12463 | 44 typescript 用来写新project? 基于node.js? |
|
|
c******n
发帖数: 16666 | 46 有些猛糙块用nodejs
主要是前端spa+d3+webgl这块 |
|
e*******o
发帖数: 4654 | 47 终于出来个明白人。
啥clojure，scala的，都是扯淡。
project |
|
w**z
发帖数: 8232 | 48 让人学clojure 这种属于毁人不倦，坑太少，基本没有大公司用。当然，你牛逼，自己
当老板没问题。但让新人学，不是害人吗？
：终于出来个明白人。
： |
|
g****t
发帖数: 31659 | 49 Hci说的就是糙快猛吧？新人应该是轮不到又糙快猛的机会。多数是做填空题的。
: 让人学clojure 这种属于毁人不倦，坑太少，基本没有大公司用。当然，你牛逼
，自己
: 当老板没问题。但让新人学，不是害人吗？
: ：终于出来个明白人。
: ：
|
|
w**z
发帖数: 8232 | 50 真要糙快猛，就选自己最拿手的。
这也是为什么，startup的tech stack 都是选用founder 最懂的。 其实Hci也是这情况
。基本没有人会去选一个，自己不会的，但是“听说”，糙快猛的去做，一定是是在一
开始里的团队里有一个某方面的大拿专家选了一个自己拿手的。
我最近做的三个 startup， 一个PHP， 两个Python 都是这情况。 |
|
